Inference serving
Результат главы
После главы вы сможете:
- описать полный model artifact contract, а не только weights;
- выбрать embedded, dedicated или managed serving;
- считать упрощённый latency/memory budget для batching;
- объяснить trade-offs quantization;
- спроектировать shadow/canary, monitoring, degrade и rollback.
Model file ещё не сервис
Production artifact должен связывать:
- model weights/graph и checksum;
- input/output schema;
- tokenizer/feature pipeline;
- label taxonomy;
- calibration и thresholds;
- training dataset/version/provenance;
- code/runtime dependency versions;
- supported hardware;
- offline evaluation report;
- owner, expiry и rollback target.
Если classifier обновился, а router остался на старом порядке labels, endpoint может быть быстрым и полностью неверным.
Три topology
| Вариант | Получаем | Платим | Плохой выбор, когда |
|---|---|---|---|
| Embedded in app | Минимальный network hop | App memory/deploy coupled | Большой/shared/GPU model |
| Dedicated inference service | Independent scaling/versioning | Network и ops complexity | Один маленький CPU model |
| Managed provider endpoint | Быстрый старт | Cost, data boundary, vendor limits | Нужен strict control/edge/offline |
Public interface должен оставаться provider-neutral: classify_intent, transcribe_audio, rank_documents, а не название serving vendor.
Serving request contract
{
"request_id": "req-42",
"tenant_id": "trusted-runtime-value",
"model_alias": "intent-router-stable",
"schema_version": "1",
"inputs": ["Где мой заказ?"],
"deadline_ms": 80
}
Response содержит model version, prediction, calibrated confidence, threshold/decision, timings и typed failure. Tenant/access metadata не берётся из model-generated arguments.
Latency — распределение, не среднее
Разделяйте:
- queue latency;
- preprocessing;
- transfer/serialization;
- model compute;
- postprocessing/policy;
- end-to-end p50/p95/p99;
- cold start и steady state.
Среднее скрывает tail. Для voice p95 может определять ощущение разговора; для batch backfill важнее throughput/cost.
Batching trade-off
Batching обычно повышает utilization/throughput, но ожидание соседних requests и большой batch увеличивают latency/memory. Упрощённый Helios calculator использует консервативную модель:
batch_count = ceil(pending_requests / batch_size)
batch_latency = fixed_latency + per_item_latency × batch_size
estimated_tail = batch_count × batch_latency
peak_memory = model_memory + per_item_memory × batch_size
Это не hardware profiler и не queueing theory. Это hand-computable admission check, заставляющий явно задать budgets. Решение:
serve— requested batch помещается;degrade— меньший batch помещается;reject— ни один batch не проходит latency+memory.
NVIDIA Triton — один vendor-specific пример: его dynamic batcher объединяет stateless requests и позволяет ограничить delay/queue. Это не универсальная рекомендация и не зависимость курса; измеряйте конкретную модель на конкретном hardware.
Backpressure, admission и degrade
Когда очередь растёт, бесконечное ожидание хуже typed refusal. Runtime задаёт:
- max queue size;
- request deadline;
- priority/fairness;
- cancellation;
- maximum batch wait;
- retry ownership;
- degraded route.
Примеры degrade:
- уменьшить batch;
- перейти на меньшую model version;
- отключить expensive reranking;
- вернуть cached safe answer;
- передать request человеку/в async queue;
- reject с retry-after вместо timeout storm.
Quantization
Quantization отображает weights/activations в меньшую числовую разрядность. Возможный выигрыш — размер, memory bandwidth и hardware throughput. Возможная цена — quality loss, unsupported operators и conversion/debug complexity.
| Вид | Когда параметры вычисляются | Trade-off |
|---|---|---|
| Dynamic | Activation scale во время inference | Проще, но есть runtime overhead |
| Static post-training | На calibration dataset заранее | Быстрее, чувствительно к representativeness |
| Quantization-aware training | Ошибка учитывается при training | Больше training complexity |
| Mixed precision | Часть операций остаётся точнее | Hardware/graph-specific tuning |
ONNX Runtime прямо предупреждает: quantization не lossless и иногда ухудшает производительность на неподходящем hardware. Поэтому сравнивайте original и optimized artifact на одном golden dataset и target device.
Shadow и canary
Shadow: новая версия не влияет на action. Проверяем prediction disagreement, slices, latency и resource profile.
Canary: небольшая доля реального traffic влияет на outcome. Нужны version correlation, kill switch и автоматические/ручные rollback conditions.
Не путайте application deployment health с model quality: pod может быть healthy, пока macro F1 или wallet false accepts деградировали.
Monitoring
Четыре слоя:
| Слой | Signals |
|---|---|
| Service | availability, queue, p95/p99, memory, saturation |
| Model | class/score distribution, abstain, disagreement |
| Data | schema errors, missing fields, drift slices |
| Product | correct route, successful outcome, escalation, harm/cost |
Labels часто приходят с задержкой. Поэтому proxy signals полезны, но не заменяют delayed ground truth и human review sample.
Rollback contract
Rollback unit включает:
- model artifact;
- preprocessing/tokenizer;
- label mapping;
- threshold/calibrator;
- service image/config;
- compatible client schema;
- migration state, если он есть.
Перед canary проверьте, что предыдущий immutable bundle доступен и может загрузиться на текущем hardware. «Мы храним старый .pkl» недостаточно.
Helios и реальные аналоги
Helios intent classifier мал и может жить рядом с runtime. Speech/large reranker могут стать отдельными services с собственным batching. В neobank external decision endpoint требует строгого deadline и fallback; в telehealth voice path важнее turn latency и безопасный human handoff, чем максимальный throughput.
Лаборатория
cd examples/helios_ml
uv run --frozen python scripts/profile_serving.py
Default scenario возвращает degrade: batch 4 превышает memory budget, batch 3 укладывается в memory 160 MB и даёт conservative tail estimate 48 ms для последнего request в текущей очереди. Это не статистический p95; p95 измеряется на распределении реального traffic.
Эксперименты:
- Поставьте
--memory-budget-mb 200: почему решение сталоserve? - Поставьте latency budget ниже fixed latency: почему корректен
reject? - Добавьте queue wait в формулу и новый hand-computable test.
- Составьте immutable bundle manifest для intent artifact.
- Запишите canary rollback condition по quality и отдельно по service health.
Self-check
- Версионируются ли preprocessing и labels вместе с weights?
- Где измеряются queue и end-to-end latency?
- Каков max queue и кто владеет retry?
- Batching оптимизируется под throughput или под p95?
- Quantized artifact проверен на target hardware и golden data?
- Shadow не влияет на action?
- Canary имеет kill switch и immutable rollback bundle?
- Есть безопасный degrade/reject outcome?
Источники
Проверено 2026-08-30: