Тест, свързан с ръководство · трудно Ниво
Тест за непрекъснато пакетиране
Прилагайте 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
- Документ за база данни от 80-те години
- Хартията на 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