Пакетная обработка через LLM API: очереди, batching, checkpoints и контроль

Batch - это отдельный продуктовый режим, а не большой цикл for

Интерактивный запрос оптимизируется под секунды и обратную связь пользователю. Пакетная задача оптимизируется под throughput, стоимость, воспроизводимость и восстановление после сбоя. Архив из тысяч документов может обрабатываться часами, но каждая запись должна иметь наблюдаемый статус и повторяемый результат.

Простой цикл, который читает файл и вызывает API, ломается на первом rate limit или рестарте. Production-конвейер знает, какие записи подготовлены, отправлены, приняты, завершены, проверены и опубликованы.

Какие задачи подходят для пакетной обработки LLM

Проверяйте актуальные endpoints, окна выполнения, квоты, модели и поддерживаемые функции в документации провайдера: условия batch API меняются.

Три режима: sync, очередь и managed Batch API

Managed batch удобен для автономных записей, но может не поддерживать tool calling, multi-turn или отдельные форматы. Собственная очередь сложнее, зато позволяет маршрутизировать модели и выполнять промежуточную бизнес-логику.

Архитектура конвейера из восьми состояний

1. Discover. Найти eligible records.
2. Prepare. Нормализовать и редактировать данные.
3. Validate input. Проверить schema и размер.
4. Submit. Создать job идемпотентно.
5. Monitor. Получить событие или проверить статус.
6. Reconcile. Сопоставить outputs с record_id.
7. Validate output. Schema, бизнес-правила и quality checks.
8. Publish. Записать принятый результат атомарно.

Каждый переход фиксируется отдельно. Рестарт worker продолжает с подтверждённого состояния, а не создаёт партию заново.

Единица работы должна быть независимой

Record - минимальная запись, которую можно безопасно повторить и проверить отдельно: документ, карточка товара, фрагмент разговора или eval-case. Не объединяйте несвязанные объекты в один prompt ради экономии, если затем невозможно понять, какой элемент вызвал ошибку.

• record_id стабилен между перезапусками;
• source_version фиксирует исходные данные;
• tenant и data_class известны до отправки;
• input_hash обнаруживает изменение;
• expected_schema_version задаёт контракт;
• output не выполняет side effect автоматически.

Manifest превращает партию в воспроизводимый объект

batch_id: batch_2027_01_07_a
purpose: product_category_backfill
source_snapshot: catalog_2027_01_07T00Z
record_count: 12500
model_alias: classifier_stable
model_resolved: provider/model/version
prompt_version: category_v8
schema_version: CategoryResultV3
input_uri: object://private/batches/...
input_sha256: ...
created_by: pipeline_identity
policy_version: ai-data-v5
max_budget: configured_amount

Manifest не содержит секретный ключ. Он связывает данные, код и конфигурацию и позволяет объяснить, почему две партии дали разные результаты.

JSONL удобен, но каждая строка остаётся контрактом

Многие batch API принимают JSONL: один JSON-объект на строку. Добавляйте уникальный custom_id или recordId, по которому результат сопоставляется с источником. Не полагайтесь на порядок строк в output.

Версионируйте модель, prompt, schema и данные вместе

Имя «основная модель» недостаточно для воспроизводимости. Сохраняйте resolved model identifier, параметры sampling, system instructions, шаблон, schema, код постобработки и snapshot входа. Alias удобен для эксплуатации, но в trace должна быть конкретная версия.

Идемпотентность нужна на submit и publish

Повтор запроса создания job не должен создавать вторую платную партию, а повтор consumer не должен дважды записывать результат. Dedup key можно строить из tenant, purpose, source_version, record_id, prompt_version и model version.

record_key = SHA256(
  tenant + purpose + record_id + source_version
  + prompt_version + schema_version + resolved_model
)

submit: create batch only if manifest_key is new
publish: upsert accepted output by record_key
side effect: separate approval + idempotency key

Checkpoint хранит подтверждённое состояние

Checkpoint - не номер последней строки в локальном цикле. Он хранит состояние каждой записи или устойчивого shard: prepared, submitted, succeeded, failed_retryable, failed_terminal, validated, published. Обновление checkpoint и результата выполняется атомарно либо через transactional outbox.

• Не отмечайте shard готовым до проверки всех outputs.
• Храните provider job ID и output URI.
• Отдельно учитывайте отсутствующие строки.
• Повторно запускайте только незавершённые records.
• Сохраняйте причину terminal failure.

