โทเค็นต่อวินาทีที่วัดโดย MLPerf คืออะไร และมีการใช้งานอย่างไรใน LLM?

คู่มือฮาร์ดแวร์ » มาตรฐาน » โทเค็นต่อวินาทีที่วัดโดย MLPerf คืออะไร และมีการใช้งานอย่างไรใน LLM?

หากคุณทำงานกับโมเดลภาษา คุณคงเคยได้ยินคำว่า "โทเค็นต่อวินาที" มาเป็นพันครั้งแล้ว แต่ไม่ค่อยมีใครอธิบายรายละเอียดเกี่ยวกับความหมายในสภาพแวดล้อมจริง และที่สำคัญที่สุดคือ MLPerf วัดค่านี้อย่างไร ในบทความนี้ เราจะอธิบายอย่างชัดเจนว่าโทเค็นคืออะไร เหตุใดเมตริกโทเค็นต่อวินาทีจึงมีความสำคัญอย่างยิ่งในการอนุมาน และแพลตฟอร์มอย่าง Databricks และเกณฑ์มาตรฐาน MLPerf ใช้เมตริกนี้เพื่อกำหนดขนาด เปรียบเทียบ และขยายขนาดอย่างไร นอกจากนี้ เรายังรวมตัวเลขเฉพาะจากผู้ผลิตและคลาวด์ไปจนถึงความคาดหวังด้านประสิทธิภาพภาคพื้นดินอีกด้วย.

ปัญหาไม่ใช่เรื่องเล็กน้อย: อุตสาหกรรมได้กำหนดมาตรฐานโทเค็นต่อวินาทีเพื่อประเมินประสิทธิภาพ LLM ในศูนย์ข้อมูลและที่ขอบข้อมูล MLPerf ซึ่งเป็นชุดโปรแกรม MLCommons ที่ได้รับการตรวจสอบโดยผู้เชี่ยวชาญ ได้กลายมาเป็นมาตรฐานในการเปรียบเทียบฮาร์ดแวร์และซอฟต์แวร์ในขณะเดียวกัน ผู้ให้บริการอย่าง Databricks ก็ได้จัดเตรียมจุดสิ้นสุดของโมเดลโดยตรงตามช่วงโทเค็นต่อวินาทีแล้ว ลองมาวิเคราะห์ทั้งหมดนี้ พร้อมตัวเลขและกรณีการใช้งาน

โทเค็นคืออะไร และเหตุใดจึงสำคัญในการเรียน LLM?

โมเดลภาษาไม่ประมวลผลตัวอักษรหรือคำแต่ละคำตามที่เป็นอยู่ แต่ทำงานด้วยหน่วยที่เรียกว่าโทเค็น โทเค็นโดยทั่วไปจะมีความยาวประมาณ 4 ตัวอักษร หรือเฉลี่ย 0,75 คำอัตราส่วนนี้จะแตกต่างกันไปขึ้นอยู่กับภาษาและตัวแบ่งโทเค็นของโมเดล แต่จะใช้เป็นตัวอ้างอิงอย่างรวดเร็ว: ข้อความ 10 คำจะย้ายโทเค็นได้ประมาณ 13–14 โทเค็น

การแบ่งส่วนที่แน่นอนขึ้นอยู่กับรุ่น: LLM แต่ละแห่งใช้ตัวแบ่งคำของตัวเองและแบ่งคำออกเป็นโทเค็นหรือคำย่อยที่สมบูรณ์เครื่องมือออนไลน์ช่วยให้คุณเห็นได้ เช่น วิธีที่ Llama สร้างโทเค็นวลีเฉพาะ ความแปรปรวนนี้ซึ่งดูเหมือนเป็นรายละเอียดเล็กๆ น้อยๆ มีอิทธิพลต่อค่าความหน่วงและต้นทุนการประมวลผล

เมื่อพูดถึงอัตราการสร้าง โดยปกติจะแสดงเป็นจำนวนโทเค็นต่อวินาที มากกว่าจำนวนคำต่อวินาที การดำเนินการนี้จะทำให้เมตริกเป็นเนื้อเดียวกันในทุกภาษา ความยาวบริบท และรูปแบบเอาต์พุตและช่วยให้คำนวณต้นทุนการอนุมานและความจุที่ต้องการได้อย่างแม่นยำ

เหตุใดจึงวัดประสิทธิภาพเป็นโทเค็นต่อวินาทีและไม่วัดเป็น RPS

