Глава 46. Caching, batching, streaming, distillation, fine-tuning

В сервисе разбора обращений один и тот же справочник тарифов занимал 18 тысяч входных токенов. Его отправляли заново с каждым тикетом. Ночная переиндексация шла синхронными запросами, а оператор ждал полный ответ, хотя первые слова были готовы через секунду. Команда собиралась обучать свою модель. Сначала она перестала оплачивать собственную небрежность.

Это стандартный порядок событий. Fine-tuning обсуждают на второй неделе, кэш префикса включают на восьмой, а разница в счёте между этими двумя решениями отличается примерно на порядок — в пользу того, которое делается за день.

Пять разных инструментов

Кэширование экономит повторный ввод. Оно работает, когда стабильный префикс запроса байт-в-байт одинаков: system prompt и справочники ставят первыми, пользовательские данные последними. Кэш ответа уместен только для детерминированных, обезличенных запросов; ключ обязан включать tenant, версии prompt, модели и корпуса.

Batch API снижает цену фоновой работы ценой задержки. Для ночной классификации каталога это хороший обмен, для чата поддержки нет. Streaming почти не меняет стоимость и полное время выполнения, зато уменьшает time to first token. Пользователь видит начало ответа, но сервер всё равно должен пережить обрыв соединения и сохранить итог.

Distillation переносит поведение дорогой модели в более дешёвую на размеченном наборе. Fine-tuning закрепляет формат, стиль или узкую классификацию. Ни один из них не добавляет свежих фактов: для этого нужен retrieval. Обучать модель потому, что prompt неудобно поддерживать, довольно дорогой способ не чинить prompt. К тому же после дообучения промпт никуда не денется: он просто станет невидимым, зашитым в веса, и его нельзя будет отревьюить.

Практический каркас

from hashlib import sha256
import json
 
def cache_key(*, tenant: str, prompt_version: str, model: str, payload: dict) -> str:
    body = json.dumps(payload, sort_keys=True, ensure_ascii=False)
    raw = f"{tenant}:{prompt_version}:{model}:{body}"
    return sha256(raw.encode()).hexdigest()
 
async def answer(req):
    key = cache_key(tenant=req.tenant_id, prompt_version="support-v12",
                    model=settings.STRONG_MODEL, payload=req.model_dump())
    if cached := await redis.get(key):
        return cached
    result = await generate(req)
    await redis.set(key, result, ex=900)
    return result

Схема выбора проста:

повторяется вход?        -> prompt cache
ответ можно переиспользовать безопасно? -> response cache
результат терпит часы?   -> batch
важно быстро показать начало? -> streaming
много размеченных примеров и стабильная задача? -> distillation/fine-tuning

Порядок, в котором это стоит делать

Механизмы дают очень разную отдачу на вложенный день работы. Порядок такой:

1. Перестать отправлять лишнее. Разбивка токенов по категориям (глава 18) показывает, что треть входа не нужна. Это бесплатно и не требует ничего, кроме внимания.
2. Кэш стабильного префикса. День работы: переставить блоки так, чтобы неизменная часть шла первой, и включить кэширование у провайдера.
3. Роутинг моделей. Дешёвая модель на простых случаях (глава 45).
4. Batch для фоновых задач. Пара дней, включая переделку джоб на асинхронный забор результатов.
5. Streaming. Не про деньги, а про ощущение скорости.
6. Distillation и fine-tuning. Недели работы, отдельный набор данных, отдельный процесс обновления и повторные замеры качества после каждой смены модели.

Начинать с шестого пункта — распространённая ошибка, потому что он самый интересный. Инженерное удовольствие и экономический эффект здесь расположены в противоположных концах списка.

Что ломается

Кэш без версии возвращает ответ старого prompt. Общий ключ показывает данные соседнего tenant. Streaming создаёт иллюзию успеха, хотя генерация оборвалась после первого абзаца. Batch-задачи теряются без собственного job id и сверки результатов. Fine-tuning деградирует после смены входных документов, а команда спорит с моделью вместо проверки drift.

Правило: сначала измерьте повтор, допустимую задержку и стоимость ошибки. Выбирайте механизм по найденному ограничению, а не по моде.

Чеклист главы

• Измерена доля стабильного префикса в реальных запросах; неизменная часть стоит первой.
• Кэш ответов включён только там, где переиспользование безопасно; ключ содержит tenant, версии prompt, модели и корпуса.
• Смена версии промпта или модели автоматически инвалидирует кэш; есть тест.
• Фоновые задачи, терпящие часы, переведены в batch; у каждой есть свой job id и сверка результатов.
• Streaming не считается ускорением: измерены отдельно time to first token и полное время.
• Обрыв соединения при streaming не теряет результат: он сохраняется на сервере.
• Distillation и fine-tuning рассматриваются после исчерпания дешёвых мер и требуют своего набора данных и процесса обновления.
• Для дообученной модели есть регулярная проверка drift на свежих данных.
• Каждый механизм выбран по измеренному ограничению: повтор, допустимая задержка, стоимость ошибки.

Практикум

Задача 46.1 — что именно вы оплачиваете дважды. ⭑⭑

Возьмите сто реальных вызовов и найдите, за что вы платите повторно.

Критерии приёмки:

• Посчитаны: доля общего префикса, число кандидатов на безопасный response cache, доля задач с допустимой задержкой больше часа.
• Реализован один механизм из найденных и измерены p50/p95 latency, стоимость успешного результата и качество на прежнем eval-наборе.
• Смена версии промпта подтверждённо инвалидирует старый кэш.
• Показано, что кэш не пересекает границы tenant; есть тест с двумя арендаторами.
• Написан вывод: сколько стоило внедрение и за сколько дней оно окупается.

Подсказки:

1. Долю общего префикса считайте по фактическим строкам запроса, а не по шаблону: разница в мелочах вроде подстановки даты в начало.
2. Один механизм за итерацию: иначе вы не узнаете, что именно сработало.

Задача 46.2 — batch для ночной работы. ⭑⭑⭑

Переведите одну фоновую задачу на batch-обработку.

Критерии приёмки:

• Задача выбрана по измеренной допустимой задержке, а не по удобству.
• У каждой отправки есть собственный идентификатор и сверка «отправлено — получено — обработано».
• Потерянная или частично выполненная пачка обрабатывается: есть тест на пропавший результат.
• Замерена экономия и время выполнения до и после.
• Описано, что произойдёт, если batch не успеет к утру, и это поведение реализовано.

Подсказки:

1. Сверка по числу записей обязательна: тихая потеря части пачки — самый незаметный отказ.
2. Если задача внезапно перестала терпеть часы, это продуктовое изменение, а не техническое: зафиксируйте его явно.