Глава 8 — Оптимизация производительности, serving и стоимости
Финальный пост поглавного разбора LLM Primer V: Building Real-World LLM Applications. Глава, относящаяся к экономике продакшен-LLM как к слоёной дисциплине: самый дешёвый вызов — тот, что никогда не сделан, а каждый следующий слой ниже — тот, что делает следующий вызов дешёвым.
Почему существует эта глава
Каждое продакшен-свойство, которого стоит хотеть, оплачивается токенами, задержкой или compute-ом. Избыточность стоит второго провайдерского вызова. Валидация стоит прохода классификатора. Guardrails стоят лишних токенов на каждом промпте. Трассировка стоит хранилища и bandwidth-а на экспорт. Human-review стоит часов. Ни одно из этого не бесплатно, и к тому моменту, как система в продакшене, давление — не добавлять способность, а поддерживать ту, что у команды уже есть, за стоимость, которую бизнес будет продолжать платить. Глава 8 проходит слои, в которых живёт эта стоимость, и техники, снижающие её без регрессии качества. Рамка сознательна: техника, срезающая процент со стоимости, но добавляющая процент к частоте ошибок, — не победа, и дисциплина — тратить осознанно на то, что двигает пользовательское качество и надёжность, и отказываться тратить на что-либо ещё.
8.1 Семантическое кэширование — вызов, которого не случилось
Семантическое кэширование превращает повторяющийся вопрос в сохранённый ответ, даже когда формулировка изменилась. Механизм эмбеддит входящий запрос, ищет ближайших соседей в бакете, ограниченном тенантом и ролью, и отдаёт сохранённый ответ, если сосед в пределах порога сходства и в окне свежести. Сделанное правильно — оно убирает целый модельный вызов из пути запроса. Сделанное неправильно — отдаёт ответ чужого тенанта текущему пользователю или ответ из политики, поменявшейся ночью. Корректность держится на составных ключах — тенант плюс роль плюс модель плюс версия промпта, а не только эмбеддинг запроса, — и на периодических refresh-проходах, ловящих дрейф. Hit rate сам по себе — неправильная цель; cost-weighted hit rate на верифицированно корректных ответах — правильная, потому что высокий hit rate на дешёвых запросах и низкий на дорогих приносит меньше, чем обратное.
8.2 Rate limiting и динамическая маршрутизация моделей
Per-request-лимиты — неверная форма для LLM-трафика, потому что стоимость запроса варьируется на два порядка по флоту. Token bucket-ы и долларовые бюджеты с двухфазным reserve-and-settle заменяют per-request-счёт; слоистая иерархия бюджетов — пользователь, тенант, приложение, глобально — ограничивает радиус взрыва на каждом уровне. Маршрутизация затем выбирает наименьшую достаточную модель под каждый запрос. Классификатор — эвристика для простых случаев, дешёвый LLM-вызов для трудных — маркирует запрос и диспатчит в cost-tiered-флот с валидированной цепочкой фолбэков: SLM сначала, средний tier при валидационном отказе или низкой уверенности, фронтир на дальнейший фолбэк, детерминированный дефолт в самом низу. Сам роутер несёт trust-импликации — это решенческая поверхность, которой атакующий может попытаться манипулировать, — и он принадлежит внутрь трассируемого, оцениваемого, охраняемого конверта, который построили предыдущие главы.
8.3 Внутри inference-сервера
Под приложением inference-сервер — то место, где живёт последний порядок величины экономии стоимости. PagedAttention относится к KV-кэшу как к виртуальной памяти, так что смешанный батч длинных и коротких запросов больше не тратит непрерывную память на самый длинный. Continuous batching держит GPU занятым на heterogeneous-длинах, впуская новые запросы в текущий батч, а не ожидая, пока все закончатся. Speculative decoding использует маленькую draft-модель для угадывания токенов, которые целевая модель верифицирует параллельно, умножая эффективную пропускную способность на тех токенах, где draft угадал. Prefix caching хранит KV-состояние общего статического промпта между пользователями, так что системный промпт оплачивается один раз и переиспользуется. Квантизация роняет прецизию весов, не заметно влияя на качество на большинстве задач. LoRA-serving даёт одной базовой модели обслуживать многие fine-tuned варианты почти за стоимость базовой. Дистилляция ужимает саму модель. Эти оптимизации композируются друг над другом, и их кумулятивный эффект — то, что сделало суверенные self-hosted-развёртывания финансово жизнеспособными в 2026-м.
Что закрывает глава 8 и что идёт дальше
Глава 8 закрывает том V. Инженерия одного приложения, которую построила книга, — детерминированная обёртка, модельный вызов, retrieval-конвейер, цикл агента, оценочный набор, слой трассировки, постура безопасности, экономика serving-а, — это единица композиции для того, что следует дальше. Том VI, Масштабирование LLM-систем, берёт эту единицу как данность и задаёт следующий набор вопросов: что происходит, когда одна организация запускает сотню таких систем на общем inference-кластере, как fleet-wide policy-движок авторизует между ними, как меняется capacity-планирование, когда нагрузка бёрстовая, а железо в дефиците, и как оптимизации inference-сервера, набросанные в этой главе, становятся глубокой инженерией, когда они и есть load-bearing-поверхность. Том VI уходит в механику; том V установил словарь, которым эта механика будет пользоваться.
Том V здесь заканчивается. Следующий том серии — LLM Primer VI — Масштабирование LLM-систем (Scaling AI Systems) — подхватывает инженерию инференса и инфраструктуры, которую глава 8 только набросала, и относится к единице «приложение», построенной в этом томе, как к примитиву для fleet-scale-композиции.