บริการ API แบบดั้งเดิมมุ่งเน้นไปที่ RPS (จำนวนคำขอต่อวินาที) ใน LLM แนวทางดังกล่าวยังไม่เพียงพอ: คำขอสองคำขออาจใช้เวลาที่แตกต่างกันมาก ขึ้นอยู่กับโทเค็นอินพุตและโทเค็นเอาต์พุตนั่นคือ เพย์โหลดจริงมาในรูปแบบโทเค็น ไม่ใช่เป็น "จำนวนการโทร"

แหล่งที่มาหลักของความแปรปรวนมีอยู่สองประการ ประการแรกคือความยาวของบริบทอินพุต: ข้อความสั้นๆ อาจมีเพียงไม่กี่ข้อความ แต่เอกสารสรุปสามารถเพิ่มเป็นหลายร้อยหรือหลายพันรายการได้ในทางกลับกัน ความยาวของเอาต์พุต: การสรุปมักจะสร้างโทเค็นน้อยลง การสร้างบทความหรือคำอธิบายที่ยาวจะเพิ่มเวลา เนื่องจากการถอดรหัสเอาต์พุตเป็นส่วนที่มีราคาแพงที่สุด

ดังนั้น หากต้องการปรับขนาดจุดสิ้นสุดของการอนุมานได้อย่างสมจริง จำเป็นต้องคิดในแง่ของโทเค็น ตัวอย่างเช่น Databricks จัดเตรียมจุดสิ้นสุดการให้บริการด้วยโทเค็นจำนวนหนึ่งต่อวินาที และเรียกเก็บเงินเป็นรายชั่วโมงตามการปรับขนาดด้วยวิธีนี้ คุณสามารถปรับความจุให้สอดคล้องกับโหลดจริงได้โดยไม่ต้องถูกหลอกโดย RPS ที่ไม่ได้บอกเล่าเรื่องราวทั้งหมด

Databricks และ MLPerf วัดโทเค็นต่อวินาทีอย่างไร

Databricks นำ RAG จำนวนมากมาอ้างอิงและสรุปดังนี้: โทเค็นอินพุต 2048 รายการและโทเค็นเอาต์พุต 256 รายการโดยจะรวมทั้ง 1 เฟสเข้าด้วยกัน (การเติมล่วงหน้าและการถอดรหัส) และโดยค่าเริ่มต้น จะปรับสมดุลระหว่างปริมาณงานและเวลาแฝงให้เหมาะสมสำหรับขนาดชุดข้อมูล XNUMX ชุดต่อคำขอ โดยจำลองคำขอพร้อมกันหลายรายการ

ด้วยกฎนั้น ตัวเลขจะอ่านได้ดังนี้: หากคุณกำหนดค่าจุดสิ้นสุดที่ 2304 โทเค็นต่อวินาที (2048 + 256) การร้องขอขนาดนั้นใช้เวลาประมาณหนึ่งวินาทีหากคุณตั้งค่าไว้ที่ 5600 โทเค็นต่อวินาที คำขอเดียวกันจะลดลงเหลือประมาณ 0,5 วินาที และคุณสามารถประมวลผลคำขอที่คล้ายกันสองคำขอต่อวินาทีได้

เมื่อปริมาณงานของคุณเปลี่ยนแปลง ความหน่วงเวลาก็จะเปลี่ยนไปด้วย การสร้างโทเค็นเอาต์พุตมากขึ้นจะส่งผลเสียมากกว่าการเพิ่มโทเค็นอินพุตหากคุณกำลังทำการอนุมานแบบแบตช์ ให้คำนวณค่าเฉลี่ยจำนวนโทเค็นอินพุตและเอาต์พุตสำหรับชุดข้อมูลของคุณ และเปรียบเทียบกับเกณฑ์มาตรฐานก่อนหน้าเพื่อประมาณเวลา

ตัวอย่างเชิงปฏิบัติ: ด้วยแถว 1000 แถว โทเค็นอินพุตเฉลี่ย 3000 โทเค็นเอาต์พุต 500 โทเค็น และปริมาณงานที่รองรับ 3500 โทเค็นต่อวินาที จะใช้เวลามากกว่า 1000 วินาที เพราะค่าเฉลี่ยของคุณเกินค่าอ้างอิง แต่หากคุณเฉลี่ยอินพุต 1500 และเอาต์พุต 100 พร้อมการจัดเตรียมโทเค็น 1600 โทเค็นต่อวินาที คุณจะไปต่ำกว่า 1000 วินาที รวมทั้งหมด 1000 แถว

