Инференс и сервинг LLM

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

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

1. #inference_serving1 / 5
   Латентность и пропускная способность (throughput) в сервинге LLM — это...

   A)Одно и то же понятие, просто названное двумя разными словами для маркетинга

   B)Throughput — это время ожидания пользователем до появления первого токена ответа

   C)Латентность — это сколько запросов в секунду обслужено системой

   D)разные цели: латентность — время на один запрос, throughput — запросов/токенов в секунду; и они конфликтуют

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

   +D)разные цели: латентность — время на один запрос, throughput — запросов/токенов в секунду; и они конфликтуют

   // разбор: Латентность — время на один запрос (важны time-to-first-token и время на токен), throughput — сколько запросов/токенов в секунду выдаёт система суммарно. Они в конфликте: большие батчи повышают throughput (GPU загружен), но каждый запрос ждёт дольше — латентность растёт. Онлайн-чат оптимизирует латентность, офлайн-обработка — throughput. Отсюда continuous batching как компромисс.

2. #inference_serving2 / 5
   Почему continuous (in-flight) batching эффективнее статического батчинга для LLM-сервинга?

   A)Он убирает потребность в дорогих специализированных GPU-ускорителях

   B)Новые запросы входят в батч по мере освобождения слотов, не ждя конца самых длинных генераций

   C)Он обеспечивает одинаковую длину всех ответов в батче

   D)Он отключает KV-cache ради экономии памяти

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

   +B)Новые запросы входят в батч по мере освобождения слотов, не ждя конца самых длинных генераций

   // разбор: В статическом батче запросы стартуют и финишируют вместе: короткие ответы ждут самый длинный, GPU простаивает, а новый запрос ждёт следующего батча. Continuous batching работает на уровне итераций: закончил один запрос — его слот тут же занимает новый из очереди. GPU держится загруженным, throughput и латентность под нагрузкой заметно лучше. Это ядро vLLM/TGI.

3. #inference_serving3 / 5
   Почему удвоение длины промпта бьёт по стоимости/латентности сильнее, чем линейно?

   A)Длина входного промпта на итоговую стоимость и латентность вообще никак не влияет в этом случае

   B)Стоимость зависит от числа выходных токенов, вход бесплатен

   C)Attention квадратичен по длине, а KV-cache растёт линейно и съедает память/батч

   D)Модель при длинном промпте просто откажется отвечать

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

   +C)Attention квадратичен по длине, а KV-cache растёт линейно и съедает память/батч

   // разбор: Стоимость определяют и входные, и выходные токены. Само внимание масштабируется квадратично по длине (каждый токен смотрит на все), так что длинный контекст дорожает быстрее линейного на этапе prefill. Плюс KV-cache растёт линейно с длиной и отъедает память, снижая максимальный батч → косвенно бьёт по throughput. Отсюда борьба за компактный контекст и эффективные attention-ядра.

4. #inference_serving4 / 5
   Что даёт speculative decoding?

   A)Автоматически без потерь уменьшает итоговый размер основной модели вдвое при её загрузке в память

   B)Ускоряет генерацию: draft-модель предлагает токены, большая проверяет их за один проход

   C)Повышает фактическую точность ответов за счёт двух независимых проходов по данным

   D)Расширяет контекст без дополнительных затрат памяти

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

   +B)Ускоряет генерацию: draft-модель предлагает токены, большая проверяет их за один проход

   // разбор: Декодирование по одному токену недоиспользует GPU (упор в память, не в вычисления). Speculative decoding: быстрая маленькая draft-модель угадывает сразу несколько следующих токенов, а большая модель верифицирует их одним параллельным проходом, принимая совпавший префикс. При хорошем угадывании — кратное ускорение без изменения распределения выходов (эквивалентно обычному). Качество и размер модели не меняются.

5. #inference_serving5 / 5
   Почему prefill (обработка промпта) и decode (генерация) по-разному грузят железо?

   A)Prefill считает все входные токены параллельно (compute-bound), а decode идёт по одному токену и упирается в память/пропускную KV-cache (memory-bound)

   B)Они идентичны по профилю нагрузки на GPU

   C)Prefill медленнее decode на длине промпта

   D)Decode не использует GPU вообще

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

   +A)Prefill считает все входные токены параллельно (compute-bound), а decode идёт по одному токену и упирается в память/пропускную KV-cache (memory-bound)

   // разбор: Prefill обрабатывает весь промпт за один проход — токены идут параллельно, GPU занят матричными умножениями (compute-bound), отсюда time-to-first-token растёт с длиной промпта. Decode генерирует по одному токену: на каждый шаг тянутся все веса и KV-cache при малом объёме вычислений — упор в пропускную способность памяти (memory-bound). Разный профиль объясняет, почему батчинг и spec-decoding бьют в decode, а длинный промпт — в prefill.