Test legat de ghid · Greu Nivel
Chestionar pe lot continuu
Apply iteration-level LLM batching, capacity limits, and prefill tradeoffs, including why admitting requests continuously does not guarantee zero waiting.
Întrebare 1 de 8
Care este principala slăbiciune a loturilor statice (fixe) pentru servirea LLM?
Previzualizează fiecare întrebare8 întrebări
Răspunsurile și explicațiile apar pe măsură ce susțineți testul.
- Care este principala slăbiciune a loturilor statice (fixe) pentru servirea LLM?
- Poate rula doar pe procesoare
- Este nevoie de etichetarea tuturor datelor mai întâi
- Solicitările scurte se termină mai devreme, dar sloturile lor sunt inactive, în timp ce lotul așteaptă cel mai lung
- Face modelul mai puțin precis
- La ce grad de granularitate adaugă și elimină solicitările în loturi continue?
- O dată pe zi
- Per pas de decodare (un jeton la un moment dat)
- Doar la cerere completă
- Pe epocă de antrenament
- 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
- Ce tehnică se asociază în mod natural cu dotarea continuă pentru a face inserarea/eliminarea secvențelor ieftine?
- Cache-ul KV bazat pe blocuri de la PagedAttention
- FP32 dublă precizie
- Schimbarea discurilor
- Etichetarea manuală a datelor
- Ce lucrare de cercetare este în mod obișnuit creditată cu popularizarea loturilor (continue) la nivel de iterație?
- Hârtia originală Transformer
- Hârtia Orca
- O hârtie de bază de date din anii 1980
- Hârtia 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