Глава 15 — Serverless API против выделенной инфраструктуры

Пятнадцатый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, кладущая арифметику точки безубыточности на стол и затем называющая строку бюджета на платформенную инженерию, толкающую ответ для большинства команд.

Зачем эта глава существует

Глава 14 оставила команду с чистой картиной, из чего сделан API-счёт, и тихим подозрением, что может быть дешевле. Естественный следующий вопрос — должна ли команда вообще платить за токен. Альтернатива — привести инференс в дом, запустить open-weight модель на стеке, описанном в более ранних главах, и платить за GPU-час вместо этого. У обмена есть чистая точка безубыточности. Что менее чисто, и что большинство команд недооценивает, — это всё на стороне выделенного, чего нет в GPU-счёте: платформенная инженерия, security-патчи, хореография апгрейдов моделей, страничка в 3 часа ночи, когда узел выпадает из флота. Глава 15 берёт обе стороны всерьёз и выводит, когда self-hosting — правильный ответ.

15.1 Формула точки безубыточности чиста и в основном обманчива

GPU производит throughput × utilization × 3 600 выходных токенов в час. Его стоимость на миллион токенов — (gpu_hourly / tokens_per_hour) × 1 000 000. Безубыточность против API — там, где это число равно per-миллион цене API. 70B-модель в FP8 на H100 за $3/час, гоняющая 800 токенов в секунду агрегированно при 60 процентах утилизации, выходит на около $1 за миллион выходных токенов. Фронтирный API берёт $15. Кажущаяся экономия — 14× — аргумент для self-hosting, который любят финансы и который упускает вторую, большую строку. Точка безубыточности также зависит от утилизации; ниже 20–30 процентов утилизации self-hosted стоимость на миллион поднимается выше API-ставки, и GPU становится дороже альтернативы, которую он должен был вытеснить. Утилизация, в свою очередь, — функция формы трафика, качества автоскейлинга и того, может ли команда упаковать больше одной нагрузки на один флот.

15.2 Платформенная инженерия — строка, которая решает сделку

Счёт за GPU — меньшая половина. Большая половина — команда, поддерживающая работу флота: движки, драйверы, оркестрация, автоскейлинг, наблюдаемость, безопасность. Команда API платит эту стоимость неявно через per-токен цену; self-hosting команда платит её в head-count. Полезное правило: один serving-флот — один-два варианта модели, автоскейлинг, наблюдаемость, on-call, квартальные апгрейды — требует примерно одного FTE-платформенного инженера плюс долю SRE. Более разнообразный флот — несколько движков, несколько моделей, мульти-тенантное планирование — требует двух-четырёх. При $300 тыс. полностью нагружённых на инженера годовой счёт за платформу — $300 тыс.–$1,2 млн. Точка безубыточности месячного трафика, где self-hosting окупается, лежит где-то между 200 миллионами и 1 миллиардом выходных токенов в месяц. Ниже этого — инженерный оверхед превышает экономию на токенах и команде стоит остаться на API. Выше — экономия доминирует. Платформенная инженерия также приходит ступенчатыми функциями, а не гладкими кривыми: первый найм поднимает флот, второй случается, потому что первый не может покрыть on-call на выходных, третий — когда флот растёт в мульти-регион.

15.3 Реалистичная поза — гибридная, а роутер — несущий элемент

Самое чистое решение — всё через API или всё выделенное — редко верно для команды больше года в продакшене. Установившиеся предсказуемые нагрузки (ночной batch, плановые отчёты, очереди классификации) хорошо упаковываются на запланированную выделенную ёмкость. Взрывные нагрузки (вирусные всплески, потоки тикетов, запуски новых когорт) требуют эластичности API. Нагрузки со строгой задержкой (интерактивное автодополнение, голос) выигрывают от совмещённого выделенного развёртывания. Нагрузки без задержки (ночное обогащение, переиндексация) выигрывают от batch API за полцены. Архитектура, поддерживающая гибрид, — роутер на границе приложения, классифицирующий каждый запрос по бюджету задержки, сложности и текущей утилизации бэкенда и диспетчирующий на самый дешёвый бэкенд, выполняющий его SLA. Уточнённый роутер также делает внутри-API маршрутизацию модели (дешёвая модель для простых запросов, фронтирная для сложных, reasoning-тир для тех, кому нужно). Второпорядковое преимущество — опциональность: нагрузки могут мигрировать через границу изменением политики роутера, а не приложения. И выделенный случай часто окупается только потому, что вторая нагрузка — та, что иначе пошла бы в API, — едет на уже оплаченном GPU. Команда, оценивающая выделенный случай на одной нагрузке, обычно никогда не движется; команда, думающая портфелями нагрузок, движется, и экономит.

Что подготавливает глава 15

Глава 15 назвала класс нагрузки, введённой агентами, не подходящий ни под «вызов API», ни под «serving модели»: среда исполнения для LLM-сгенерированного кода, живущая на serverless-функциях, microVM (Firecracker, gVisor) или WASM-песочницах в зависимости от изоляции и гибкости пакетов, которые нужны агенту. Глава 16 закрывает том каталогом приёмов сокращения затрат, применимых на любой стороне позиционной линии: интеллектуальная маршрутизация моделей, компакция контекста уровня приложения, batch API, семантический кэш — приёмы, складывающиеся в треть или половину счёта прошлого месяца.

Дальше — Глава 16: Стратегии сокращения затрат в продакшене. Складывающиеся приёмы, превращающие счёт прошлого месяца в экономию следующего.