การปรับขนาดอัตโนมัติตามความต้องการและการคำนวณการปรับขนาดจริง

Databricks Model Serving รวมถึงการปรับขนาดอัตโนมัติอย่างรวดเร็ว เพิ่มหรือลดทรัพยากรตามความต้องการโทเค็นต่อวินาทีระบบจะปรับขนาดตามบล็อกความจุ และจะเรียกเก็บเงินเฉพาะความจุที่เพิ่มขึ้นเมื่อใช้งานจริงเท่านั้น ในการทดสอบที่มีคำขอแบบขนานมากขึ้น ปริมาณงานที่ได้รับการจัดสรรจะเพิ่มขึ้นจนกระทั่งคงที่ที่ประมาณ 8000 โทเค็นต่อวินาที เมื่อทรัพยากรเต็ม ส่งผลให้ความหน่วงในการเข้าคิวเพิ่มขึ้น

หากคุณสังเกตเห็นว่าโทเค็นมีน้อยกว่าที่คุณทำเครื่องหมายไว้ต่อวินาที ให้ตรวจสอบสองสิ่งนี้: จัดเตรียมการทำงานพร้อมกันที่สะท้อนถึงเมตริกจุดสิ้นสุดและขนาดแบนด์วิดท์ขั้นต่ำ กำหนดค่าแล้ว ด้วยข้อมูลนี้ การปรับขนาดจริงจะถูกประมาณโดยใช้สูตร: ความพร้อมทำงานพร้อมกันที่จัดเตรียมไว้ × ขนาดแบนด์วิดท์ขั้นต่ำ / 4

ตัวอย่างที่เป็นรูปธรรม: ด้วยจำนวนการทำงานพร้อมกันสูงสุดที่ 8 และขนาดแถบขั้นต่ำที่ 850 โทเค็นต่อวินาที ขีดจำกัดที่มีผลคือ 1700 โทเค็นต่อวินาที (8 × 850 / 4) การทำความเข้าใจการคำนวณนี้จะช่วยป้องกันไม่ให้เกิดเหตุการณ์ที่ไม่คาดคิด และช่วยให้คุณปรับแต่งการตั้งค่าให้ตรงกับค่า SLO ของเวลาแฝงได้

MLPerf Inference: คืออะไรและวัดอะไรในปัจจุบัน

MLPerf ซึ่งพัฒนาโดย MLCommons เป็นชุดโปรแกรมแบบเปิดและเป็นมาตรฐานสำหรับการวัดประสิทธิภาพ AI ในศูนย์ข้อมูลและเอจ ตั้งแต่วิสัยทัศน์ไปจนถึง LLM เป้าหมายคือการเปรียบเทียบแพลตฟอร์มในลักษณะที่ยุติธรรมและสามารถทำซ้ำได้เพื่อขับเคลื่อนประสิทธิภาพของระบบนิเวศในช่วงไม่กี่ปีที่ผ่านมา จุดเน้นได้เปลี่ยนไปสู่ ​​GenAI และ LLM ขนาดใหญ่ชัดเจน

ในรุ่นที่ 2 Llama 70 50B ได้รับการยกย่องให้เป็นเกณฑ์มาตรฐานดาวเด่น แทนที่ ResNetXNUMX และ เมตริกโทเค็นต่อวินาทีได้รับการปรับปรุงถึง 3,3 เท่าในกรณีที่ดีที่สุดในหนึ่งปีด้วยประสิทธิภาพเฉลี่ยที่สูงขึ้น 5 เท่าด้วยการปรับแต่งฮาร์ดแวร์และซอฟต์แวร์ การปรากฏตัวของ CPU อย่าง Intel Xeon 6 ในผลการทดสอบอย่างเป็นทางการยังแสดงให้เห็นว่า มีพื้นที่สำหรับโซลูชันทั่วไปที่มีประสิทธิภาพในสถานการณ์บางอย่าง.

MLPerf Inference เวอร์ชัน 5.1 ได้ก้าวไปอีกขั้นด้วยการรวมเกณฑ์มาตรฐานสำคัญใหม่ XNUMX รายการ การใช้เหตุผลกับ DeepSeek-R1 การแปลงคำพูดเป็นข้อความด้วย Whisper Large v3 และ LLM ขนาดเล็กที่อิงจาก Llama 3.1 8Bโดยรวมแล้ว กลุ่มได้รายงานผู้เข้าร่วม 27 ราย บรรลุผลลัพธ์ที่สำคัญ 90.000 รายการ และสามารถจำกัดค่าเมตริกเวลาแฝงในสถานการณ์แบบโต้ตอบได้

