Kuis terkait panduan · Keras Tingkat
Kuis Pengelompokan Berkelanjutan
Terapkan pengelompokan LLM tingkat iterasi, batas kapasitas, dan pengorbanan pra-pengisian, termasuk mengapa menerima permintaan secara terus-menerus tidak menjamin tidak ada waktu menunggu.
Pertanyaan 1 dari 8
Apa kelemahan utama batching statis (tetap) untuk penyajian LLM?
Pratinjau setiap pertanyaan8 pertanyaan
Jawaban dan penjelasan muncul saat Anda mengikuti kuis.
- Apa kelemahan utama batching statis (tetap) untuk penyajian LLM?
- Itu hanya dapat berjalan di CPU
- Ini memerlukan pelabelan semua data terlebih dahulu
- Permintaan pendek selesai lebih awal tetapi slotnya menganggur sementara batch menunggu yang terlama
- Hal ini membuat model menjadi kurang akurat
- Pada tingkat perincian apa batching berkelanjutan menambah dan menghapus permintaan?
- Sekali sehari
- Per langkah decoding (satu token pada satu waktu)
- Hanya per permintaan penuh
- Per periode pelatihan
- Permintaan pengelompokan berkelanjutan selesai dan mengosongkan kapasitas. Apa yang dapat dilakukan penjadwal selanjutnya?
- 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 mana yang berpasangan secara alami dengan pengelompokan berkelanjutan untuk membuat urutan penyisipan/penghapusan menjadi murah?
- Cache KV berbasis blok PagedAttention
- Presisi ganda FP32
- Pertukaran disk
- Pelabelan data manual
- Makalah penelitian apa yang umumnya dianggap mempopulerkan batching tingkat iterasi (kontinu)?
- Kertas Transformer asli
- Makalah Orca
- Makalah database tahun 1980-an
- Makalah 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