Kuiz berkaitan panduan · Keras Tahap
Kuiz Berkelompok Berterusan
Gunakan batching LLM peringkat lelaran, had kapasiti dan tukar ganti praisi, termasuk sebab penerimaan permintaan secara berterusan tidak menjamin sifar menunggu.
soalan 1 daripada 8
Apakah kelemahan utama batching statik (tetap) untuk sajian LLM?
Pratonton setiap soalan8 soalan
Jawapan dan penjelasan muncul semasa anda mengambil kuiz.
- Apakah kelemahan utama batching statik (tetap) untuk sajian LLM?
- Ia hanya boleh berjalan pada CPU
- Ia memerlukan pelabelan semua data terlebih dahulu
- Permintaan pendek selesai lebih awal tetapi slot mereka melahu sementara kumpulan menunggu yang paling lama
- Ia menjadikan model kurang tepat
- Pada butiran apakah pengumpulan berterusan menambah dan mengalih keluar permintaan?
- Sekali sehari
- Setiap langkah penyahkodan (satu token pada satu masa)
- Mengikut permintaan penuh sahaja
- Setiap zaman latihan
- 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
- Teknik yang manakah berpasangan secara semula jadi dengan batching berterusan untuk menjadikan urutan memasukkan/mengalih keluar murah?
- Cache KV berasaskan blok PagedAttention
- FP32 berketepatan ganda
- Penukaran cakera
- Pelabelan data manual
- Apakah kertas penyelidikan yang lazimnya dikreditkan dengan mempopularkan batching peringkat lelaran (berterusan)?
- Kertas Transformer asal
- Kertas Orca
- Kertas pangkalan data 1980-an
- Kertas 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