Логи, метрики и трассировки, по которым можно восстановить, что произошло с конкретным запросом.
Ключевые тезисы
- Логируйте вход, версию модели, предсказание и время ответа — этого достаточно для 90% расследований.
- Трассировка сквозь сервисы показывает, где именно теряются миллисекунды.
- Сэмплирование логов при высокой нагрузке: полный лог может стоить дороже самой модели.
Подробный разбор
{"ts": "...", "request_id": "...", "model": "churn@2026-08-15",
"features_hash": "9f2c...", "features": {...}, "score": 0.183,
"latency_ms": 12, "fallback": false, "cache_hit": false}- логируются либо полностью, либо хешем + сэмплированием — в зависимости от объёма и требований к персональным данным.
- Метка (что произошло на самом деле) приезжает позже и джойнится по
request_id. - Именно эта пара « + метка» становится обучающей выборкой следующей версии.
- Трейс с спанами: получение , , постобработка — сразу видно узкое место.
- Гистограммы задержек, а не средние: по ним считаются перцентили.
- Метрики по версиям модели раздельно — иначе при канареечном выкате всё смешается.
- Алерты на рост доли фолбэков и на смещение распределения скоров.
Видеолекции
Тайм-кода именно на эту тему в записях нет. Но глава «Системный дизайн ML-сервисов» разобрана в курсах целиком — с той оговоркой, что место в записи придётся искать самому.
Связанные темы
Инференс и эксплуатация · Безопасная эксплуатация
Reliability96%
Отказоустойчивость · Системный дизайн ML-сервисовЧто происходит, когда модель недоступна, отвечает медленно или выдаёт мусор.
Monitoring96%
Мониторинг · MLOpsНаблюдение за инфраструктурой, данными и качеством предсказаний после релиза.
Requirements and SLA85%
Требования и SLA · Системный дизайн ML-сервисовЧисла, которые нужно зафиксировать до архитектуры: задержка, пропускная способность, доступность, стоимость запроса.
Serving Architecture85%
Архитектура инференса · Системный дизайн ML-сервисовМодель внутри приложения, отдельный сервис или платформа инференса — три уровня связанности.
Caching85%
Кеширование · Системный дизайн ML-сервисовНе считать то, что уже посчитано: кеш предсказаний, признаков и эмбеддингов.
Batching and Queues85%
Батчинг и очереди · Системный дизайн ML-сервисовСобирать запросы в пачки, чтобы загрузить GPU, и сглаживать всплески нагрузки очередью.
Scaling85%
Масштабирование · Системный дизайн ML-сервисовГоризонтальное и вертикальное масштабирование инференса и правильные метрики автоскейлинга.
GPU Inference85%
GPU-инференс · Системный дизайн ML-сервисовКак выжать из видеокарты пропускную способность и не переплачивать.
Cost Model85%
Экономика сервиса · Системный дизайн ML-сервисовСтоимость одного предсказания и точка, где модель перестаёт окупаться.
LLM Serving85%
Обслуживание LLM · Системный дизайн ML-сервисовОтдельная инженерная дисциплина: KV-кеш, непрерывный батчинг, потоковая отдача и контроль стоимости.
Model Deployment85%
Деплой моделей · MLOpsДоставка модели пользователю: онлайн-сервис, батч-скоринг или встраивание в приложение.
Docker85%
Docker · MLOpsКонтейнеризация фиксирует окружение целиком: код, зависимости, системные библиотеки.
Kubernetes85%
Kubernetes · MLOpsОркестрация контейнеров: масштабирование, самовосстановление, обновления без простоя.
Secure Inference75%
Защита инференса · Безопасность ИИПериметр вокруг работающей модели: что происходит с запросом до того, как он дойдёт до весов, и после того, как ответ получен.
AI Governance75%
Управление рисками ИИ · Безопасность ИИПроцесс вокруг модели: классификация риска, документация, контроль изменений и ответственность за решения.
Data Contracts75%
Контракты данных · Инженерия данныхЯвная договорённость между источником и потребителем: какие поля, каких типов и с какими гарантиями.
Профильная компетенция для роли: Продуктовый инженер.
Усиливает профиль: ML Engineer.
Спрашивают на собеседовании: Selectel — Платформа инференса.
Тема встречается в тестах по направлениям — ошибки приведут обратно на эту страницу.
Глава «Системный дизайн ML-сервисов» последний раз правилась . Нашли ошибку — напишите.