รวมหลายคำขอในรอบเดียว
จากหน้า 2: ทุกก้าวของ ขั้นเขียนคำตอบ (decode, decoding phase)ช่วงที่โมเดลเขียนคำตอบทีละ token แต่ละก้าวต้องรันโมเดลหนึ่งรอบ จึงช้ากว่าขั้นอ่าน prompt เมื่อคิดต่อ tokenดูคำศัพท์ทั้งหมด ต้องอ่านน้ำหนักทุกตัว เพื่อเขียน token เดียว
การ์ดสมมติอ่านหน่วยความจำได้ 1,000 GB ต่อวินาที โมเดล 16 GB จึงใช้ 16 มิลลิวินาที ต่อก้าว ได้ไม่เกิน 62.5 token/วินาที ต่อคน น้ำหนัก 4 บิต (4 GB) ใช้ 4 มิลลิวินาที เพดาน 250 token/วินาที
หน้า 2 สมมติแค่ 40 token/วินาที เพราะยังต้องอ่าน แคชคีย์และแวลู (KV cache)ที่เก็บ key และ value ของ token ที่คำนวณแล้วในทุกชั้น จะได้ไม่ต้องคำนวณซ้ำทุกครั้งที่เขียน token ใหม่ ยิ่งข้อความยาวยิ่งใช้หน่วยความจำมากดูคำศัพท์ทั้งหมด และงานอื่น
การรวมคำขอเป็นชุด (batching)การประมวลผลคำขอของหลายคนพร้อมกันในรอบเดียว อ่านน้ำหนักโมเดลครั้งเดียวแต่ได้ token ของหลายคน จึงได้ปริมาณงานรวมสูงขึ้นดูคำศัพท์ทั้งหมด คือใช้จังหวะที่ต้องอ่านน้ำหนักอยู่แล้ว คำนวณ token ของ 8 คนไปพร้อมกันในก้าวเดียว เหมือนรถรับส่งพนักงานรอบเดียวรับได้ทั้งคัน ตารางนี้สมมติว่าแชตสั้นจน KV cache ไม่ต้องนับ
| แบบ | มิลลิวินาที/ก้าว | token/วินาที ต่อคน | token/วินาที รวมทุกคน |
|---|---|---|---|
| 16 บิต, 1 คน | 16 | 62.5 | 62.5 |
| 16 บิต, 8 คน | 16 | 62.5 | 500 |
| 4 บิต, 1 คน | 4 | 250 | 250 |
แต่ทุกก้าวต้องอ่าน KV cache ของทุกคนด้วย 8 คน คนละ 8,000 token แคชรวม 8.39 GB ที่ 16 บิต ราวครึ่งของน้ำหนัก แชตยาวและคนเยอะจึงช้าลง และ 16.0 + 8.39 + 1 GB (ส่วนอื่นๆ) = 25.4 GB ก็เกินการ์ด 24 GB (หน้าถัดไป)
เซิร์ฟเวอร์จริงเพิ่มและเอาคำขอออกได้ทุกก้าว (continuous batching) งานรวมสูงขึ้น แต่ต่อคนช้าลงบ้าง
ตอนเขียนทีละ token และแชตยังสั้น เวลาส่วนใหญ่หมดไปกับการอ่านน้ำหนัก การรวมหลายคำขอเป็นชุดจึงได้ token ต่อวินาทีรวมสูงขึ้นมาก
มังคุด
รวมหลายคนในรอบเดียว คำตอบของหนูจะปนกับคนอื่นมั้ย?