Инференс и обслуживание LLM
Квантизация, память KV-cache, спекулятивное декодирование, FlashAttention, continuous batching, стратегии декодирования, латентность против пропускной способности и стоимость обслуживания.
11 вопросов
JuniorТеорияОчень частоПочему prefill упирается в вычисления, а decode в пропускную способность памяти, и как это ложится на time-to-first-token?
Почему prefill упирается в вычисления, а decode в пропускную способность памяти, и как это ложится на time-to-first-token?
Prefill считает токены промпта параллельно большими матричными умножениями, поэтому решает арифметика и он задаёт time-to-first-token. Decode выдаёт по токену за проход, перечитывая все веса, поэтому решает память и задаёт задержку между токенами.
Типичные ошибки
- ✗Думают, что GPU с большими FLOPs починит медленный decode
- ✗Считают time-to-first-token и задержку между токенами одной метрикой
- ✗Забывают, что decode перечитывает все веса ради одного токена
Уточняющие вопросы
- →Почему батчинг повышает пропускную способность decode, но не улучшает задержку между токенами в одном потоке?
- →Как приём планировщика chunked prefill меняет time-to-first-token в обмен на ровность decode?
MiddleПроизводительностьОчень частоЧем continuous batching отличается от статического батчинга и почему пропускная способность резко растёт?
Чем continuous batching отличается от статического батчинга и почему пропускная способность резко растёт?
Статический батчинг фиксирует группу и держит все слоты до конца самой длинной последовательности, поэтому готовые строки простаивают, а новые ждут. Continuous batching планирует на каждом шаге decode — готовые уходят, новые приходят, и GPU загружен.
Типичные ошибки
- ✗Думают, что выигрыш даёт больший батч, а не планирование на каждом шаге
- ✗Считают паддинг до самой длинной последовательности безобидным
- ✗Ждут, что continuous batching снизит задержку одного запроса, а не поднимет пропускную способность
Уточняющие вопросы
- →Как планировщик выбирает между запуском нового prefill и продолжением decode?
- →Чего стоит вытеснение, когда бюджет KV заканчивается посреди батча?
JuniorТеорияЧастоЧто именно уменьшает квантизация INT8 или INT4, что она ускоряет и чем за это платят?
Что именно уменьшает квантизация INT8 или INT4, что она ускоряет и чем за это платят?
Она уменьшает число байт на вес — нужно меньше VRAM и меньше данных на каждый токен. Поэтому сильнее ускоряется decode, упирающийся в память, а не prefill, упирающийся в вычисления. INT8 по весам почти без потерь, INT4 отнимает точность.
Типичные ошибки
- ✗Ждут, что prefill ускорится так же сильно, как decode
- ✗Считают INT4 бесплатным — будто любая квантизация без потерь
- ✗Путают квантизацию с прунингом или дистилляцией
Уточняющие вопросы
- →Когда метод обучения quantization-aware training выигрывает у post-training quantization?
- →Почему квантизация KV-cache помогает иначе, чем квантизация весов?
JuniorПроизводительностьЧастоКак temperature, top-k и top-p меняют распределение при сэмплировании и что выставить для строгого JSON?
Как temperature, top-k и top-p меняют распределение при сэмплировании и что выставить для строгого JSON?
Temperature масштабирует логиты — низкая заостряет распределение, высокая сглаживает. Top-k оставляет k вероятнейших токенов, top-p — минимальный набор с массой p, с адаптивной шириной. Строгому JSON нужна temperature 0, творчеству — выше и top-p.
Типичные ошибки
- ✗Думают, что top-p — это top-k с набором кандидатов фиксированного размера
- ✗Ставят temperature 0 и ждут, что top-k или top-p всё ещё на что-то влияют
- ✗Верят, что одного фиксированного seed достаточно для воспроизводимости
Уточняющие вопросы
- →Что даёт ручка repetition penalty такого, чего не может temperature?
- →Почему батчинг ломает побитовую воспроизводимость даже при temperature 0?
MiddleПроизводительностьЧастоKV-cache упирается в память на длинном контексте — расставьте рычаги по тому, чего каждый стоит в качестве.
KV-cache упирается в память на длинном контексте — расставьте рычаги по тому, чего каждый стоит в качестве.
Сначала бесплатные рычаги — страничные блоки и общий префикс лишь убирают потери, а chunked prefill только перепланирует работу. Grouped-query attention бесплатен, если он уже в модели, квантизация KV в INT8 стоит немного, а обрезка контекста стоит качества и идёт последней.
Типичные ошибки
- ✗Хватаются за обрезку контекста раньше бесплатных рычагов памяти
- ✗Считают квантизацию KV в INT4 нейтральной для качества
- ✗Думают, что chunked prefill меняет то, что модель выдаёт
Уточняющие вопросы
- →Почему chunked prefill помогает не только памяти, но и хвостовой задержке?
- →Где кэширование общего префикса окупается сильнее всего в чат-нагрузке?
JuniorПроизводительностьИногдаПочему beam search стоит примерно в k раз дороже жадного декодирования и почему чат-модели его почти не используют?
Почему beam search стоит примерно в k раз дороже жадного декодирования и почему чат-модели его почти не используют?
Он держит k гипотез, поэтому на каждом шаге декодируются k последовательностей и хранятся k KV-cache — примерно в k раз больше вычислений и памяти. Чат-модели его избегают — максимизация правдоподобия даёт пресный текст без разнообразия.
Типичные ошибки
- ✗Думают, что beam search возвращает глобально оптимальную последовательность
- ✗Считают, что большее правдоподобие означает лучший ответ в чате
- ✗Забывают, что у каждого луча свой KV-cache
Уточняющие вопросы
- →Где beam search до сих пор уместен по умолчанию — например, в машинном переводе?
- →Как штраф за длину меняет то, что в итоге возвращает beam search?
MiddleПроизводительностьИногдаЯдро внимания FlashAttention считает точный результат — откуда тогда берётся ускорение и на чём именно экономия?
Ядро внимания FlashAttention считает точный результат — откуда тогда берётся ускорение и на чём именно экономия?
Это точное ядро, а не приближение. Оно разбивает запросы, ключи и значения на блоки в SRAM и использует бегущий softmax, поэтому полная матрица внимания не попадает в HBM. Экономится трафик памяти, а не FLOPs — часть работы даже пересчитывается.
Типичные ошибки
- ✗Называют FlashAttention приближённым или разреженным вниманием
- ✗Ждут, что счёт FLOPs уменьшится
- ✗Считают, что то же ускорение сохранится в режиме, где всё упирается в вычисления
Уточняющие вопросы
- →Почему приём с бегущим softmax сохраняет численно точный результат?
- →Какая часть выигрыша остаётся, когда батч уже упирается в вычисления?
MiddleПроизводительностьИногдаКакую фрагментацию KV-cache устраняет схема памяти PagedAttention и что она благодаря этому открывает?
Какую фрагментацию KV-cache устраняет схема памяти PagedAttention и что она благодаря этому открывает?
Буфер под максимальную длину на каждый запрос тратит впустую большую часть KV-cache — внутренняя и внешняя фрагментация. PagedAttention хранит кэш блоками за таблицей блоков, выделяя их по надобности, поэтому блоки можно делить между запросами и вытеснять.
Типичные ошибки
- ✗Путают страничное хранение KV со сжатием или квантизацией KV-cache
- ✗Думают, что таблица блоков лежит на критическом пути CPU
- ✗Упускают, что общий префикс может переиспользовать те же физические блоки
Уточняющие вопросы
- →Как разделение общего префикса между запросами переиспользует одни и те же блоки?
- →Что происходит, когда пул блоков исчерпан посреди decode?
MiddleПроизводительностьИногдаКак черновик и проверка сохраняют распределение целевой модели и когда спекулятивное декодирование перестаёт окупаться?
Как черновик и проверка сохраняют распределение целевой модели и когда спекулятивное декодирование перестаёт окупаться?
Черновая модель предлагает токены, целевая проверяет их одним параллельным проходом, правило отклонения принимает префикс и корректирует остаток — распределение выхода в точности целевое. Не окупается при низком принятии или на батче с упором в вычисления.
Типичные ошибки
- ✗Считают, что спекулятивное декодирование меняет качество на задержку
- ✗Ждут выигрыша при больших батчах, где GPU и так упирается в вычисления
- ✗Игнорируют, что плохо согласованный черновик может всё замедлить
Уточняющие вопросы
- →Как доля принятых токенов пересчитывается в сквозное ускорение?
- →Что меняется, если черновик берут из ранних слоёв самой целевой модели, а не из отдельной?
SeniorДизайнИногдаНужно обслуживать чат-модель на 70B параметров для 200 одновременных пользователей на арендованных GPU. Промпты в среднем 2000 токенов, ответы 300 токенов, продукт требует p95 сквозной задержки меньше двух секунд при потоковой выдаче. Бюджет фиксирован, трафик втрое выше в рабочие часы и почти исчезает ночью. Опишите схему обслуживания — в какой точности держите веса и KV-cache, как делите модель между GPU, какова политика батчинга и планирования, как считаете бюджет KV-cache под конкурентность и какой рычаг задержки дёргаете первым, когда p95 уплывает. Скажите, куда реально уходят деньги и что будете измерять, чтобы доказать, что схема держит.
Нужно обслуживать чат-модель на 70B параметров для 200 одновременных пользователей на арендованных GPU. Промпты в среднем 2000 токенов, ответы 300 токенов, продукт требует p95 сквозной задержки меньше двух секунд при потоковой выдаче. Бюджет фиксирован, трафик втрое выше в рабочие часы и почти исчезает ночью. Опишите схему обслуживания — в какой точности держите веса и KV-cache, как делите модель между GPU, какова политика батчинга и планирования, как считаете бюджет KV-cache под конкурентность и какой рычаг задержки дёргаете первым, когда p95 уплывает. Скажите, куда реально уходят деньги и что будете измерять, чтобы доказать, что схема держит.
Веса в INT8 или FP8, KV-cache в FP8, тензорный параллелизм — так, чтобы модель с бюджетом KV влезала с запасом. Обслуживают continuous batching поверх страничного KV, конкурентность ограничена бюджетом KV, а рычаги задержки исчерпывают до закупки GPU.
Типичные ошибки
- ✗Считают GPU только под веса и забывают про бюджет KV-cache
- ✗Оптимизируют среднюю задержку, когда требование задано по хвосту p95
- ✗Добавляют реплики раньше, чем чинят точность, батчинг и контроль допуска
Уточняющие вопросы
- →Как разделите двухсекундный бюджет между time-to-first-token и потоковым хвостом?
- →Что изменится, если трафик рваный, а не плавная суточная кривая?
SeniorДизайнИногдаПродукт тратит быстро растущие суммы на облачный LLM API, и руководство спрашивает, не пора ли хоститься самим. Сейчас трафик — 40 миллионов входных и 8 миллионов выходных токенов в месяц с удвоением каждый квартал, с резким дневным пиком и почти нулевой ночью. Требования к задержке умеренные, нагрузка смешанная — короткие реплики чата и длинные пересказы документов. Постройте модель стоимости для обоих вариантов — что нужно измерить на своём железе, чтобы получить защищаемую цифру долларов за миллион токенов, как складываются цена аренды GPU, достижимая скорость в токенах в секунду и реальная утилизация, и какие постоянные издержки цена API уже покрывает. Затем скажите, при каком объёме и условиях своё размещение выигрывает, чего оно стоит в инженерных силах и рисках и какой гибрид вы выкатите первым.
Продукт тратит быстро растущие суммы на облачный LLM API, и руководство спрашивает, не пора ли хоститься самим. Сейчас трафик — 40 миллионов входных и 8 миллионов выходных токенов в месяц с удвоением каждый квартал, с резким дневным пиком и почти нулевой ночью. Требования к задержке умеренные, нагрузка смешанная — короткие реплики чата и длинные пересказы документов. Постройте модель стоимости для обоих вариантов — что нужно измерить на своём железе, чтобы получить защищаемую цифру долларов за миллион токенов, как складываются цена аренды GPU, достижимая скорость в токенах в секунду и реальная утилизация, и какие постоянные издержки цена API уже покрывает. Затем скажите, при каком объёме и условиях своё размещение выигрывает, чего оно стоит в инженерных силах и рисках и какой гибрид вы выкатите первым.
Стоимость миллиона токенов — часовая цена GPU, делённая на реально выданные за час токены при настоящем батчинге и реальной утилизации, а не на пике. Своё размещение выигрывает только на большом ровном объёме — простой ночью и дежурство оплачиваются всегда.
Типичные ошибки
- ✗Берут пиковую скорость от вендора вместо измеренной при настоящем батчинге
- ✗Игнорируют ночной простой и считают часы GPU оплатой по потреблению
- ✗Забывают учесть инженерные силы, дежурство и оценку качества на стороне своего хостинга
Уточняющие вопросы
- →Какой гибрид выкатите первым — своё размещение под основной трафик и API под всплески?
- →Как смещается точка окупаемости, если нагрузка — длинные пересказы, а не короткие реплики чата?
