Quiz lié à un guide · Difficile Niveau
Quiz sur le traitement par lots continu
Appliquez le traitement par lots LLM au niveau de l'itération, les limites de capacité et les compromis de pré-remplissage, notamment pourquoi l'admission continue des demandes ne garantit pas une attente nulle.
Question 1 de 8
Quelle est la principale faiblesse du traitement par lots statique (fixe) pour le service LLM ?
Prévisualisez chaque question8 des questions
Les réponses et les explications apparaissent au fur et à mesure que vous répondez au quiz.
- Quelle est la principale faiblesse du traitement par lots statique (fixe) pour le service LLM ?
- Il ne peut fonctionner que sur des processeurs
- Cela nécessite d'abord d'étiqueter toutes les données
- Les requêtes courtes se terminent plus tôt mais leurs emplacements sont inactifs pendant que le lot attend la plus longue.
- Cela rend le modèle moins précis
- À quelle granularité le traitement par lots continu ajoute-t-il et supprime-t-il des requêtes ?
- Une fois par jour
- Par étape de décodage (un jeton à la fois)
- Par demande complète uniquement
- Par époque de formation
- 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
- Quelle technique s'associe naturellement au traitement par lots continu pour rendre l'insertion/suppression de séquences bon marché ?
- Cache KV basé sur des blocs de PagedAttention
- FP32 double précision
- Échange de disque
- Étiquetage manuel des données
- Quel document de recherche est généralement reconnu pour avoir popularisé le traitement par lots au niveau itératif (continu) ?
- Le papier Transformer original
- Le papier Orca
- Un article de base de données des années 1980
- Le document 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