Quiz połączony z przewodnikiem · Ciężko Poziom
Quiz dotyczący ciągłego dozowania
Zastosuj wsadowe LLM na poziomie iteracji, limity wydajności i kompromisy przed wypełnieniem, w tym dlaczego ciągłe akceptowanie żądań nie gwarantuje zerowego oczekiwania.
Pytanie 1 z 8
Jaka jest główna słabość statycznego (stałego) dozowania w przypadku obsługi LLM?
Podgląd każdego pytania8 pytania
Odpowiedzi i wyjaśnienia pojawiają się w miarę rozwiązywania quizu.
- Jaka jest główna słabość statycznego (stałego) dozowania w przypadku obsługi LLM?
- Może działać tylko na procesorach
- Wymaga to najpierw oznaczenia wszystkich danych
- Krótkie żądania kończą się wcześniej, ale ich przedziały są bezczynne, podczas gdy partia czeka na najdłuższy
- To sprawia, że model jest mniej dokładny
- Z jaką szczegółowością ciągłe przetwarzanie wsadowe dodaje i usuwa żądania?
- Raz dziennie
- Na krok dekodowania (jeden token na raz)
- Tylko na pełne żądanie
- Według epoki szkoleniowej
- 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
- Która technika łączy się naturalnie z ciągłym dozowaniem, aby sekwencje wstawiania/usuwania były tanie?
- Oparta na blokach pamięć podręczna KV PagedAttention
- Podwójna precyzja FP32
- Wymiana dysku
- Ręczne etykietowanie danych
- Jakiemu artykułowi badawczemu powszechnie przypisuje się spopularyzowanie (ciągłego) przetwarzania wsadowego na poziomie iteracji?
- Oryginalny papier Transformers
- Gazeta Orki
- Dokument bazodanowy z lat 80
- Artykuł 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