ตัวชี้วัดและวัตถุประสงค์ในเกณฑ์มาตรฐานใหม่

เกณฑ์มาตรฐานการใช้เหตุผลด้วย DeepSeek‑R1 ซึ่งเป็น MoE ของพารามิเตอร์ 671B แสดงให้เห็นว่า แบบจำลองเหล่านี้สร้างสายเหตุผลยาวๆ ก่อนที่จะได้คำตอบรองรับเอาท์พุตสูงสุด 20.000 โทเค็น โดยเฉลี่ย 3880 โทเค็นต่อเอาท์พุตในชุดข้อมูล ซึ่งถือเป็นการอนุมานที่ใหญ่ที่สุดจนถึงปัจจุบัน

กฎจะวัดปริมาณข้อมูลในโหมดออฟไลน์และโหมดเซิร์ฟเวอร์ด้วยขีดจำกัดที่เข้มงวด: เวลาถึงโทเค็นแรกคือ 2 วินาที และเวลาแฝงต่อโทเค็นคือ 80 มิลลิวินาทีที่ p99การดำเนินการนี้มุ่งหวังที่จะสร้างสมดุลระหว่างงบประมาณ "การคิด" กับการตอบสนองที่จำเป็นในการจัดสรรงบประมาณดังกล่าว

เกณฑ์มาตรฐาน LLM ขนาดเล็กที่มี Llama 3.1‑8B เข้ามาแทนที่ GPT‑J 6B ในฐานะเกตเวย์ รองรับบริบทสูงสุด 128.000 โทเค็น และประเมินผลการสรุปบน CNN-DailyMail ด้วยโทเค็นอินพุต 778 รายการ และโทเค็นเอาต์พุต 73 รายการ ความถูกต้องได้รับการตรวจสอบด้วย ROUGE และในดิวิชั่นปิด จำเป็นต้องตรงตามเกณฑ์มาตรฐานความแม่นยำสูง 99 เปอร์เซ็นต์

ในการวัดค่าความหน่วง จะมีการใช้ตัวบ่งชี้สองตัว ได้แก่ TTFT (เวลาถึงโทเค็นแรก) และ TPOT (เวลาต่อโทเค็นที่ออก) บนเซิร์ฟเวอร์ จะสังเกตเห็น TTFT 2 วินาทีและ TPOT 100 มิลลิวินาที (ประมาณ 480 ppm) และในสถานการณ์โต้ตอบใหม่ จะถูกบีบให้เหลือ 0,5 วินาทีและ 30 มิลลิวินาทีตามลำดับ (ประมาณ 1600 ppm) สำหรับกรณีเช่นการแชท การเขียนโค้ด หรือเครื่องมือสร้างสรรค์

ไฮไลท์ประสิทธิภาพโดยผู้ผลิตและผู้ปฏิบัติงาน

