ML System Design: масштабирование и трейдофы

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 10, остальные разбираются в тренажёре.

1. #scaling_tradeoffs1 / 5
   Когда дистилляция/квантование модели — правильный ход, а когда преждевременный?

   A)Когда бюджет инференса нарушен и профиль указывает на узкое место в модели

   B)Дистилляция и квантование — якобы правильный ход: чем меньше модель, тем лучше

   C)Это оправдано лишь при разработке под мобильные приложения

   D)Не стоит: потеря качества при сжатии недопустима

   показать ответ и разбор

   +A)Когда бюджет инференса нарушен и профиль указывает на узкое место в модели

   // разбор: Порядок: профилировать end-to-end → убедиться, что модель и есть bottleneck → тогда int8-квантование (почти бесплатно по качеству), дистилляция в компактного ученика, ONNX/TensorRT. Инженерная зрелость — не оптимизировать то, что не болит: усложнение пайплайна имеет постоянную цену поддержки. Обратный кейс: LLM-инференс, где квантование — вопрос выживания бюджета сразу.

2. #scaling_tradeoffs2 / 5
   Чем латентность (latency) отличается от пропускной способности (throughput)?

   A)Это два близких названия для общей скорости работы сервиса

   B)Латентность — число запросов в секунду, throughput — время одного запроса

   C)Латентность — время одного запроса; throughput — запросов в секунду

   D)Латентность измеряется в байтах, а throughput — в секундах

   показать ответ и разбор

   +C)Латентность — время одного запроса; throughput — запросов в секунду

   // разбор: Латентность — задержка обработки одного запроса, throughput — сколько запросов система тянет в секунду. Это разные цели, часто в конфликте: батчинг запросов повышает throughput, но каждый запрос ждёт набора батча — латентность растёт. SLA обычно задаёт и то, и другое (например, P99-latency при целевом RPS).

3. #scaling_tradeoffs3 / 5
   Почему хорошая офлайн-метрика модели не гарантирует роста бизнес-метрики в проде?

   A)Офлайн меряет на прошлых данных; онлайн зависит от поведения юзеров и системы

   B)Офлайн-метрики качества модели не получится посчитать до запуска

   C)Онлайн-метрики в точности совпадают с офлайн-метриками модели

   D)Офлайн-качество и онлайн-эффект — это одно и то же, просто разные слова

   показать ответ и разбор

   +A)Офлайн меряет на прошлых данных; онлайн зависит от поведения юзеров и системы

   // разбор: Офлайн-метрика (AUC, точность) считается на исторической выборке в идеализированных условиях. В проде на бизнес-метрику влияют поведение пользователей, задержки, петли обратной связи и вся окружающая система — рост AUC не обязан двигать конверсию. Поэтому финальную ценность подтверждает только онлайн A/B-тест.

4. #scaling_tradeoffs4 / 5
   Ранжирующая модель стоит в критичном пути выдачи, но её сервис иногда таймаутит. Как проектировать деградацию?

   A)Фолбэк на дешёвую эвристику или кэш при таймауте — отдать разумную выдачу, а не ронять весь запрос

   B)Ретраить запрос к модели до успешного ответа, заблокировав отдачу страницы пользователю

   C)Поднять таймаут модели до нескольких секунд, чтобы она успевала ответить при пиковой нагрузке

   D)Убрать модель из выдачи после первого же её таймаута, чтобы подобная ситуация не повторялась

   показать ответ и разбор

   +A)Фолбэк на дешёвую эвристику или кэш при таймауте — отдать разумную выдачу, а не ронять весь запрос

   // разбор: Модель в критичном пути — источник отказа, поэтому проектируют graceful degradation: на таймаут отдают фолбэк (популярное, кэш прошлого ответа, простая эвристика), чтобы пользователь получил пусть худшую, но выдачу, а не ошибку. Бесконечные ретраи вешают запрос, задранный таймаут ломает SLA, а выключение модели убивает продукт. Деградация должна быть быстрой и предусмотренной.

5. #scaling_tradeoffs5 / 5
   Персональные подборки на главной пересчитываются на каждый заход и не укладываются в latency. Дёшевый приём?

   A)Просто увеличить таймаут ответа, чтобы пользователь дольше ждал подборку, но формально сервис при этом не падал под нагрузкой

   B)Кэшировать/предрасчитывать подборки для активных юзеров (ночью или по TTL) и отдавать готовые, обновляя фоном

   C)Убрать персонализацию и показывать всем пользователям один статичный список — якобы так и уложиться в latency

   D)Считать подборку ещё тяжелее, но зато сразу для всех пользователей на свете одним общим огромным запросом раз в сутки

   показать ответ и разбор

   +B)Кэшировать/предрасчитывать подборки для активных юзеров (ночью или по TTL) и отдавать готовые, обновляя фоном

   // разбор: Если подборка меняется не ежесекундно, её не обязательно считать синхронно на каждый заход: результаты предрассчитывают (батчем ночью или по расписанию) и/или кэшируют с TTL, отдавая готовое за миллисекунды, а обновляют фоново. Так тяжёлый расчёт уходит из критического пути запроса. Рост таймаута маскирует проблему, отказ от персонализации — потеря ценности, «тяжелее для всех» противоречит цели.