Викторина, связанная с руководством · Жесткий Уровень
Непрерывная пакетная викторина
Применяйте пакетную обработку LLM на уровне итерации, ограничения емкости и компромиссы перед заполнением, в том числе, почему непрерывный прием запросов не гарантирует нулевое ожидание.
Вопрос 1 из 8
В чем основной недостаток статической (фиксированной) пакетной обработки для обслуживания LLM?
Предварительный просмотр каждого вопроса8 вопросы
Ответы и пояснения появляются по мере прохождения теста.
- В чем основной недостаток статической (фиксированной) пакетной обработки для обслуживания LLM?
- Он может работать только на процессорах
- Требуется сначала пометить все данные
- Короткие запросы завершаются раньше, но их слоты простаивают, пока пакет ожидает самый длинный запрос.
- Это делает модель менее точной.
- С какой степенью детализации непрерывная пакетная обработка добавляет и удаляет запросы?
- Один раз в день
- За шаг декодирования (по одному токену за раз)
- Только по полному запросу
- За эпоху обучения
- A continuous-batching request finishes and frees capacity. What can the scheduler do next?
- Restart every remaining request from its first token
- Guarantee every queued request runs immediately
- Discard the finished answer without returning it
- Admit eligible queued work if its resource budgets allow
- Какой метод естественным образом сочетается с непрерывной пакетной обработкой, чтобы удешевить вставку/удаление последовательностей?
- Блочный KV-кеш PagedAttention
- FP32 двойной точности
- Замена диска
- Маркировка данных вручную
- Какой исследовательской работе обычно приписывают популяризацию пакетной обработки на уровне итерации (непрерывной)?
- Оригинальная бумага Трансформер.
- Бумага Орка
- Документ о базе данных 1980-х годов
- Документ ImageNet
- What utilization problem can continuous batching reduce compared with a fixed request batch?
- Every model accuracy error
- The need to store any KV cache
- All queueing at any traffic rate
- Waiting for the longest request before admitting new eligible work
- A continuous-batching server has reached its memory budget. Must a newly arrived request enter the next iteration?
- No; admission can wait until suitable capacity is available
- Yes; the name guarantees unlimited request admission
- Yes; the server removes all active outputs automatically
- Only if the request has no punctuation
- A long prompt’s prefill delays tokens for already decoding requests. Which serving objective exposes that tradeoff?
- Measure only the weight-file name
- Assume more admitted prompts always improve every latency
- Measure time between decode tokens alongside throughput
- Count only the number of model layers