• NVIDIA นำอีกครั้ง คราวนี้ด้วย Blackwell Ultra บนระบบ GB300 NVL72 ทำคะแนนได้ บันทึกการใช้เหตุผลด้วย DeepSeek‑R45 ที่มีปริมาณงานมากกว่า GB1 NVL200 ถึง 72 เปอร์เซ็นต์โดยสามารถเข้าถึงโทเค็นได้ 5842 โทเค็นต่อวินาทีต่อ GPU แบบออฟไลน์และ 2907 โทเค็นบนเซิร์ฟเวอร์ โดยมีการปรับปรุงให้ดีขึ้นเกือบ 5 เท่าเมื่อเทียบกับ Hopper ที่ไม่ผ่านการตรวจสอบ
• ในการทดสอบประสิทธิภาพ Llama 3.1 405B แบบโต้ตอบใหม่ NVIDIA ได้ใช้ การให้บริการแบบแยกส่วนกับไดนาโมการแยกบริบทและการสร้างบน GPU ที่แตกต่างกันและการถ่ายโอน KV Cache ผ่าน NVLink ทำให้ได้ปริมาณงานต่อ GPU มากกว่าการให้บริการแบบเดิมบน Blackwell ถึง 1,5 เท่า และมากกว่าระบบที่มี Hopper ถึง 5 เท่า
• สำหรับรุ่นที่เล็กกว่า NVIDIA รายงานว่า มากกว่า 18.000 โทเค็นต่อวินาทีต่อ GPU บน Llama 3.1 8B ออฟไลน์ และ 5667 โทเค็นต่อวินาทีต่อ GPU ใน Whisper รักษาความเป็นผู้นำของ GPU ในทุกสถานการณ์ (ออฟไลน์ เซิร์ฟเวอร์ และแบบโต้ตอบ)
• AMD ขยายการปรากฏตัวด้วยการจัดส่ง GPU Instinct MI355X ครั้งแรก ซึ่งขณะนี้อยู่ในช่วง 2‑70B แสดงการปรับขนาดหลายโหนดและการเพิ่มขึ้นของโทเค็นต่อวินาที 2,7 เท่าเมื่อเทียบกับ MI325X ใน FP8ในการแบ่งแบบเปิด การตัดแต่งกิ่งแบบมีโครงสร้างใช้กับ Llama 3.1‑405B (FP4) เพิ่มปริมาณงานได้ 82 เปอร์เซ็นต์ด้วยแบบจำลองที่ตัดความลึกได้ 21 เปอร์เซ็นต์ และ 90 เปอร์เซ็นต์ด้วยแบบจำลองที่ปรับแต่งละเอียดขึ้น 33 เปอร์เซ็นต์, รักษาความแม่นยำ
• นอกจากนี้ยังเปิดตัวการจัดส่งใน Llama 2‑70B Interactive, Mixtral‑8×7B และ Stable Diffusion XL และนำเสนอผลลัพธ์ MI300X/MI325X แบบผสม: เมื่อปรับขนาดเป็น 4 โหนด MI355X บรรลุปริมาณงานมากกว่า MI3,4X ถึง 300 เท่าขยายได้ถึง 8 โหนดพร้อมความสามารถในการปรับขนาดที่ดี
• HPE ซึ่งรวม ProLiant และ Cray รายงานผลลัพธ์อันดับ 14 จำนวน 1 รายการ DL380a Gen12 โดดเด่นใน DLRM และ Llama 3.1‑8B (เซิร์ฟเวอร์) ในกลุ่มระบบ PCIe 8-GPU; DL385 Gen11 ทำเครื่องหมายประสิทธิภาพ GPU ที่ดีขึ้นใน Whisper ด้วย H200 NVL และ Cray XD670 (8× H200) ได้รับคะแนนสูงสุด 3.1 คะแนนใน RetinaNet, Llama 8‑6000B, Mixtral และ Whisper รวมถึงคะแนนสูงสุดจาก RTX Pro 200 Blackwell SE และผลการทดสอบ GH2 NVLXNUMX ใน DLRM
• CoreWeave เป็นระบบคลาวด์รายแรกที่รายงานผลลัพธ์ด้วย GB300 โดยส่งมอบ 6005 โทเค็นต่อวินาทีต่อ GPU ใน DeepSeek‑R1 ออฟไลน์และสาธิตการประสานงานและการปรับขนาดด้วย Slurm บน Kubernetes และการกำหนดเวลาที่คำนึงถึงโทโพโลยีเพื่อให้ได้รับประโยชน์สูงสุดจาก NVLink
• Dell จัดส่งระบบ 12 ระบบพร้อมตัวเร่งความเร็ว AMD และ NVIDIA ที่โดดเด่นใน LLaMA 2 70B Interactive พร้อม PowerEdge XE9680L และ B200 เซิร์ฟเวอร์ LLaMA 3.1‑8B บน XE9685L+B200, SDXL บน XE9685L และ Whisper บน XE9680L แสดงให้เห็นถึงความหลากหลายจากภาพไปจนถึงเสียงผ่าน LLM
• อินเทลย้ำว่ายังคงอยู่ เพียงหนึ่งเดียวที่จะส่งผลลัพธ์ด้วยซีพียูเซิร์ฟเวอร์ และแสดงให้เห็นว่า Xeon 6 ที่มี P-cores มีประสิทธิภาพดีขึ้น 1,9 เท่าเมื่อเทียบกับ Xeon รุ่นที่ 5 ในการทดสอบประสิทธิภาพ 8 ครั้ง ซึ่งตอกย้ำบทบาทในการอนุมานเชิงวัตถุประสงค์ทั่วไป นอกจากนี้ Xeon 60 ยังได้เปิดตัวเวิร์กสเตชันที่ใช้ GPU Arc Pro B192 จำนวน 2 ตัว พร้อม VRAM ขนาด 70GB เพื่อให้บริการ LlamaXNUMX-XNUMXB แก่ผู้ใช้หลายราย และรวมไดรเวอร์และเฟรมเวิร์กเข้าด้วยกันเพื่อให้การใช้งาน GPU หลายตัวง่ายขึ้น
• ในบรรดาผู้ผสานรวมและพันธมิตร ASUSTeK เพิ่มประสิทธิภาพเวลาแฝงและปริมาณงานด้วยการวัดปริมาณ เคอร์เนล และสแต็กBroadcom สาธิตการจำลองเสมือน VCF ด้วยค่าใช้จ่ายขั้นต่ำเมื่อเทียบกับการใช้ฮาร์ดแวร์เปล่าบนเวิร์กโหลดหลายรายการ (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet) Cisco ปรับขนาดได้เกือบเป็นเส้นตรงด้วย UCS C885A M8 (8× H200 SXM) และ UCS C845A M8 (8× H200 NVL หรือ L40S) ซึ่งรองรับโดยเครือข่าย One G200
• KRAI ใช้ OpenAI API และค่าใช้จ่ายจริงเพื่อเปรียบเทียบ SGLang และ vLLM กับ Llama3.1‑70B: 31.391 โทเค็นต่อวินาทีแบบออฟไลน์ด้วย SGLang 0.4.9 และ 26.319 ด้วย vLLM 0.9.2 บนเซิร์ฟเวอร์เดี่ยวที่มี H8 200x; ด้วยการหาปริมาณแบบไดนามิก มันถึง 27.697 ด้วย SGLang และ 30.893 ด้วย vLLM และบนหลายโหนด มันขยายขนาดได้ถึง 87.334 โทเค็นต่อวินาทีบนสามเซิร์ฟเวอร์
• แลมบ์ดาพร้อม 8x B200 180 GB SXM แสดงให้เห็นถึงการปรับปรุงปริมาณงาน สูงถึง 7 เปอร์เซ็นต์ใน SDXL และ 15 เปอร์เซ็นต์ใน Llama 3.1‑405B เมื่อเทียบกับรอบก่อนหน้า และนำเสนอคลัสเตอร์ตั้งแต่ 16 ถึง 1536 GPU พร้อมด้วย Kubernetes หรือ Slurm ที่ได้รับการจัดการ
• MiTAC พร้อมด้วยซีรีส์ G8825Z5 โดดเด่นในงาน LLaMA 2 70B Interactive ด้วย 18.846,1 โทเค็นต่อวินาที และผลลัพธ์ที่ดีในเซิร์ฟเวอร์และ Mixtral; Nebius รับรองประสิทธิภาพการทำงานเสมือนจริงเกือบเทียบเท่ากับโลหะเปล่าใน GB200 NVL72, HGX B200 และ HGX H200 ด้วย 596,11 โทเค็นต่อวินาทีบนเซิร์ฟเวอร์และ 855,82 โทเค็นออฟไลน์บน Llama 3.1‑405B พร้อม GPU GB4 จำนวน 200 ตัว
• Red Hat สาธิต vLLM เป็นรันไทม์ที่รองรับบน AI Inference Server พร้อมด้วย เคอร์เนล CUTLASS สำหรับ FP8 และ FlashAttention‑3 พร้อมด้วยเครื่องยนต์ vLLM v1 ที่ได้รับการปรับปรุง ขับเคลื่อน Llama‑3.1‑8B ใน H100 และ L40S ด้วยอัตราส่วนต้นทุนต่อประสิทธิภาพที่ยอดเยี่ยม
• Supermicro โพสต์ผลลัพธ์ชั้นนำด้วย HGX‑B200 8‑GPU (อากาศและของเหลว) กับ CPU ของทั้ง Intel และ AMD โดยเน้นที่ Llama 3.1‑8B และ Llama 2‑70B บนเซิร์ฟเวอร์/ออฟไลน์/แบบโต้ตอบ และ Whisperในการทำงานร่วมกัน แสดงให้เห็นการปรับขนาดที่ยอดเยี่ยมด้วย 32× H100‑SXM และทางเลือกอื่นด้วย MI325X
• Vultr เปิดตัวพร้อมกับ Supermicro AS‑8126GS‑TNMR และ 8x MI325X รับรองประสิทธิภาพการแข่งขันในฐานะ GPU บนคลาวด์; GATEOverflow ส่งเสริมการทำซ้ำได้ด้วย MLCFlow บน RTX 4090 และ CPU AMD/Intel; Giga Computing จัดส่งระบบระบายความร้อนด้วยอากาศ EPYC+MI8X และ Xeon+HGX B325 ขนาด 200U; QCT ครอบคลุมการกำหนดค่า Xeon 6 ด้วย H200 NVL (4 GPU) และแพลตฟอร์ม H8 SXM200 จำนวน 5× พร้อมด้วย NVLink และ GPUDirect Storage นอกเหนือจากระบบ MI8X จำนวน 325×

