Вікторина, пов’язана з посібником · важко Рівень
Тест безперервного пакетування
Застосовуйте пакетування 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 подвійна точність
- Заміна диска
- Ручне маркування даних
- Якій дослідницькій роботі зазвичай приписують популяризацію (безперервного) пакетування на рівні ітерації?
- Оригінальний папір трансформер
- Папір Orca
- Стаття бази даних 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