Инференс, serving и стоимость

English · Русский · AI Interview Atlas › Темы

Обслуживание моделей в масштабе: prefill и decode, батчинг, кеширование, квантизация, метрики задержки и рычаги стоимости.

На этой странице: Оба трека (4) · AI-инженерия (14)

Оба трека

• Сервис может потратить больше вычислений на один reasoning-запуск или получить несколько кандидатов и проверить их. Как распределить бюджет при ограничении задержки?
  • Прикладной сценарий · 🧪 сгенерировано по темам вакансий · ✍ Ответ · Предложить правку
  • Что проверяет: Умение распределять вычисления по измеренной пользе для задачи с учётом расходов на проверку.
  • Сильный ответ покрывает:
    • Сравнить стратегии на одинаковых отложенных задачах, включая стоимость проверяющего и полную задержку.
    • Измерить успех по сложности задач и выбрать правило маршрутизации, которому не нужен правильный ответ.
    • Задать остановку и резервный сценарий; показать все расходы на успешную задачу и нарушения срока.
  • Читать: Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters (Snell et al., arXiv) · Evaluation best practices (OpenAI API documentation)
• Разграничьте time to first token, time per output token, inter-token latency и throughput при сравнении систем инференса.
  • Знания · Где спрашивали: Microsoft †, Perplexity † · ✍ Ответ · Предложить правку
  • Что проверяет: Умение отличать задержку для пользователя от совокупной пропускной способности.
  • Сильный ответ покрывает:
    • Определить TTFT как очередь плюс prefill, TPOT и inter-token latency как темп декодирования, throughput как ёмкость.
    • Объяснить, как больший батч обменивает скорость декодирования для пользователя на throughput и как prefill прерывает декодирование.
    • Сравнивать при одинаковой нагрузке и распределении длин: p50 и p99 по каждой задержке, throughput в пределах целей.
  • Читать: vLLM documentation (vLLM project)
• Как сравнить vLLM, SGLang, TensorRT-LLM и собственный runtime на конкретной нагрузке?
  • Прикладной сценарий · Предложить правку
  • Что проверяет: Умение выбирать по воспроизводимой нагрузке, а не общему рейтингу.
  • Сильный ответ покрывает:
    • Воспроизвести снятую нагрузку: реальные распределения длин промптов и ответов, характер поступления запросов, общие префиксы и параллельность.
    • Зафиксировать модель, точность, параллелизм и оборудование, честно настроить каждый движок и учесть стоимость сопровождения собственного runtime.
    • Сравнивать goodput — запросы в секунду в пределах SLO по TTFT и задержке между токенами — и совпадение выходов с базовой реализацией.
  • Читать: vLLM documentation (vLLM project) · DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving (Zhong et al., arXiv)
• Вам поручили снизить стоимость инференса на порядок. Расставьте меры по приоритету и объясните, как проверить достижимость цели.
  • Прикладной сценарий · Где спрашивали: Amazon †, Microsoft † · ✍ Ответ · Предложить правку
  • Что проверяет: Умение оценить экономию при явных ограничениях качества и задержки.
  • Сильный ответ покрывает:
    • Измерить стоимость успешной задачи при нужном качестве и SLO.
    • Сравнить меньшие модели, сокращение контекста, переиспользование, батчинг и точность.
    • Измерить каждое изменение и проверить, достигается ли цель в совокупности.
  • Читать: Optimizing inference (Hugging Face Transformers docs) · Site Reliability Engineering (Google)

AI-инженерия

• Запрос к reasoning API расходует токены, но не возвращает пригодный ответ. Как найти причину и организовать восстановление с ограниченным бюджетом?
  • Прикладной сценарий · 🧪 сгенерировано по темам вакансий · ✍ Ответ · Предложить правку
  • Что проверяет: Умение различать учёт токенов, статус завершения и бюджет повторов.
  • Сильный ответ покрывает:
    • Проверить статус, расход токенов, размер контекста и смысл выходного лимита у провайдера.
    • До восстановления отличить исчерпание лимита от ошибки инструмента, отказа и таймаута.
    • Ограничить попытки, расходы и полное время; измерять успех восстановления и исключать повторные действия инструментов.
  • Читать: Reasoning models (OpenAI API documentation)
• Сравните prefill и авторегрессионное декодирование: когда узким местом становятся вычисления, а когда пропускная способность памяти?
  • Знания · ✍ Ответ · Предложить правку
  • Что проверяет: Умение определять узкое место с учётом нагрузки и батча.
  • Сильный ответ покрывает:
    • Prefill обрабатывает позиции промпта параллельно, decode идёт авторегрессионно.
    • При малом батче decode часто читает веса и почти не переиспользует их в арифметике.
    • Профилировать длины и батчинг до вывода о вычислительном или memory-bound ограничении.
  • Читать: Optimizing inference (Hugging Face Transformers docs)
