Prover farm это самая дорогая инфраструктура в ZK-стеке, и при этом самая недосчитанная. Команда покупает или арендует пачку GPU, гоняет на них SP1 или RISC Zero, видит счёт и не понимает, почему cost-per-proof в разы выше, чем считали на бумаге. Мы держим prover-инфраструктуру за клиентов и видим, что деньги утекают не там, где их ждут. Дальше про то, где именно.
Считаем cost-per-proof, а не cost-per-GPU
Первая ошибка та же, что и в LLM-инференсе: считать стоимость железа, а не стоимость полезной работы. GPU стоит фиксированную сумму в месяц, а ценность это доказательство, которое он произвёл. Cost-per-proof это месячная стоимость фермы, делённая на число пруфов, которые она реально выпустила, и почти всё интересное живёт в знаменателе.
Знаменатель убивают четыре вещи: пустая очередь, переполненная очередь, нехватка памяти и простой между всплесками нагрузки. Цена за GPU-час тут вторична: можно купить самые дешёвые карты и получить дорогущий пруф, если ферма половину времени стоит.
Очередь: и пустая, и забитая бьют по цене
Пруфы приходят не ровным потоком, а пачками, привязанными к ритму rollup'а или к дедлайнам на доказательство. Поэтому ферма постоянно колеблется между двумя плохими состояниями.
Пустая очередь это оплаченные GPU, которые простаивают между пачками. Прямой убыток в cost-per-proof: платёж за карту размазывается на меньшее число пруфов.
Забитая очередь хуже: пруфы копятся, latency на доказательство растёт, и если у rollup'а есть дедлайн на финализацию, вы упираетесь в него. Дальше выбор между «докупить карт под пик» и «не успеть», и оба варианта дорогие.
Управление этим колебанием это половина работы на prover-ферме. Грубо размер фермы под средний поток даёт дешёвый пруф и срывы на пиках; размер под пик даёт надёжность и кучу простаивающих карт в провалах. Реальная экономика живёт в гибриде: база на железе под средний поток, добор в облаке под пик.
Память: тихий потолок
ZK-доказательство прожорливо по памяти, и память упирается в потолок раньше, чем вычисления. На больших схемах witness и промежуточные данные не влезают в VRAM, и пруф либо падает, либо уезжает на CPU-фоллбэк, который в десятки раз медленнее. С точки зрения cost-per-proof медленный CISC-фоллбэк это карта, занятая в разы дольше на один пруф: дорого и незаметно, пока не посмотришь на распределение времён.
Поэтому раскладку фермы мы считаем не только по числу карт, а по профилю памяти конкретной схемы: сколько VRAM ест худший пруф, сколько параллельных доказательств влезает на карту, где начинается фоллбэк. Это определяет реальную пропускную способность куда сильнее, чем флопсы в спеке.
Утилизация и витаемость карт
Сверх очереди и памяти cost-per-proof точат две вещи. Первая это утилизация: доля GPU-времени, ушедшая в реальные пруфы, а не в загрузку данных, синхронизацию и простой пайплайна. Вторая это сама доступность нужных карт: prover-нагрузки тянутся к свежим GPU, а они в дефиците, и срок поставки на железо может перекрывать окно, на которое ферма вообще нужна.
Отсюда тот же гибридный вывод, что и в инференсе: ровную базовую нагрузку дешевле держать на своём железе с высокой утилизацией, а пики и короткие кампании добирать в облаке, переплачивая за час ради доступности и эластичности.
Как это у клиента
На полигоне мы прогоняем схемы клиента на реальном профиле нагрузки: меряем cost-per-proof, профиль памяти и поведение очереди под всплеск, и из этих чисел считаем раскладку фермы. Дальше это превращается в сопровождение: сколько карт в базе, как добираемся под пик, какие алерты на глубину очереди, latency пруфа и фоллбэк по памяти.
Если вам нужна prover-ферма, у которой cost-per-proof просчитан, а не «сколько вышло, столько вышло», это то, что мы держим в zk и закрываем через scale. Хотите прикинуть cost-per-proof под ваши схемы и поток: напишите нам.