Команда из 25 разработчиков может развернуть собственный инференс и всё равно не сэкономить. Разбор на Habr с пятью последовательными конфигурациями приводит к более полезному выводу: на агентской нагрузке кэш префикса влияет на результат сильнее, чем выбор модели и размер карты.
Это неприятная новость для закупочного расчёта в стиле «у нас много запросов, значит свой сервер дешевле API». Много запросов ещё не означает много уникальной вычислительной работы. А высокая загрузка железа сама по себе ничего не говорит о цене полезного ответа.
Что измерили
Автор публикации на Habr описывает путь через пять конфигураций, включая четыре промежуточных стенда. Финальный контур собран на одной карте Blackwell и vLLM. В материале также разобраны рабочие флаги запуска, три неочевидных бага и их обходы.
Особенно показательно соотношение входных и выходных токенов: 452:1. В материале приведено это соотношение, а среди ключевых элементов контура названы KV-пул и кэш префикса.
Главный вывод автора сформулирован жёстко: на агентской нагрузке кэш префикса решает больше, чем выбор модели, размер карты и всё остальное вместе взятое. До этого понимания команда дошла за несколько стендов и, по её оценке, потратила лишние месяцы, потому что неправильно определила предмет измерения.
Для сравнения self-hosting с внешним API этого наблюдения недостаточно, но оно задаёт правильную единицу анализа: долю вычислений, которую контур действительно выполняет повторно или, благодаря кэшу, пропускает.
Как измеренный контур переводится в TCO
Стенд на одной Blackwell показывает работу vLLM, batching и KV-пула при конкретном профиле 452:1. Бизнес-расчёт начинается с проверки того же контура в производственном потоке, и здесь результат нужно связать с четырьмя статьями полной стоимости.
Пики. Batching и KV-пул следует проверять при максимальном одновременном потоке: помещаются ли запросы в доступную память и сохраняется ли переиспользование префиксов, когда контекст меняется. Если нет, потребуется дополнительная производительность, которой не видно по среднему замеру.
Простой. Одна карта оплачивается и в часы, когда поток запросов падает. Поэтому к измеренной пропускной способности нужно добавить профиль спроса: сколько времени ускоритель обслуживает полезную нагрузку, а сколько ждёт следующего пика.
Резервирование. Финальный стенд публикации собран на одной карте, однако производственный TCO должен учитывать запас на отказ или обслуживание. Это отдельная статья, а не продолжение тестовой цены сервера.
Инженерная поддержка. Здесь публикация даёт прямую фактуру: четыре промежуточных стенда, три неочевидных бага и, по оценке автора, лишние месяцы поиска правильной метрики. Эти затраты нельзя считать разовыми по умолчанию, контур с vLLM, batching и KV-пулом придётся наблюдать и поддерживать после запуска.
Так измеренный технический эффект превращается в расчёт: выигрыш от переиспользования контекста сопоставляется с мощностью под пики, оплатой простоя, резервом и временем инженеров. Сам материал подробно подтверждает лишь последний пункт и устройство финального стенда; остальные статьи команда должна измерить на собственной нагрузке.
Полный счёт начинается после покупки
Это не аргумент против собственного инференса. Это аргумент против его ленивого обоснования. Self-hosting выглядит разумно, когда нагрузка предсказуема, длинные префиксы повторяются, измеренный эффект сохраняется на пиках, а стоимость простоя, резерва и поддержки не съедает вычислительную выгоду. Внешний API сохраняет преимущество там, где спрос рваный, контекст постоянно меняется или собственный контур требует слишком дорогого запаса.
Практический шаблон пересчёта поэтому должен включать профиль входа и выхода, долю повторяемого префикса и четыре строки TCO: пики, простой, резервирование и инженерную поддержку. Цена карты появляется рядом с ними, а не заменяет их.
Главный маркер на ближайшем замере: сохранится ли выигрыш кэша префикса на реальной агентской нагрузке, а не на подготовленном тесте. Если при изменении контекста и пиковом потоке KV-пул перестанет эффективно переиспользоваться, высокая утилизация останется красивым графиком. Но не доказательством экономии.