บทความโดย เซียงเซียนซhi
Lufei ได้โพสต์บน X เพื่อปิดประเด็นการลดราคาของ Xiaomi MiMo
วันที่ 26 พฤษภาคม บัญชีทางการของ Xiaomi MiMo บน X ได้ประกาศว่า: ชุด API MiMo-V2.5 ลดราคาถาวร สูงสุดถึง 99% ราคาสำหรับความยาว context ทั้งหมดถูกกำหนดเป็นราคาเดียวกัน และแพ็กเกจ Token ได้รับการอัปเกรด 5-8 เท่า
ประกาศนี้ถูกแชร์ในวงการ AI ของจีนตลอดทั้งสัปดาห์ ปฏิกิริยาแรกจากอุตสาหกรรมแบ่งออกเป็นหลายฝ่าย ฝ่ายที่ใหญ่ที่สุดกล่าวว่านี่คือ “การแข่งขันด้านราคาอีกครั้ง” — ในสองปีที่ผ่านมา ตั้งแต่ Zhipu, DeepSeek, ByteDance DouBao ไปจนถึง Alibaba Tongyi โมเดลขนาดใหญ่ของจีนต่างลดราคาสลับกัน ใครก็ตามที่ไม่ได้แข่งขัน
อีกมุมมองที่มองในแง่ลบ: ซีอีโอเพิ่งประกาศว่ากำไรปีนี้ลดลงครึ่งหนึ่ง แต่ยังคงใช้เงิน 60,000 ล้านหยวนไปกับ AI และตัดค่าใช้จ่าย API ลง 90% — เป็นตัวอย่างคลาสสิกของการ “เสียเงินเพื่อแย่งส่วนแบ่งตลาด” บางคนคิดว่านี่เป็นผลต่อเนื่องจาก DeepSeek — ซึ่งได้ดึงมาตรฐานการตั้งราคาของทั้งอุตสาหกรรมลงมาถึงพื้นดิน ใครไม่ตามก็จะถูกขับออก
ดังนั้น ในฐานะหัวหน้าของ MiMo ลู่ฟู่ลี่จึงได้นำเสนอโพสต์เทคโนโลยีขนาด 5,000 คำเมื่อคืนนี้ โดยเปิดเผยบัญชีด้านวิศวกรรมของการลดราคาให้กับทุกคน
ดูสิ นี่คือความสามารถด้านวิศวกรรมที่แท้จริง ไม่ใช่กลยุทธ์การตลาด
เพื่อเข้าใจว่าลอฟลี่พูดถึงอะไร คุณต้องเข้าใจก่อนว่า 99% นี้ลดลงอะไร
这不是全面的模型降价。99% 的折扣专门针对名为 Input (Cache Hit) 的定价——即“用户在长对话中重复读取历史上下文”的部分。普通的新输入（No Cache Hit）降幅小得多，而模型输出（Output）的降幅最小。
หากคุณมองโมเดลเหมือนร้านกาแฟ ข้อนี้จะเข้าใจได้ง่ายขึ้น
คุณสั่งกาแฟลาเต้หวานครึ่งหนึ่ง ร้านกาแฟมีสองวิธีทำ: วิธีแรกคือทุกครั้งจะบดเมล็ดกาแฟ ตวงน้ำเชื่อม และเทนมใหม่ทั้งหมด ซึ่งต้องจ่ายค่าทรัพยากรและค่าแรงทุกครั้ง; แต่โมเดลรู้ว่าคุณจะดื่มลาเต้หวานครึ่งหนึ่งแบบเดิมทุกวันในสัปดาห์นี้ จึงตัดสินใจทำเป็นปริมาณใหญ่เก็บไว้ในตู้เย็น แล้วตักออกมาตามปริมาณหนึ่งแก้วเมื่อต้องการ ครั้งนี้ MiMo เลือกวิธีหลัง—เปลี่ยนส่วนที่ผู้ใช้อ่านซ้ำจาก “คำนวณใหม่ทุกครั้ง” เป็น “ดึงออกมาใช้ทันที” จึงทำให้ต้นทุนจริงของส่วนนี้ใกล้เคียงกับศูนย์ และสามารถให้ส่วนลด 99% ได้อย่างเป็นธรรมชาติ
เพื่อให้ทำได้ตาม "การรับทันที" บล็อกเทคนิคได้อธิบายถึงหกโครงการ แต่ละโครงการไม่สามารถขาดได้ ด้านล่างนี้จะแยกอธิบายทีละขั้นตอน
โครงการที่ 1: ลดขนาด "หน่วยความจำ" ของโมเดลลงเหลือ 1/7
โมเดลจะคำนวณและบันทึก “สถานะกลาง” สำหรับแต่ละโทเค็นขณะสนทนา กับคุณ เพื่อใช้ในขั้นตอนถัดไป สิ่งนี้เรียกว่า KVCache — สามารถเข้าใจได้ว่าเป็น “สมุดบันทึกความจำระยะสั้น” ของโมเดล ทุกครั้งที่พูดประโยคหนึ่ง โมเดลจะบันทึกสรุปของประโยคนั้นลงในสมุด และครั้งต่อไปจะสามารถเปิดดูบันทึกได้ทันที โดยไม่ต้องฟังเนื้อหาทั้งหมดที่คุณพูดตั้งแต่ต้น
แบบดั้งเดิมแต่ละชั้นจะใช้ "Full Attention" — หมายถึงทุก token จะดูทุก token ในบทสนทนาทั้งหมด ทำให้สมุดโน้ตยิ่งพลิกยิ่งหนา MiMo-V2.5-Pro เปลี่ยนสถาปัตยกรรม: ใน 70 ชั้น มี 60 ชั้นที่ดูเฉพาะ 128 token ล่าสุดเท่านั้น (SWA, Sliding Window Attention) และมีเพียง 10 ชั้นที่ทำหน้าที่เป็น "ผู้จัดการเอกสาร" ที่ดูทั้งหมด
ผลลัพธ์คือขนาดของ KVCache ลดลงเหลือเพียง 1/7 ของ Full Attention และปริมาณการคำนวณก็ลดลงเป็น 1/7 เช่นกัน
นี่คือรากฐานแรกในการลดต้นทุน ตัวอย่างเช่น ก่อนหน้านี้ พนักงานทุกคนในบริษัทต้องจำบันทึกการประชุมทั้งหมด ทำให้สมองของแต่ละคนรับไม่ไหวและประสิทธิภาพต่ำ กฎใหม่นี้ลดภาระของพนักงาน 60 คนเหลือเพียง 1/7 โดยให้พนักงานจัดการเอกสารเพียง 10 คนรับผิดชอบประวัติทั้งหมด—ความสามารถในการจดจำของบริษัทโดยรวมไม่ลดลง แต่ประสิทธิภาพเพิ่มขึ้น 7 เท่า
โครงการที่สอง: ทำให้พื้นที่ที่ SWA ประหยัดได้สามารถใช้งานได้จริง
การบีบลำดับชั้นของแล็ปท็อปให้เหลือ 1/7 เป็นขั้นตอนแรก แต่การเปลี่ยน “1/7 ทางทฤษฎี” ให้กลายเป็น “1/7 จริงๆ” ยังมีอุปสรรคอีกขั้นหนึ่ง
ระบบ KVCache แบบดั้งเดิมจัดสรรหน่วยความจำ GPU ให้กับทุกชั้นตาม "ปริมาณการใช้งานสูงสุดที่เป็นไปได้" หมายความว่า แม้ว่า 60 ชั้นของ SWA จะต้องการแค่สมุดเล็กๆ ระบบก็จะจัดสรรให้ทุกชั้นตาม "สมุดขนาดใหญ่ของผู้จัดการเอกสาร" — พื้นที่ที่ SWA ประหยัดได้ถูกจองไว้โดยไม่ได้ใช้งาน จึงเท่ากับว่าไม่ได้ประหยัดอะไร
ทีม Luo Fuli แบ่ง KVCache ออกเป็นสองสระอิสระ โดย 10 ชั้นของ Full Attention ใช้ “สระใหญ่” ที่จัดสรรตามความยาวเต็ม และ 60 ชั้นของ SWA ใช้ “สระเล็ก” ที่จัดสรรเฉพาะตามหน้าต่าง 128 โทเค็น
ตัวอย่างเช่น บริษัทเคยจัดให้พนักงานแต่ละคนซึ่งมี 60 คน ซึ่งจริงๆ แล้วต้องการแค่ตู้เก็บเอกสารขนาดเล็กสำหรับเก็บเอกสารหนึ่งสัปดาห์ แต่กลับได้รับตู้เก็บเอกสารขนาดใหญ่ที่สามารถเก็บเอกสารได้ถึง 100 ปี โดยพื้นที่ 99% ของตู้เหล่านั้นว่างเปล่า วิธีใหม่คือการจัดตู้ตามความต้องการจริง ผลลัพธ์คือสำนักงานสามารถรองรับพนักงานได้มากกว่าเดิมถึง 5 เท่า—เช่นเดียวกันกับ GPU หนึ่งเครื่องที่สามารถให้บริการผู้ใช้งานพร้อมกันได้เพิ่มขึ้นเป็น 5 เท่า
ขั้นตอนนี้ดูเหมือนง่าย แต่ถ้าไม่มีมัน ข้อได้เปรียบของสถาปัตยกรรม SWA ที่ออกแบบมาทั้งหมดก็จะสูญเปล่า
โครงการที่สาม: ทำให้ "ผู้ใช้เก่าอ่านซ้ำ" สามารถเข้าถึงแคชได้จริง
โน้ตบุ๊กถูกบีบอัดที่ 1/7 + พื้นที่ใช้งานได้จริง ขั้นตอนต่อไปคือการแก้ไขปัญหาเก่า: อัตราการเข้าถึงแคชเงื่อนไขนำหน้า
การสนทนาของผู้ใช้จำนวนมากเริ่มต้นด้วยเนื้อหาเดียวกัน—พรอมต์ระบบเดียวกัน คลังโค้ดเดียวกัน และเอกสารยาวเดียวกัน ระบบจะเก็บผลลัพธ์ที่คำนวณแล้วไว้ และเมื่อพบการจับคู่ครั้งถัดไป จะใช้ซ้ำทันที กลไกนี้เรียกว่าแคชเบื้องต้น
แต่ในโหมด SWA มีจุดที่ต้องระวัง: การที่คำขอสองคำขอมีโทเค็นเหมือนกัน ไม่ได้หมายความว่า KV ยังคงอยู่ อาจมีการคำนวณคำนำหน้าแล้ว แต่ส่วนที่อยู่นอกหน้าต่าง SWA ถูกกำจัดไปแล้ว หากระบบยังใช้กฎเก่าที่ว่า “ถ้าโทเค็นเหมือนกันก็ใช้ซ้ำ” จะทำให้อ่านข้อมูลที่ไม่ถูกต้องหรือถูกเขียนทับไปแล้ว ซึ่งจะทำให้ประสิทธิภาพของโมเดลพังทันที
ทีม Luo Fuli ได้อัปเกรดกฎเป็น "ความยาวปลอดภัยของหน้าต่าง" — รับประกันเฉพาะ "ส่วนที่คุณสามารถยืมได้อย่างสมบูรณ์"
ตัวอย่างเช่น ห้องสมุดมีหนังสือ 1 ล้านเล่ม และคุณต้องการยืมชุดหนังสือ “Three-Body Problem” ทั้งหมด 3 เล่ม ระบบเดิมจะแจ้งว่า “หนังสือเล่มนี้มีอยู่” คุณจึงวิ่งไปที่ชั้น แต่กลับพบว่ามีเพียงปกและเล่มแรกเท่านั้น ส่วนเล่มที่สองและสามถูกยืมไปแล้ว การ “แจ้งผิดพลาด” แบบนี้ทำให้คุณต้องเดินทางเปล่าและต้องยืมใหม่ ระบบใหม่เปลี่ยนกฎเป็นการรับประกันเฉพาะส่วนที่คุณสามารถยืมได้ครบชุด—ส่งเล่มแรกให้คุณก่อน แล้วจึงจัดหาเล่มที่สองและสามมาให้คุณต่อ
ดูเหมือนจะเข้มงวดมากขึ้นและอัตราการถูกต้องจะลดลง แต่ในความเป็นจริงกลับกัน: เนื่องจาก SWA ลดขนาด KVCache ลงเหลือ 1/7 พื้นที่จัดเก็บเดียวกันจึงสามารถเก็บข้อมูลได้มากกว่าหลายเท่า จึงทำให้อัตราการเข้าถึงข้อมูลจริงเพิ่มขึ้นอย่างมาก
ในบล็อกของ Luo Fuli มีตัวเลขการทดสอบออนไลน์ที่ให้ไว้: อัตราการเข้าถึงแคชเซิร์ฟเวอร์โดยเฉลี่ยอยู่ที่ 93% ภายใต้เฟรมเวิร์ก harness หลัก และผู้ใช้ที่มีกิจกรรมสูงและใช้งานระยะยาวสามารถสูงกว่า 95%
ความหมายของตัวเลขนี้คือ: คำขอ "อ่านซ้ำ" 95% ไม่ต้องใช้ GPU คำนวณเลย แต่ดึงข้อมูลโดยตรงจากแคช นี่คือพื้นฐานทางกายภาพของส่วนลด 99%
โครงการที่สี่: ติดตั้ง "แคช" ลงใน SSD ที่ติดตั้งมาพร้อม GPU
อัตราการ命中เพิ่มขึ้น ปัญหาถัดไปคือ: แคชเหล่านี้เก็บไว้ที่ไหน
หน่วยความจำ GPU (HBM) มีราคาสูงและจำกัด—เครื่อง H100 แบบ 8 หน่วยมีหน่วยความจำเพียง 640GB แต่ MiMo ต้องจัดเก็บ KVCache อาจอยู่ในระดับหลายสิบเทราไบต์ ดังนั้นจึงจำเป็นต้องใช้การจัดระดับ: ข้อมูลที่เพิ่งใช้งานเก็บในหน่วยความจำ GPU (L1) ข้อมูลที่เก่ากว่าเล็กน้อยเก็บในหน่วยความจำ CPU (L2) และข้อมูลที่ไม่ได้ใช้งานเก็บในแคชกระจาย (L3)
เหมือนกับการจัดการเงินของคุณ เงินสดในกระเป๋าคือหน่วยความจำแสดงผล—ใช้ได้ทันทีแต่เก็บได้น้อย ยอดบัญชีบัตรธนาคารคือหน่วยความจำ CPU—ใช้ครั้งละ 30 วินาทีแต่เก็บได้มาก เงินฝากประจำคือแคชกระจายระดับ L3—ใช้ครั้งละ 2 นาทีแต่ถูกกว่ามาก
แนวทางทั่วไปของอุตสาหกรรมคือการสร้างคลัสเตอร์การจัดเก็บข้อมูลแยกต่างหากสำหรับ L3 โดยใช้เครื่องเฉพาะทางและห้องเซิร์ฟเวอร์เฉพาะ พร้อมจ่ายค่าเช่ารายเดือน
ทีมจัดเก็บข้อมูลของ Xiaomi ทำแตกต่างออกไป พวกเขาพัฒนาแคชกระจายตัวของตนเองที่ชื่อ GCache และติดตั้งโดยตรงบน SSD ที่มาพร้อมกับเครื่อง GPU — ร่วมใช้งานกับงานฝึกอบรมและงานอนุมานบนเครื่องเดียวกัน
ผู้อื่นเช่าโกดังเฉพาะเพื่อเก็บข้อมูลจำนวนมาก แต่ Xiaomi พบว่าโรงจอดรถสำหรับเครื่อง GPU ว่างอยู่ จึงเก็บข้อมูลลงไปทันที ช่วยประหยัดค่าเช่ารายเดือน
ค่าใช้จ่ายในการจัดเก็บเพิ่มเติมเป็นศูนย์
ผลกระทบของเรื่องนี้ใหญ่กว่าที่ดูเหมือน ในบัญชีพลังการประมวลผลของบริษัท AI ทั่วไป ค่าใช้จ่ายในการจัดเก็บเป็นค่าใช้จ่ายคงที่—ยิ่งโมเดลใหญ่ขึ้นและผู้ใช้มากขึ้น บิลการจัดเก็บก็ยิ่งยาวขึ้น การทำงานของ GCache ตัดค่าใช้จ่ายนี้ออกไปโดยตรง ร่วมกับขนาดเล็กของ SWA และอัตราการเข้าถึง 93-95% ระยะเวลาการอยู่รอดของ KVCache ใน L3 (TTL) ขยายจากไม่กี่นาทีเป็นหลายชั่วโมงหรือแม้แต่หลายวัน—ยิ่ง TTL ยาวเท่าใด ช่วงเวลาที่สามารถเข้าถึง context ย้อนหลังก็ยิ่งกว้างขึ้น อัตราการเข้าถึงแคชสูงขึ้น และส่วนลด 99% ก็ยิ่งมั่นคง
โครงการที่ห้า: ทำให้คำขอที่เข้าถึงแคชเดินทางผ่านเส้นทางที่สั้นที่สุด
แคชสามารถเก็บได้ ค้นหาได้ และราคาถูก ขั้นสุดท้ายคือ: วิธีการส่งคำขอที่ถูกต้องไปยังเครื่องที่ถูกต้อง
ซีอีโอได้พัฒนาระบบการจัดการของตนเองชื่อ LLM-Router ซึ่งทำสามสิ่ง:
หนึ่งคือการจัดสรรแบบใกล้เคียง: คำขอที่มีคำนำหน้าเดียวกันจะถูกส่งไปยังเครื่องเดียวกัน เพื่อให้การใช้ซ้ำแคชสูงสุด
ที่สองคือการแบ่งกลุ่มตามความยาว แยกคำขอสั้น (0-64K) คำขอปานกลาง (64K-256K) และคำขอยาว (256K-1M) ไปยังช่องทางการประมวลผลที่ต่างกัน เพื่อป้องกันไม่ให้คำขอสั้นถูกคำขอยาวชะลอ
ที่สามคือการปรับปรุง TTFT โดยให้ความสำคัญกับคำขอที่มีปริมาณการคำนวณจริงน้อย (เช่น คำขอที่เข้าถึงแคชได้มาก) ในคิวการรอการประมวลผล — เพื่อป้องกันไม่ให้คำขอเหล่านี้ถูกบล็อกโดยคำขอที่ต้องคำนวณใหม่ทั้งหมด
ตัวอย่างเช่น ในระบบจัดตารางเที่ยวบินที่สนามบินทั่วไป ผู้โดยสารที่มีจุดหมายเดียวกันจะถูกรวมกันในห้องรอเดียวกันและใช้กระบวนการรับสัมภาระร่วมกัน — นี่คือการจัดเรียงแบบความใกล้ชิด ผู้โดยสารที่มีกระเป๋าเดินทางขึ้นเครื่องและผู้โดยสารที่มีกระเป๋าโหลดใต้เครื่องสามใบจะผ่านช่องตรวจความปลอดภัยสองช่องแยกกัน ทำให้ผู้ที่เร็วไม่ถูกชะลอโดยผู้ที่ช้า — นี่คือการแบ่งกลุ่มตามความยาว เมื่อขึ้นเครื่อง จะให้ผู้โดยสารที่มีเพียงกระเป๋าเดินทางขึ้นเครื่องขึ้นก่อน เพราะพวกเขาขึ้นเร็ว ทำให้เครื่องบินสามารถบินออกได้เร็วขึ้น — นี่คือการปรับปรุงแบบ TTFT
กลยุทธ์การจัดตารางนี้ช่วยเพิ่มอัตราการเข้าถึงแคช L2 ได้ 25% เพิ่มปริมาณการรับข้อมูลต่อเครื่องเดียว 30% และลดความล่าช้า P90 ของคำขอระยะยาวลง 30%
GPU เดียวกันสามารถให้บริการผู้ใช้ได้มากขึ้น เหตุผลอีกครึ่งหนึ่งของการลดราคาคือผลผลิตต่อหน่วยการประมวลผลสูงขึ้น และต้นทุนต่อผู้ใช้ลดลง
โครงการที่หก: ทำให้โมเดลพิมพ์เร็วขึ้น
ห้าสิ่งแรกทั้งหมดมุ่งปรับปรุงด้านการ "อ่าน" — ลดต้นทุนในการให้ผู้ใช้อ่านบริบทย้อนหลังให้ใกล้เคียงศูนย์ สิ่งที่หกคือการปรับปรุงด้านการ "เขียน" — นั่นคือกระบวนการที่โมเดลสร้างโทเค็นถัดไป
แบบจำลองแบบดั้งเดิมสามารถสร้าง token ได้เพียง 1 ตัวเท่านั้นในแต่ละครั้ง MiMo รองรับ MTP (Multi-Token Prediction) แบบเนทีฟ 3 ชั้น — ทำนาย token ถัดไป 3 ตัวในครั้งเดียว และหากการคาดการณ์ขั้นกลางถูกต้อง จะข้ามการคำนวณขั้นกลางทันที
ตัวอย่างเช่น การพิมพ์แบบดั้งเดิมคือการพิมพ์ทีละตัวอักษร—ถ้าคุณต้องการพิมพ์ “วันนี้อากาศ” คุณต้องกดปุ่ม 4 ครั้ง ในขณะที่ MTP มีฟีเจอร์เติมคำอัตโนมัติที่ทายว่าคุณจะพิมพ์ตัวอักษรถัดไป 1-2 ตัวอะไร—ถ้ามันทายถูก คุณก็ไม่ต้องกดปุ่มอีก 2 ครั้ง
การทดสอบจริงของ MTP ของ MiMo ในสถานการณ์ agentic: เร่งความเร็ว 2.3 เท่าสำหรับ 128 โทเค็นแรก และเร่งความเร็ว 1.5 เท่าสำหรับ 128-256 โทเค็น
ความหมายของเรื่องนี้คือ ส่วนลด 99% นั้นเน้นเฉพาะ Input (Cache Hit) แต่เมื่อโมเดลให้บริการผู้ใช้จริงๆ Input และ Output จะเกิดขึ้นในคำขอเดียวกัน — หาก Output ไม่ถูกตัดลด ต้นทุนโดยรวมของคำขอก็จะลดลงเพียงครึ่งเดียวเท่านั้น MTP ช่วยลดส่วนที่เป็น Output นี้ลงด้วย ทำให้แบบจำลองกำไรจากการลดราคาทั้งหมดสมบูรณ์
เชื่อมหกสิ่งนี้เข้าด้วยกันเป็นห่วงโซ่การลดต้นทุน:
โครงสร้าง SWA → KVCache 1/7 → สองบ่อปลดปล่อยความจุอย่างแท้จริง → สามารถเก็บได้มากกว่า 5 เท่าบน GPU เดียวกัน → อัตราการพบข้อมูลในแคชเบื้องต้น 93-95% → 95% ของคำขอแทบไม่ต้องคำนวณ → GCache ทำให้ต้นทุนการจัดเก็บลดลงเป็นศูนย์ → การจัดสรรให้คำขอที่พบข้อมูลในแคชได้รับการประมวลผลก่อน → MTP ช่วยลดการสร้างข้อมูล → เวลา GPU ต่อคำขอลดลงหนึ่งระดับสิบ → ต้นทุนต่อหน่วยลดลงมากกว่า 95% → ราคาลดลง 99% แต่ยังคงมีกำไรขั้นต้น
หากขาดส่วนใดส่วนหนึ่ง โซ่จะขาดที่จุดนั้น การลดราคา 99% ไม่ใช่ตัวเลขทางการตลาด แต่เป็นผลสะสมจากการรวมกันของหกเสาหลักทางวิศวกรรมและการยืนยันออนไลน์จริง
ย้อนกลับไปดูการตีความหลายแบบในช่วงเริ่มต้นของอุตสาหกรรม แต่ละแบบล้วนมีข้อถูกต้องบางส่วน สองปีที่ผ่านมา สงครามราคาระหว่างบริษัทโมเดลขนาดใหญ่ของจีนเป็นเรื่องจริง; ซีอีโอไม่เพียงแต่ลดกำไรลงครึ่งหนึ่งแต่ยังลงทุนหนักใน AI เป็นเรื่องจริง; DeepSeek ได้ดึงราคาของอุตสาหกรรมลงสู่ระดับต่ำสุดก็เป็นเรื่องจริง
แต่การที่ Luo Fuli ได้เปิดเผยบล็อกเทคนิคอย่างเปิดเผยและถอดประกอบรายละเอียดทางเทคนิคอย่างละเอียด ย่อมต้องการตอบโต้ข้อกล่าวอ้างเกี่ยวกับสงครามราคา และทำให้ “ปัญหาทางเทคนิคกลับคืนสู่เทคนิค ปัญหาทางการตลาดกลับคืนสู่การตลาด”
เธอเขียนในบล็อกว่า ประสิทธิภาพการให้เหตุผลของรุ่น MiMo-V2.5 ไม่ได้มาจากการพัฒนาจุดเดียวในขั้นตอนใดขั้นตอนหนึ่ง แต่เป็นผลลัพธ์จากการปรับปรุงแบบร่วมกันหลายมิติ Hybrid SWA ทำให้ทั้ง prefill และ decode ได้รับประโยชน์ แต่การดำเนินการ KVCache ที่ยังไม่ได้รับการปรับปรุงอย่างเพียงพอกลับทำให้ต้นทุนเพิ่มขึ้นในทุกขั้นตอน รอบเป้าหมายนี้ ทีม MiMo ได้รีวิวระบบการจัดการ KVCache, การแคชแบบแบ่งระดับ, และต้นไม้แคชคำนำหน้าอย่างเป็นระบบ แก้ไขปัญหาหลักของ SWA KVCache, ปรับปรุงกลยุทธ์การจัดตารางและเส้นทาง prefill/decode และผ่านการทดสอบในสถานการณ์จริงออนไลน์ สุดท้ายจึงสามารถแปลงข้อได้เปรียบด้านประสิทธิภาพเชิงทฤษฎีให้เป็นผลลัพธ์จริงในสภาพแวดล้อมการผลิต จน Hybrid SWA สามารถแสดงจุดแข็งของสถาปัตยกรรมในการให้เหตุผลแบบบทความยาวทั้งในด้านความแข็งแกร่งและประสิทธิภาพ เมื่อรวมกับการตั้งค่า MoE และการปรับปรุงต่างๆ สำหรับการให้เหตุผลแบบมัลติมีเดีย จึงเพิ่มประสิทธิภาพของบริการให้เหตุผลออนไลน์อย่างมาก
นี่คือกลยุทธ์เชิงระบบสำหรับวิศวกรรม AI และเป็นวิธีการลดต้นทุนที่ภาคอุตสาหกรรมควรพิจารณาและเรียนรู้ร่วมกัน
ไม่จำเป็นต้องเขียนบล็อกเกี่ยวกับสงครามราคา แต่จำเป็นต้องดำเนินการตามแผนทางวิศวกรรม