Инференс LLM для 25 разработчиков: 452:1, KV-пул и почему это не экономит денег

Команда из 25 разработчиков, работающая с агентским кодингом в закрытом контуре, развернула собственный инференс LLM на одной карте RTX PRO 6000 Blackwell 96 GB. Аренда железа обходится в 131 000 ₽ в месяц, модель — Qwen3-Coder-Next-FP8 (80B MoE, 3B активных параметров), движок — vLLM 0.27.1 в Docker, шлюз — LiteLLM 1.95.0. Стенд обслуживает 25 подключённых пользователей, из них 16 активных ежедневно, и обрабатывает постоянный поток запросов от Claude Code и Claude Desktop в режиме third-party. Ключевое ограничение — закрытый контур: код заказчиков не покидает периметр, что и стало причиной развёртывания собственной инфраструктуры.

Путь к текущей конфигурации занял пять итераций, и каждая выявляла проблемы, которые не были очевидны на предыдущем шаге. Первая конфигурация с плотной моделью Qwen3 30B работала предсказуемо, но не справлялась с агентским циклом — требовались ручные подталкивания. Переход на MoE-версию 30B поднял качество, но модель занимала лишь четверть 96-гигабайтной карты — неэффективное использование железа. Наконец, Qwen3-Coder-Next 80B дала приемлемое качество, но кэш для гибридной архитектуры в сборке vLLM не работал, и команда этого не замечала, пока не подключила LiteLLM. Шлюз показал разбивку по типам токенов: запросы читают на порядки больше, чем пишут. Диагностика появилась раньше лечения, и это нормальный порядок вещей.

Ключевым изменением стало включение флага --enable-prefix-caching для гибридных моделей — в vLLM 0.27.1 он не активируется автоматически. После этого доля попаданий в кэш выросла с 0% до 96.9%, а латентность на повторном префиксе упала с 31.9 секунды до 0.24 секунды. Цифры подтверждаются с двух независимых сторон: биллинг шлюза и собственные счётчики движка (97.3% попаданий за период аптайма). Это не оптимизация на проценты — это смена режима работы стенда, высвободившая время, VRAM и терпение команды.

Экономика стенда раскрывает специфику агентской нагрузки. За календарную неделю обработано 8 030 запросов, потреблено 993,5 млн входных токенов, из которых 962,3 млн прочитано из кэша, и лишь 31,3 млн обработано реально. Выходных токенов — 2,2 млн. Отношение вход/выход — 452:1. В пересчёте на один запрос: ~123 700 токенов входного контекста, из них ~119 800 из кэша, ~3 900 обработано, сгенерировано 274 токена. Средний шаг агента тащит сто двадцать тысяч токенов и выдаёт двести семьдесят четыре. Нагрузка на 16 активных пользователей — около 500 запросов на человека в неделю, примерно сотня за рабочий день.

Отсюда два практических следствия. Первое: на агентской нагрузке оптимизация чтения контекста важнее скорости генерации — бенчмарки, меряющие tok/s на выходе, описывают лишь 0.2% реального трафика. Второе: сравнивать собственный инференс с облаком нужно по фактическому биллингу с учётом кэша, а не по сырому объёму входа — иначе можно нарисовать себе выгодную, но неверную картинку. Авторы подчёркивают: если у вас гибридная или MoE архитектура и вы не видите строку cache read в статистике — вы, скорее всего, платите тридцатикратную латентность и не знаете об этом. Проверять надо не «есть ли кэш в vLLM», а «работает ли он для вашей конкретной архитектуры в вашей версии».

Вопрос экономической эффективности остаётся открытым. Авторы не приводят итоговую стоимость за токен или сравнение с облачными API, но предупреждают, что наивный расчёт по сырому входу завышает выгоду. Для команд, рассматривающих собственный инференс, материал даёт практические ориентиры: конфигурации, флаги vLLM, три неочевидных бага и обходы. Главный вывод — на агентской нагрузке кэш префикса решает больше, чем выбор модели, размер карты и всё остальное вместе взятое. Подробный разбор выбора модели по замерам, а не по бенчмаркам, авторы обещают в отдельной статье.