สถาบันการศึกษาก็มีช่วงเวลาสำคัญเช่นกัน มหาวิทยาลัยฟลอริดาที่มี DGX B200 SuperPOD ที่ผสานรวมกับ HiPerGator เป็นสถาบันแรกที่ส่งผลการอนุมาน การตอบสนองความหน่วงของเซิร์ฟเวอร์ภายใต้การแบ่งพาร์ติชันแบบปิด การใช้ Apptainer โดยไม่มี Docker/Sudo และการปรับให้เข้ากับ SLURM แบบหลายผู้ใช้ ในทางตรงกันข้าม การส่งเพียงครั้งเดียวบน MacBook Pro M1 ด้วย ONNX Runtime และ CoreML บน GPU และ Neural Engineเกินเป้าหมายความแม่นยำในประเภทขอบและแสดงให้เห็นว่าสามารถประเมินการอนุมานคุณภาพได้บนฮาร์ดแวร์ของผู้บริโภค

ความเร็วที่ผู้ใช้รับรู้และขีดจำกัดในทางปฏิบัติ

ประสบการณ์ของผู้ใช้ไม่ได้วัดกันแค่เกณฑ์มาตรฐานเท่านั้น แต่ในชีวิตประจำวัน ความรู้สึกลื่นไหลเกิดขึ้นเมื่อคุณเกินเกณฑ์โทเค็นที่กำหนดต่อวินาทีผู้ใช้รายหนึ่งแสดงความเห็นว่าขีดจำกัดการสนทนาของพวกเขาคือ 4 โทเค็นต่อวินาที และสำหรับการเขียนเรื่องราวนั้นอยู่ที่ประมาณ 10 โทเค็นต่อวินาที หากต่ำกว่านั้น การโต้ตอบจะรู้สึกช้า

