Κουίζ που συνδέεται με οδηγό · Σκληρό Επίπεδο
Κουίζ συνεχούς παρτίδας
Εφαρμόστε δέσμες LLM σε επίπεδο επανάληψης, όρια χωρητικότητας και αντισταθμίσεις προπλήρωσης, συμπεριλαμβανομένου του γιατί η συνεχής αποδοχή αιτημάτων δεν εγγυάται μηδενική αναμονή.
Ερώτηση 1 του 8
Ποια είναι η κύρια αδυναμία της στατικής (σταθερής) παρτίδας για την εξυπηρέτηση LLM;
Προεπισκόπηση κάθε ερώτησης8 ερωτήσεις
Οι απαντήσεις και οι εξηγήσεις εμφανίζονται καθώς κάνετε το κουίζ.
- Ποια είναι η κύρια αδυναμία της στατικής (σταθερής) παρτίδας για την εξυπηρέτηση LLM;
- Μπορεί να τρέξει μόνο σε CPU
- Απαιτεί πρώτα την επισήμανση όλων των δεδομένων
- Τα σύντομα αιτήματα ολοκληρώνονται νωρίς, αλλά οι θέσεις τους είναι αδρανείς ενώ η παρτίδα περιμένει για το μεγαλύτερο
- Κάνει το μοντέλο λιγότερο ακριβές
- Με ποια ευαισθησία προσθέτει και αφαιρεί αιτήματα η συνεχής ομαδοποίηση;
- Μία φορά την ημέρα
- Ανά βήμα αποκωδικοποίησης (ένα διακριτικό τη φορά)
- Μόνο ανά πλήρες αίτημα
- Ανά προπονητική εποχή
- 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 διπλής ακρίβειας
- Εναλλαγή δίσκου
- Χειροκίνητη επισήμανση δεδομένων
- Σε ποια ερευνητική εργασία αποδίδεται συνήθως η διάδοση της ομαδοποίησης σε επίπεδο επανάληψης (συνεχούς);
- Το αυθεντικό χαρτί Transformer
- Το χαρτί της Όρκας
- Έγγραφο βάσης δεδομένων της δεκαετίας του 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