連続バッチ処理クイズ

クイズに答えると、答えと解説が表示されます。

1. LLM サービスの静的 (固定) バッチ処理の主な弱点は何ですか?
   • CPU上でのみ実行可能
   • 最初にすべてのデータにラベルを付ける必要があります
   • 短いリクエストは早く終了しますが、バッチが最も長いリクエストを待機している間、スロットはアイドル状態になります。
   • モデルの精度が低くなります
2. 連続バッチ処理ではリクエストの追加と削除はどの程度の粒度で行われますか?
   • 1日1回
   • デコード ステップごと (一度に 1 つのトークン)
   • 完全なリクエストごとにのみ
   • トレーニング エポックごと
3. 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
4. シーケンスの挿入/削除を安価にするために、連続バッチ処理と自然に組み合わせられる手法はどれですか?
   • PagedAttendant のブロックベースの KV キャッシュ
   • FP32倍精度
   • ディスクの交換
   • 手動でのデータラベル付け
5. 一般に、反復レベル (連続) バッチ処理の普及に貢献したと考えられている研究論文は何ですか?
   • オリジナルのトランスフォーマー用紙
   • オルカ紙
   • 1980 年代のデータベース論文
   • ImageNet 論文
6. 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
7. 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
8. 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