หากคุณพยายามรัน LLM ในเครื่อง มีความจริงอยู่สามประการ บน CPU เดสก์ท็อป การเคลื่อนที่ 1–2 โทเค็นต่อวินาทีถือเป็นเรื่องปกติเป็นไปไม่ได้สำหรับคำตอบที่ยาว ด้วย GPU สำหรับการเล่นเกมระดับไฮเอนด์ คุณจะได้รับโทเค็นเกือบ 5 โทเค็นต่อวินาที ด้วย NVIDIA H100 ใช่แล้ว เรากำลังพูดถึง 60 โทเค็นต่อวินาทีอยู่แล้ว แต่เป็นฮาร์ดแวร์ศูนย์ข้อมูล ไม่ใช่ฮาร์ดแวร์เดสก์ท็อป.

เกิดอะไรขึ้นบ้างในระบบคลาวด์? ผู้ให้บริการที่ทรงประสิทธิภาพที่สุดกำลังเอาชนะตัวเลขเหล่านี้ได้ด้วยฮาร์ดแวร์เฉพาะทางและสแต็กอนุมานที่ปรับแต่งให้เหมาะสม มีรายงานค่าเฉลี่ยประมาณ 119 โทเค็นต่อวินาทีบน ChatGPT‑4 และ 168 บน Geminiในขณะที่โมเดลโอเพนซอร์สยอดนิยมอย่าง DeepSeek อยู่ที่ประมาณ 21 โทเค็นต่อวินาที หากแปลงเป็นคำ 119 โทเค็นต่อวินาทีจะเท่ากับประมาณ 90 คำต่อวินาที

ข้อสรุปการดำเนินการ: สำหรับผู้ใช้ส่วนใหญ่ การรัน AI บนคอมพิวเตอร์เป็นไปได้ แต่ไม่สามารถทำได้จริงเนื่องจากความล่าช้าการทำงานด้วยความเร็วที่สบายและมีเวลาแฝงที่จำกัดนั้น บริการที่ได้รับการจัดการจึงถือเป็นตัวเลือกที่สมเหตุสมผล