• Объясните батчинг на уровне итераций: как запросы добавляются в выполняющийся батч и покидают его?
  • Знания · Где спрашивали: Anthropic † · ✍ Ответ · Предложить правку
  • Что проверяет: Понимание связи планировщика с утилизацией, справедливостью и ожиданием.
  • Сильный ответ покрывает:
    • Добавлять последовательности на границах итераций и удалять завершённые.
    • Ограничивать токены и KV-память, а не только число запросов.
    • Измерять ожидание и голодание запросов наряду с throughput.
  • Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon et al., arXiv)
• Как страничная организация KV-кеша сокращает потери памяти и какие задачи остаются планировщику?
  • Знания · ✍ Ответ · Предложить правку
  • Что проверяет: Умение отличать управление памятью от планирования запросов.
  • Сильный ответ покрывает:
    • Объяснить фрагментацию при непрерывном выделении памяти под самый длинный возможный ответ.
    • Описать блоки фиксированного размера с таблицей косвенности и общие блоки между запросами.
    • Назвать нерешённое: приём, вытеснение и справедливость остаются политикой планировщика.
  • Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon et al., arXiv)
• Объясните точное speculative decoding, проверку предложенных токенов и случаи, когда draft-модель лишь добавляет накладные расходы.
  • Знания · ✍ Ответ · Предложить правку
  • Что проверяет: Понимание условий ускорения без универсальных обещаний.
  • Сильный ответ покрывает:
    • Малая модель предлагает несколько токенов для параллельной проверки целевой моделью.
    • Описать принятие и корректирующий сэмплинг, сохраняющие распределение целевой модели.
    • Оценить долю принятых токенов, стоимость draft и доступные параллельные вычисления.
  • Читать: Fast Inference from Transformers via Speculative Decoding (Leviathan et al., arXiv)
• Когда префикс промпта можно переиспользовать и какие изменения обесценивают или инвалидируют кеш?
  • Знания · ✍ Ответ · Предложить правку
  • Что проверяет: Учёт точного совпадения, срока жизни кеша и изоляции клиентов.
  • Сильный ответ покрывает:
    • Сформулировать условие переиспользования: одинаковый префикс токенов при той же модели и конфигурации.
    • Расположить промпт так, чтобы стабильная часть шла первой, а изменчивая — последней.
    • Ограничить срок жизни кеша и область записей, чтобы один клиент не читал префикс другого.
  • Читать: Prompt caching (Claude Platform Docs)
• Сравните форматы с плавающей точкой и целочисленные форматы вплоть до четырёх бит: как проверить допустимость снижения точности?
  • Знания · Предложить правку
  • Что проверяет: Умение сопоставить экономию памяти с качеством, ядрами и поддержкой оборудования.
  • Сильный ответ покрывает:
    • Сравнить неравномерную сетку FP8 и FP4 с равномерной сеткой INT8 и INT4 и масштабы по группам, без которых не обойтись при малой разрядности.
    • Отделить квантование только весов до 4 бит, ускоряющее memory-bound декодирование, от квантования активаций, которому нужны нативные ядра FP8 или INT8 на целевом GPU.
    • Сравнить с bf16 по задачным оценкам и KL на токен, отдельно на длинном контексте, коде и математике, затем измерить реальную пропускную способность.
  • Читать: QLoRA: Efficient Finetuning of Quantized LLMs (Dettmers et al., arXiv) · Optimizing inference (Hugging Face Transformers docs) · GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers (Frantar et al., arXiv) · SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models (Xiao et al., arXiv) · FP8 Formats for Deep Learning (Micikevicius et al., arXiv)
• Сравните tensor, pipeline, data, sequence и expert parallelism при развёртывании большой модели.
  • Знания · Где спрашивали: Amazon †, Google и Google DeepMind †, Meta † · Предложить правку
  • Что проверяет: Умение выбирать по обмену данными и ограничениям памяти.
  • Сильный ответ покрывает:
    • Назвать, что делит каждая схема и какой обмен добавляет: all-reduce в каждом слое у TP, активации между стадиями у PP, обмен KV у SP, all-to-all у EP.
    • Сначала уместить веса и KV: TP внутри NVLink-домена, PP между узлами, затем реплики data parallel без обмена ради пропускной способности.
    • Измерить запас памяти на GPU, долю обмена во времени шага, простои конвейера и перекос нагрузки экспертов при целевой задержке.
  • Читать: vLLM documentation (vLLM project) · Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity (Fedus et al., arXiv) · Efficiently Scaling Transformer Inference (Pope et al., arXiv) · Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism (Shoeybi et al., arXiv)