Sharding ограничивает blast radius

Одна гигантская партия дольше проверяется и сложнее повторяется. Разбейте датасет на shards по допустимому размеру, tenant, data class, приоритету и модели. Не смешивайте клиентов: это упрощает доступ, удаление и расследование.

Backpressure начинается до LLM

Если downstream validator или база публикует медленнее, чем приходят outputs, новый input нельзя принимать бесконечно. Используйте bounded queues, concurrency pools, приоритеты и admission control. Скорость регулируется самым медленным обязательным этапом.

Квоты многомерны: RPM недостаточно

Планировщик учитывает requests per minute, tokens per minute, максимальный размер файла, число записей, одновременные jobs, context limit, output limit и внутренний бюджет. Лимиты и доступность моделей зависят от провайдера, региона и аккаунта - проверяйте документацию перед запуском.

• Предварительно оценивайте input tokens по shard.
• Резервируйте worst-case output budget.
• Не запускайте все shards одновременно.
• Оставляйте запас под интерактивный трафик.
• Разделяйте quotas по tenant и приоритету.

Retry применяется к записи, а не ко всей партии

После завершения job сформируйте reconciliation report: success, retryable error, terminal error, missing result и duplicate result. Повторяйте только retryable records с ограниченным числом попыток и общим deadline. Ошибка schema или запрещённый input обычно требует исправления, а не backoff.

Статус Completed не означает, что все результаты пригодны

Job может завершиться, хотя часть строк содержит errors или не проходит вашу schema. Сначала проверьте уникальность и полноту ID, затем синтаксис, schema, бизнес-инварианты, ссылки на источники и task quality. Accepted result - отдельное состояние.

Quality gate сочетает автоматику и выборочную проверку

Для извлечения проверяйте типы, обязательные поля, диапазоны и consistency с источником. Для классификации используйте размеченный eval-set и confusion matrix. Для суммаризации проверяйте faithfulness и критичные факты. Ручная выборка должна быть стратифицирована по tenant, типу документа, confidence и ошибкам.

Безопасность данных охватывает весь жизненный цикл

Пакет часто создаёт несколько копий данных: snapshot, JSONL, provider storage, output и логи. Минимизируйте поля до prepare stage, редактируйте PII, шифруйте storage, ограничивайте service role и задавайте retention. Не помещайте raw prompt и output в обычные application logs.

• Отдельный bucket или prefix на environment и tenant.
• Least privilege для submitter и consumer.
• Короткоживущие credentials.
• Encryption и управляемые ключи по политике.
• Audit событий чтения и выгрузки.
• Lifecycle deletion для input и output.
• Проверка региона обработки и условий провайдера.

Экономика считается на принятую запись

Цена inference - только часть TCO. Добавьте подготовку, storage, network, retries, validation, ручную проверку и исправление ошибок. Managed batch может иметь иной тариф; актуальную скидку и условия всегда проверяйте на странице цен сервиса.

cost_per_accepted_record = (
  model_input + model_output + storage + orchestration
  + retry_cost + automated_validation + human_review
  + failure_remediation
) / accepted_records

Track separately:
submitted, completed, schema_valid, quality_accepted, published.

Наблюдаемость связывает job и каждую запись

Dashboard на уровне job показывает status, возраст, число shards и расход. Уровень record нужен для расследования: record_id, hashes, версии, attempts, error_code, token usage, validation result и publish version. Не используйте только среднее время: следите за p95 completion age и самым старым элементом.

Canary проверяет данные, а не только код

Перед полной партией выберите небольшую репрезентативную выборку: разные языки, длины, форматы, tenants, редкие классы и известные плохие входы. Пройдите весь путь до staging-публикации. Сравните качество и экономику с предыдущей стабильной версией.

1. Dry-run только prepare и validation.
2. Canary inference на репрезентативном sample.
3. Ручная проверка критичных сегментов.
4. Автоматические regression gates.
5. Один production shard.
6. Пауза для проверки метрик.
7. Постепенное расширение concurrency.

План восстановления должен существовать до запуска

Определите, как продолжить после падения control database, истечения provider job, повреждения output, изменения source record и отзыва согласия на обработку. Immutable input и manifest позволяют повторить inference; idempotent publish - безопасно перечитать outputs.

Production-чек-лист пакетной обработки LLM