วิธีกำหนดขนาดจุดสิ้นสุดของคุณตาม TPS และสิ่งที่คาดหวังจากเวลาแฝง

ขั้นตอนปฏิบัติในการกำหนดขนาด ขั้นแรก ให้สรุปกรณีการใช้งานของคุณ: จำนวนโทเค็นอินพุตและเอาต์พุตโดยเฉลี่ย การกระจายความยาว และความพร้อมกันที่คาดหวังประการที่สอง ให้รันการทดสอบโหลดด้วยชุดข้อมูลตัวแทน ซึ่งเกี่ยวข้องกับ TTFT และโทเค็นต่อวินาทีที่ยั่งยืนต่อคำขอ

ขั้นต่อไป ให้ปรับการกำหนดค่าให้สอดคล้องกับรูปแบบของคุณ หากเวิร์กโหลดของคุณคล้ายกับการอ้างอิง Databricks (2048 เข้า 256 ออก) เลือกช่วงโทเค็นต่อวินาทีเพื่อให้คำขออยู่ในงบประมาณเวลาแฝงที่ต้องการโปรดจำไว้ว่าการทำซ้ำเอาต์พุตมักมีค่าใช้จ่ายมากกว่าการทำซ้ำอินพุต และการทำงานพร้อมกันที่มีประสิทธิผลจะขึ้นอยู่กับการปรับขนาดอัตโนมัติจริง

ตรวจสอบและปรับแต่ง คอยจับตาดูตัวชี้วัด ความพร้อมในการทำงานพร้อมกันที่จัดเตรียมไว้ คิว TTFT และ TPOTและเปรียบเทียบกับ SLO ของคุณ หากคุณมีความจุไม่เพียงพอ ให้ขยายช่วง หากคุณมีทรัพยากรเหลือ ให้ลดขนาดลงและปรับบล็อกเพื่อบันทึก สูตรการปรับขนาดที่แท้จริงจะช่วยให้คุณเข้าใจสาเหตุที่จุดสิ้นสุดไม่ทำงานตามที่กำหนดค่าไว้ หากไม่ได้สร้างแบบจำลองเพียงพอ

สุดท้ายนี้ ให้ตระหนักถึงสถานการณ์ที่เกิดขึ้น ในโหมดแชทบอทแบบโต้ตอบ ตั้งเป้าไว้ที่ TTFT 0,5 วินาทีและ 30 มิลลิวินาทีต่อโทเค็น วิธีนี้จะทำให้คุณได้รับประสบการณ์ผู้ใช้ระดับพรีเมียม ในโหมดเซิร์ฟเวอร์ 2 วินาทีและ 100 มิลลิวินาทีต่อโทเค็นถือเป็นแนวทางที่เหมาะสม และในโหมดออฟไลน์ วิธีนี้จะช่วยเพิ่มประสิทธิภาพการรับส่งข้อมูลสูงสุด โดยยังคงรักษาความแม่นยำตามเกณฑ์มาตรฐาน

เมื่อพิจารณาแนวโน้ม MLPerf เวกเตอร์จะชัดเจน: บริบทเพิ่มเติม โทเค็นเพิ่มเติม และเทคนิคที่มีประสิทธิภาพดีขึ้น —การให้บริการแบบแยกส่วน FP4/FP8 การตัดแต่งแบบมีโครงสร้าง เคอร์เนลที่กำหนดเอง การกำหนดเวลาแคช KV— กำลังผลักดันเพดานโทเค็นให้สูงขึ้นเป็นปีที่สองเมื่อเทียบกับปีที่แล้ว ทั้งต่อชิปและต่อระบบ

ภาพรวมที่วาดโดย Databricks และ MLPerf มีความสอดคล้องกัน: การคิดในแง่ของโทเค็นต่อวินาทีถือเป็นวิธีที่ถูกต้องในการให้เหตุผลเกี่ยวกับต้นทุน ความหน่วง และความสามารถในการปรับขนาดใน LLMด้วยเกณฑ์มาตรฐานตัวแทนที่ดี เมตริก TTFT/TPOT และการปรับขนาดอัตโนมัติที่ปรับเทียบอย่างดี ทำให้สามารถส่งมอบการตอบสนองที่รวดเร็วและเสถียรโดยไม่ต้องขยายขนาดโครงสร้างพื้นฐานมากเกินไป

บทความที่เกี่ยวข้อง:

NVIDIA Blackwell Ultra GB300: สถาปัตยกรรม หน่วยความจำ และ NVLink 5