• Оцените память для обслуживания модели с 70 млрд параметров, явно задав точность, контекст и конкурентность.
  • Прикладной сценарий · ✍ Ответ · Предложить правку
  • Что проверяет: Умение учесть веса, кеш и запас памяти во время выполнения.
  • Сильный ответ покрывает:
    • Память весов — число параметров на байты на параметр, без метаданных квантования.
    • Добавить KV-память конкретной архитектуры для заданных параллельных последовательностей.
    • Заложить активации, рабочие буферы и запас аллокатора; явно указать шардирование.
  • Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon et al., arXiv)
• Постройте roofline-оценку декодирования модели 70B для одного запроса на H100; сначала проверьте, помещается ли выбранное представление.
  • Прикладной сценарий · Предложить правку
  • Что проверяет: Умение ограничить оценку пропускной способностью памяти, её объёмом и достижимой утилизацией.
  • Сильный ответ покрывает:
    • Сначала проверить, помещается ли модель: 70B в bf16 — около 140 ГБ, больше одной H100 на 80 ГБ; в FP8 почти не остаётся места под KV.
    • Сопоставить байты, читаемые на токен (все веса плюс KV), с примерно 2 FLOP на параметр: декодирование одного запроса упирается в пропускную способность памяти.
    • Ограничить число токенов в секунду достижимой, а не пиковой пропускной способностью HBM и сверить оценку с профилем реального запуска.
  • Читать: Efficiently Scaling Transformer Inference (Pope et al., arXiv)
• После релиза p99 задержки удвоился, хотя веса модели не менялись. Как локализовать причину?
  • Прикладной сценарий · Где спрашивали: Amazon †, Databricks †, OpenAI †, Perplexity † · ✍ Ответ · Предложить правку
  • Что проверяет: Умение разделить ожидание, планирование, зависимости и изменения трафика.
  • Сильный ответ покрывает:
    • Сравнить состав трафика, время в очереди и задержки этапов до и после релиза.
    • Проверить попадания в кеш, батчинг, хвосты зависимостей и насыщение ресурсов.
    • Проверять гипотезы по одной и подтвердить причинность откатом или canary.
  • Читать: The Tail at Scale (Dean and Barroso, Google Research)
• Почему разбиение prefill на части помогает смешанному трафику и какой компромисс задаёт размер части?
  • Знания · Предложить правку
  • Что проверяет: Совместный учёт пропускной способности и пауз декодирования.
  • Сильный ответ покрывает:
    • Объяснить паузу: длинный prefill занимает итерацию целиком, все идущие декодирования ждут, и задержка между токенами подскакивает.
    • Смешивать в итерации части prefill с decode в пределах бюджета токенов; мелкие части сглаживают decode, но растят TTFT и накладные расходы.
    • Перебрать бюджет токенов на итерацию на смешанном трафике и сопоставить p99 задержки между токенами с TTFT и пропускной способностью.
  • Читать: vLLM documentation (vLLM project) · Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve (Agrawal et al., arXiv)
• Когда стоит разделить prefill и decode между воркерами и как оценить накладные расходы передачи KV?
  • System design · Предложить правку
  • Что проверяет: Умение сопоставить независимое масштабирование со стоимостью передачи и эксплуатации.
  • Сильный ответ покрывает:
    • Разделять фазы, когда всплески prefill ломают SLO по задержке decode или фазам нужны разный параллелизм и оборудование.
    • Оценить передачу как байты KV на токен, умноженные на длину промпта и делённые на пропускную способность канала, с послойным перекрытием с prefill.
    • Сравнить goodput на GPU с совмещённой схемой и chunked prefill, учитывая хвост задержки передачи и перебалансировку числа воркеров.
  • Читать: vLLM documentation (vLLM project) · DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving (Zhong et al., arXiv)
• В первоначальном домашнем задании Anthropic для инженеров производительности, введённом в 2024 году и впоследствии снятом с использования, оптимизируйте последовательную программу для симулятора ускорителя с помощью многоядерного, векторного и инструкционного параллелизма.
  • Кодинг · Где спрашивали: Anthropic ✅ · Предложить правку
  • Что проверяет: Умение методично находить параллелизм и строить инструменты, чтобы измерять и отлаживать каждый шаг.
  • Сильный ответ покрывает:
    • Сначала обеспечить корректность: сверять каждый выход с последовательной версией и исправить имеющиеся ошибки до оптимизации.
    • Найти независимые итерации по зависимостям данных и разложить их по ядрам, SIMD-полосам и слотам инструкций за такт.
    • Измерять циклы симулятора после каждого изменения и по трассе инструкций искать простои и незанятые исполнительные блоки.
  • Читать: Designing AI resistant technical evaluations (Anthropic)

← Основы LLM · RAG и поиск →