Baseten รองรับ Kimi K3 ตั้งแต่เปิดตัววันแรกบน Model APIs ของเรา เราขอขอบคุณ Moonshot AI ที่แชร์น้ำหนักของ Kimi K3 ให้เราเข้าถึงก่อนใคร รวมถึงทีม Inferact และ RadixArk ที่ร่วมมือกันตลอดกระบวนการพัฒนา
Kimi K3 เปิดให้ใช้งานแล้ววันนี้บน Baseten Model APIs พร้อมรองรับอินพุตภาพและหน้าต่างบริบทเต็ม 1M โทเค็น
Kimi K3 คือโมเดลโอเพนฟรอนเทียร์รุ่นใหม่ ด้วยพารามิเตอร์ 2.8T จึงมีขนาดใหญ่กว่าโมเดลโอเพนรุ่นก่อน ๆ มาก ซึ่งนำมาซึ่งความท้าทายมากมายในการสร้างอินฟีเรนซ์ API ที่มีประสิทธิภาพ เทคนิคทางสถาปัตยกรรมใหม่ทำให้ Kimi K3 สามารถขยายขีดจำกัดพารามิเตอร์เกินล้านล้าน ซึ่งเป็นเกณฑ์ของโมเดลโอเพนฟรอนเทียร์รุ่นก่อน:
- Kimi Delta Attention (KDA) และ Attention Residuals (AttnRes) เป็นโครงสร้างพื้นฐานที่ปรับขนาดได้สำหรับสถาปัตยกรรม Kimi
- ผู้เชี่ยวชาญที่เบาบางอย่างยิ่ง โดยมีเพียง 16 จาก 896 ผู้เชี่ยวชาญที่ทำงานในแต่ละครั้ง จัดระเบียบโดยใช้ Stable LatentMoE
- ตัวเข้ารหัสภาพแบบใหม่สำหรับประมวลผลอินพุตภาพและแมปข้อมูลภาพเข้าสู่พื้นที่แฝง
บทความนี้อธิบายงานทางเทคนิคที่จำเป็นในการรันสถาปัตยกรรมโมเดลใหม่และน้ำหนักมหาศาลของ Kimi K3 ในระดับที่พร้อมเปิดตัว
เหตุการณ์สำคัญที่ 1: สร้างโทเค็น
หลังจากได้รับสิทธิ์เข้าถึงน้ำหนักของ Kimi K3 จากทีม Moonshot AI ก่อนใคร ลำดับความสำคัญแรกของเราคือทำให้โมเดลทำงานได้
การสร้างโทเค็นแรกของ Kimi K3 ต้องใช้:
- จัดสรรฮาร์ดแวร์: เนื่องจากขนาดของ Kimi K3 เราจึงตัดสินใจรันโมเดลบนระบบ NVIDIA GB300 NVL72
- โหลดน้ำหนัก: ในรูปแบบ MXFP4 น้ำหนักของ Kimi K3 มีข้อมูลมากกว่า 1.4TB
- เริ่มต้นอินฟีเรนซ์เอนจิ้น: เราทำงานร่วมกับทีมเบื้องหลัง vLLM และ SGLang เพื่อรันบิลด์พรีรีลีสของอินฟีเรนซ์เอนจิ้นสำหรับ Kimi K3
บ่อยครั้ง เมื่อสร้าง API ที่พร้อมเปิดตัวตั้งแต่วันแรก ขั้นตอนแรกคือการพอร์ตน้ำหนักเป็น NVFP4 เพื่อปรับปรุงประสิทธิภาพและความเข้ากันได้กับ NVIDIA Blackwell และสแต็กอินฟีเรนซ์ของเรา อย่างไรก็ตาม Kimi K3 ใช้น้ำหนัก MXFP4 ดั้งเดิมพร้อมแอคติเวชัน MXFP8 และเราสามารถใช้น้ำหนักเหล่านี้ได้โดยตรง
เมื่อมีน้ำหนักแล้ว เราทำงานอย่างใกล้ชิดกับ Inferact บน vLLM และ RadixArk บน SGLang ก่อนที่จะรัน Kimi K3 บน Baseten Inference Stack เราจำเป็นต้องสร้างเส้นฐานร่วมกับอินฟีเรนซ์เอนจิ้นโอเพนซอร์สชั้นนำ
การเพิ่มการรองรับโมเดลให้กับอินฟีเรนซ์เอนจิ้นไม่ใช่เรื่องง่าย ต้องใช้การเขียนโค้ดโมเดลหลัก, เคอร์เนลที่ปรับให้เหมาะสมสำหรับสถาปัตยกรรมใหม่ เช่น KDA และสร้างความเข้ากันได้ส่วนหน้าสำหรับ Kimi K3 ตั้งแต่การทำโทเค็นไปจนถึงการเรียกใช้เครื่องมือ
อิมเมจสำหรับการเข้าถึงก่อนใครของ vLLM สำหรับ GPU NVIDIA Blackwell ช่วยเราสร้างความสมบูรณ์ของฟีเจอร์พื้นฐาน, ผ่านการประเมินเบื้องต้น และตั้งเป้าหมายประสิทธิภาพเส้นฐาน งานนี้เกี่ยวกับการรองรับฟีเจอร์สถาปัตยกรรมของ Kimi K3 เช่น KDA, AttnRes และ Stable LatentMoE เป็นรากฐานที่มั่นคงให้เราสร้างต่อ เรายังทำการตรวจสอบความถูกต้องอย่างละเอียดของอินฟีเรนซ์เอนจิ้น vLLM สำหรับ Kimi K3 และมีส่วนร่วมกลับไปยังเอนจิ้นโอเพนซอร์สจากงานของเรา
อิมเมจสำหรับการเข้าถึงก่อนใครของ SGLang เป็นข้อมูลอ้างอิงสำหรับการให้บริการ Kimi K3 ที่รวดเร็วและเชื่อถือได้ SGLang มีประวัติการรองรับโมเดลภาษาภาพที่แข็งแกร่ง และ Kimi K3 ก็ไม่มีข้อยกเว้น ร่วมกับทีม RadixArk เรามุ่งเน้นที่ความเข้ากันได้ส่วนหน้าและการปรับเคอร์เนลให้เหมาะสม และทีมวิศวกรรมของเราได้แก้ไขจุดบกพร่องส่วนหน้าเกี่ยวกับการจัดการการเรียกใช้เครื่องมือและเอาต์พุตที่มีโครงสร้างเพื่อรองรับความพร้อมในการเปิดตัว
ขอขอบคุณทีม Inferact และ RadixArk ที่สร้างเคียงข้างเราตลอดช่วงพรีวิว งานนี้เป็นรากฐานสำคัญสำหรับ Kimi K3 API ของเรา และเป็นโอกาสในการมีส่วนร่วมกลับไปยังชุมชนโอเพนซอร์ส
เหตุการณ์สำคัญที่ 2: ตรวจสอบความถูกต้องของอินฟีเรนซ์เอนจิ้น
Kimi K3 เป็นโมเดลโอเพนที่ฉลาดที่สุดเท่าที่เคยมีมา การส่งมอบความฉลาดนั้นระหว่างอินฟีเรนซ์จึงเป็นสิ่งจำเป็น
เกณฑ์ชี้วัดของ Kimi K3 แสดงประสิทธิภาพที่แข็งแกร่งในงานแบบเอเจนต์ ซึ่งขึ้นอยู่กับการเรียกใช้เครื่องมือที่แม่นยำและเอาต์พุตโมเดลคุณภาพสูง
การตรวจสอบความถูกต้องของประสิทธิภาพสามารถทำได้ในระดับความเข้มงวดที่แตกต่างกัน การตรวจสอบความถูกต้องเบื้องต้นอย่างง่าย เช่น การเรียกโมเดลด้วยพรอมพ์ที่รู้จักหรือรันเกณฑ์ชี้วัดเล็กน้อย เช่น gsm8k หรือ BFCL และตรวจสอบว่าผลลัพธ์อยู่ในระยะความคลาดเคลื่อนหรือไม่ เป็นจุดตรวจสอบที่มีประโยชน์ในระหว่างกระบวนการพัฒนาเพื่อให้แน่ใจว่าสิ่งต่าง ๆ ไม่ได้ผิดเพี้ยนไป แต่การปล่อย API สาธารณะจำเป็นต้องมีการเปรียบเทียบที่เข้มงวดกว่านี้
ทีม Moonshot AI ดำเนินการ Kimi Vendor Verifier ซึ่งช่วยให้ผู้ให้บริการอินฟีเรนซ์มั่นใจได้ว่าการให้บริการน้ำหนักโมเดลมีความแม่นยำและเที่ยงตรงสูง การผ่าน Kimi Vendor Verifier เป็นเหตุการณ์สำคัญในช่วงต้นของการพัฒนา API และเป็นเครื่องมือที่มีประโยชน์อย่างยิ่งตลอดกระบวนการพัฒนา
มีโอกาสมากมายที่จะทำผิดพลาดในการให้บริการโมเดล แม้ว่าเรื่องราวที่แพร่หลายคือการควอนไทซ์เป็นต้นตอของปัญหาคุณภาพทั้งหมด แต่ในทางปฏิบัติไม่เป็นความจริง ปัญหาคุณภาพส่วนใหญ่ โดยเฉพาะอย่างยิ่งกับการเรียกใช้เครื่องมือและพฤติกรรมโมเดลที่มีโครงสร้างอื่น ๆ มาจากส่วนหน้าของเซิร์ฟเวอร์อินฟีเรนซ์
ส่วนหน้าอยู่ด้านหน้าอินฟีเรนซ์เอนจิ้นและประมวลผลอินพุตและเอาต์พุต
ส่วนหน้าเป็นโค้ดที่กำหนดขึ้นได้ซึ่งทำงานบน CPU ด้านหน้าลูปอินฟีเรนซ์ มีหน้าที่รับอินพุตและส่งคืนเอาต์พุต ส่วนหน้าต้อง:
- ดำเนินการและตรวจสอบความถูกต้องของ API
- ทำโทเค็นพรอมพ์และดีโทเค็นเอาต์พุต
- เรนเดอร์เทมเพลตแชท
- แยกวิเคราะห์การให้เหตุผลและการเรียกใช้เครื่องมือ
- จัดรูปแบบเอาต์พุตเป็น ChatCompletions, messages หรือมาตรฐานอื่น
งานเหล่านี้แตกต่างกันเล็กน้อยในแต่ละโมเดล และเป็นเรื่องธรรมดามากที่จะเกิดข้อบกพร่องและประสิทธิภาพลดลงเมื่อสร้างอย่างรวดเร็วสำหรับการรองรับตั้งแต่วันแรก การตรวจสอบที่แข็งแกร่ง เช่น Kimi Vendor Verifier ประเมินประสิทธิภาพในโหมดความล้มเหลวทั่วไป เช่น การเรียกใช้เครื่องมือ เพื่อให้แน่ใจว่าโมเดลถูกให้บริการด้วยความเที่ยงตรงสูงทั้งในลูปอินฟีเรนซ์และพื้นผิว API
เมื่อเราพัฒนา API ต่อไป เราใช้ Kimi Vendor Verifier ในเหตุการณ์สำคัญต่อมาเพื่อให้แน่ใจว่าการปรับประสิทธิภาพให้เหมาะสมไม่ได้ทำให้เกิดข้อบกพร่องที่จะลดความแม่นยำ
เหตุการณ์สำคัญที่ 3: ค้นหาการกำหนดค่าที่เหมาะสม
อินฟีเรนซ์เอนจิ้นมีตัวเลือกการกำหนดค่าที่หลากหลายเพื่อปรับประสิทธิภาพให้เหมาะกับโมเดล ฮาร์ดแวร์ รูปแบบการรับส่งข้อมูล และการแลกเปลี่ยนระหว่างความหน่วงและปริมาณงานที่แตกต่างกัน ตัวเลือกเหล่านี้และปฏิสัมพันธ์ระหว่างกันนั้นซับซ้อน
เพื่อค้นหาการกำหนดค่าที่เหมาะสม เราทำการสแกนตัวเลือกต่าง ๆ เช่น การตั้งค่า Tensor Parallelism (TP) และ Expert Parallelism (EP), การสลับ Attention Data Parallelism (ADP), การปรับขนาดแบตช์, ความยาวร่างของตัวถอดรหัสแบบคาดเดา, ช่วงเวลาการแคชเลเยอร์เชิงเส้น, พารามิเตอร์การกำหนดเส้นทาง และการตั้งค่าอินฟีเรนซ์เอนจิ้น
Tensor Parallelism และ Expert Parallelism แบ่งโมเดลขนาดใหญ่ออกเป็นหลาย GPU
การรัน Kimi K3 ต้องใช้ GPU NVIDIA GB300 จำนวนแปดตัวเพื่อให้น้ำหนักโมเดลมหาศาลพอดีกับ VRAM อย่างไรก็ตาม แตกต่างจาก GPU NVIDIA อื่น ๆ ที่มาในโหนดละแปดตัว GB300s มาในโหนดละสี่ตัว แม้ว่าสิ่งนี้อาจดูเหมือนจำกัดกลยุทธ์การขนานที่เป็นไปได้ – โดยทั่วไปแล้ว Tensor Parallelism เป็นไปไม่ได้ข้ามโหนดเนื่องจากอินเทอร์คอนเนกต์ที่ช้าทำให้การดำเนินการ all-reduce ที่มีราคาแพงกลายเป็นคอขวดสำหรับอินฟีเรนซ์ – ระบบ GB300 NVL72 มีอินเทอร์คอนเนกต์ที่เร็วพอระหว่างโหนดที่เราสามารถรันอินฟีเรนซ์ด้วย Tensor Parallelism และ Expert Parallelism ข้ามโหนดได้
การตัดสินใจกำหนดค่าเหล่านี้เป็นผลสืบเนื่องมาจากการเลือกอินฟีเรนซ์เอนจิ้น วิศวกรทำงานแบบขนานเพื่อกำหนดค่า vLLM, SGLang และเอนจิ้นภายในของเราเอง แบ่งปันสิ่งที่ค้นพบและนำบทเรียนไปใช้กับเอนจิ้นภายในของเรา ในขณะเดียวกันก็มีส่วนร่วม PR กลับไปยังเอนจิ้นโอเพนซอร์ส
เหตุการณ์สำคัญที่ 4: ปรับประสิทธิภาพให้เหมาะสม
เมื่อโมเดลทำงานบนการกำหนดค่าที่ปรับให้เหมาะสมแล้ว มีเทคนิควิศวกรรมอินฟีเรนซ์จำนวนมากที่สามารถปรับปรุงความหน่วง ปริมาณงาน หรือทั้งสองอย่างได้อย่างมีนัยสำคัญ สำหรับโมเดล API เรามักจะดูที่:
- การคาดเดา: การใช้โมเดลร่างขนาดเล็กเพื่อทำนายหลายโทเค็น จากนั้นตรวจสอบความถูกต้องเป็นส่วนหนึ่งของฟอร์เวิร์ดพาส การเพิ่มประสิทธิภาพแบบไม่สูญเสียนี้ช่วยปรับปรุง TPS ต่อผู้ใช้ในการถอดรหัส
- การแยกส่วน: ย้ายพรีฟิลและดีโค้ดไปยังเวิร์กเกอร์แยกกัน สิ่งนี้ป้องกันการแข่งขันเพื่อทรัพยากร อนุญาตให้กำหนดค่าได้ตรงเป้าหมายมากขึ้น และทำให้อัตราส่วนของพรีฟิลต่อดีโค้ดคอมพิวต์ปรับได้เพื่อให้ตรงกับการรับส่งข้อมูล
- การแคช: การจัดสรรหน่วยความจำเพื่อบันทึก KV cache และสถานะ KDA ระหว่างคำขอ ทำให้คำขอถัดไปที่มีคำนำหน้าแชร์ในลำดับอินพุตสามารถข้ามพรีฟิลทั้งหมดหรือบางส่วนได้ สิ่งนี้ช่วยปรับปรุง TTFT และปริมาณงานของระบบโดยรวม
การมีโมเดลทำงานจากเหตุการณ์สำคัญก่อนหน้านี้เป็นสิ่งที่ต้องพึ่งพาสำหรับงานนี้ ตัวอย่างเช่น การฝึกโมเดล Speculator โดยใช้วิธี เช่น DSpark, DFlash หรือ EAGLE-3 ต้องสร้างสถานะที่ซ่อนจากโมเดลเป้าหมาย (Kimi K3) โดยใช้ชุดพรอมพ์ที่คล้ายกับการใช้งานจริงที่คาดไว้ ในการทำเช่นนี้ คุณต้องมีอินสแตนซ์ของโมเดลที่มีปริมาณงานสูงพอสมควรที่ทำงานและรันอินฟีเรนซ์
การเพิ่มประสิทธิภาพใหม่ประการหนึ่งคือในตัวทำโทเค็น เป็นเวลาหลายปีที่วิศวกรอินฟีเรนซ์สามารถละเลยเวลาในการทำโทเค็นว่าเล็กน้อย สำหรับโมเดลเช่น Kimi K3 ที่มีลำดับอินพุตยาวและอัตราการใช้ KV cache ซ้ำสูง สิ่งนี้เปลี่ยนแปลงไป และการทำโทเค็นสามารถกลายเป็นสิ่งสำคัญต่อเวลาพรีฟิล เนื่องจากการทำโทเค็นต้องเกิดขึ้นไม่ว่าลำดับอินพุตจะเป็น cache hit หรือไม่ก็ตาม
เราสร้างตัวทำโทเค็นแบบกำหนดเองที่เร็วกว่า tiktoken ถึง 18 เท่าสำหรับลำดับอินพุตยาว และนำไปใช้ควบคู่กับ Kimi K3 API ของเรา
Basetenkenizer เร็วกว่า Tiktoken ถึง 18 เท่าสำหรับลำดับอินพุตยาว
ยังมีงานอีกมากที่ต้องทำเกี่ยวกับประสิทธิภาพ ทุกโมเดลที่เราเปิดตัว เรายังคงลงทุนในการปรับความหน่วงและปริมาณงานให้เหมาะสมในสัปดาห์หลังการเปิดตัว ด้วยขนาดที่ไม่เคยมีมาก่อนของ Kimi K3 จึงมีพื้นที่ขนาดใหญ่สำหรับการปรับปรุงประสิทธิภาพเพิ่มเติมในทุกเทคนิควิศวกรรมอินฟีเรนซ์หลักและทุกเลเยอร์ของสแต็กอินฟีเรนซ์
เหตุการณ์สำคัญที่ 5: ปรับใช้งานในระดับใหญ่
มีความตื่นเต้นอย่างมากในอุตสาหกรรมสำหรับ Kimi K3 ซึ่งจะถูกจับคู่กับคลื่นความต้องการ API จำนวนมากในตอนเปิดตัว ดังนั้น ปริมาณงานของระบบโดยรวม ไม่ใช่แค่ความหน่วงต่อผู้ใช้เท่านั้น ที่เป็นลำดับความสำคัญสูงสุด
บนระบบ GB300 NVL72 หนึ่งโหนดคือ GPU 4 ตัว ซึ่งหมายความว่ามี 18 โหนด ในฐานะอินสแตนซ์ Kimi K3 ใช้พื้นที่ 2 โหนด (8 GPU); แต่ละแร็ค NVL72 สามารถโฮสต์ replica ของโมเดลได้ 9 ตัว แต่ละคลัสเตอร์มีแร็ค GB300 NVL72 หลายตัว และเราให้บริการโมเดลข้ามหลายภูมิภาคและผู้ให้บริการคลาวด์เพื่อเข้าถึงความจุมากขึ้น
แต่ละระบบ NVL72 สามารถรัน Kimi K3 ได้เก้า replica
ปัจจัยที่สำคัญที่สุดสำหรับปริมาณงานของ replica ที่กำหนดคืออัตรา cache hit ของคำนำหน้า เนื่องจากขนาดของการปรับใช้งาน ทำให้การกำหนดเส้นทางที่คำนึงถึง KV เป็นความท้าทายหลักในการแก้ไขบนโครงสร้างพื้นฐาน เมื่อผู้ใช้ส่งลำดับของโทเค็นอินพุตที่เราเคยเห็นมาก่อน เราจำเป็นต้องกำหนดเส้นทางคำขอนั้นไปยัง replica ที่สามารถเข้าถึง KV cache ที่บันทึกไว้เพื่อข้ามพรีฟิล
ระบบกำหนดเส้นทางที่คำนึงถึง KV ของเรา ซึ่งสร้างขึ้นด้วยชุดเครื่องมือ NVIDIA Dynamo ช่วยให้เราสามารถกำหนดเส้นทางการรับส่งข้อมูลไปยัง replica ที่มี cache อุ่นสำหรับคำถามซ้ำ เนื่องจากการเขียนโค้ดและเอเจนต์แบบหลายเทิร์นเป็นกรณีการใช้งานทั่วไปสำหรับ Kimi K3 ระบบกำหนดเส้นทางที่คำนึงถึง cache นี้จึงมีความสำคัญต่อการประหยัดเงินให้ผู้ใช้และรักษาปริมาณงานของระบบโดยรวมให้สูง
สร้างด้วย Kimi K3 บน Baseten
เรารู้สึกตื่นเต้นที่จะให้สิทธิ์เข้าถึงตั้งแต่วันแรกผ่าน Model APIs และหวังว่าจะได้ปรับปรุงการใช้งานโมเดลนี้อย่างต่อเนื่องเพื่อให้ได้มาตรฐานสูงสุดในด้านประสิทธิภาพและความน่าเชื่อถือ
ประกาศ Kimi K3 ของทีม Moonshot AI มีการทดสอบที่น่าสนใจมากมายสำหรับโมเดล รวมถึงงานเขียนโค้ด เช่น การปรับเคอร์เนลให้เหมาะสมและการพัฒนาเกมแบบมีภาพในลูป งานวิจัย และงานแบบเอเจนต์ เช่น การตัดต่อวิดีโอและการทำงานด้านความรู้ ในวันอังคารที่ 28 กรกฎาคม เวลา 11:00 น. Pacific Time ฉันจะ จัดงานบรรยายสรุปสำหรับผู้บริหารเกี่ยวกับ Kimi K3 ร่วมกับ Joey Zwicker ซึ่งเป็นหัวหน้าวิศวกรรมประจำที่ Baseten
Kimi K3 เปิดให้ใช้งานแล้ววันนี้บน Baseten Model APIs ยินดีต้อนรับสู่พรมแดนใหม่ของความฉลาดในน้ำหนักโอเพน
ขอขอบคุณวิศวกรจำนวนมากที่อยู่เบื้องหลัง Kimi K3 API ของเราที่ให้ฉันบันทึกการทำงานหนักของพวกเขาในบทความนี้ รวมถึงหลายคนเกินกว่าจะเอ่ยชื่อในทีมประสิทธิภาพโมเดล โครงสร้างพื้นฐาน ความจุ การฝึกอบรม ผลิตภัณฑ์ และวิศวกรรมประจำที่ นอกจากนี้ ขอขอบคุณทีมงานที่ Moonshot AI, Inferact และ RadixArk สำหรับความร่วมมือและการสนับสนุน
