GLM 5.2 ครองพื้นที่ในไทม์ไลน์ AI มาสักพักแล้ว และการพูดคุยส่วนใหญ่ก็วนอยู่ที่ว่ามันเทียบกับ Opus ได้แค่ไหน นั่นคือประเด็นหลัก แต่ปริมาณงานกลับบอกเล่าเรื่องราวที่เงียบกว่า: บรรดานักพัฒนาที่ผมทำงานด้วยยังคงใช้ MiniMax M3 ในระดับ大规模 เพราะมันมอบความสามารถระยะยาวที่เทียบเคียงได้ในราคาที่ถูกกว่ามาก อันที่จริง MiniMax M3 ยังคงนำ GLM 5.2 ในด้านการใช้งานโทเค็นบน Open Router มากกว่า 50%

ที่มา: Open Router Rankings
ข้อจำกัดหลักของเอเจนต์ระยะยาวไม่ใช่เรื่องความฉลาด แต่เป็นต้นทุนของความใส่ใจ (attention) เมื่อบริบท (context) เพิ่มมากขึ้น @MiniMax_AI M3 ถูกสร้างขึ้นเพื่อขจัดข้อจำกัดนั้น หน้าต่างบริบท (context window) ขนาด 500K โทเค็นเป็นหนึ่งในขนาดที่ยาวที่สุดที่มีในโมเดล open-weight แต่ความสามารถที่สำคัญคือการคงอยู่กับงานเดียวเป็นเวลาหลายชั่วโมงในขณะที่บริบทเพิ่มขึ้นเรื่อยๆ M3 เป็น multimodal ที่มีความเข้าใจภาพและวิดีโอแบบเนทีฟ ดังนั้นเอเจนต์ตัวเดียวกันจึงสามารถทำงานกับข้อความ โค้ด และอินพุตภาพในการรันครั้งเดียว
โพสต์เปิดตัว ของ Fireworks ชี้ให้เห็นประเด็นเดียวกันจากฝั่งโครงสร้างพื้นฐาน โดยนำเสนอ M3 ว่าเป็นโมเดล open-weight ตัวแรกบน Fireworks ที่รวมการเขียนโค้ดระดับ前沿, ความเข้าใจภาพและวิดีโอแบบเนทีฟ และหน้าต่างบริบท 500K โทเค็นไว้ในระบบเดียว ข้อกล่าวอ้างในทางปฏิบัติที่สำคัญสำหรับบทความนี้คือสิ่งที่ Fireworks รายงานในโพสต์เปิดตัวนั้น M3 มีการถอดรหัสบริบทระยะยาวที่เร็วกว่า M2.7 ถึง 15 เท่า, การคำนวณต่อโทเค็นลดลงเหลือ 1/20 ที่บริบทระยะยาว และ Fireworks อ้างถึงการทำงานอัตโนมัติ 12 ถึง 24 ชั่วโมงในงานทำซ้ำเอกสารและการปรับแต่งเคอร์เนล CUDA
งานระยะยาวนั้นต้องการทรัพยากรมากเพราะบริบทไม่เคยหยุดเติบโต การรันเอเจนต์หลายชั่วโมงจะสะสมโค้ด, ログ, ผลลัพธ์จากเครื่องมือ และการให้เหตุผลขั้นกลาง และด้วย dense attention แบบมาตรฐาน ทุกโทเค็นใหม่จะอ่านทั้งหมดนั้นซ้ำอีกครั้ง ต้นทุนจะเพิ่มขึ้นตามกำลังสองของความยาว ดังนั้นยิ่งเอเจนต์ทำงานนานเท่าไหร่ แต่ละขั้นตอนก็ยิ่งแพงขึ้น นั่นคือเหตุผลในทางปฏิบัติที่ทำให้เอเจนต์ที่ทำงานนานส่วนใหญ่ต้องถูกตัดให้สั้นลง
กลไกที่เปลี่ยนแปลงสิ่งนี้คือ MiniMax Sparse Attention (MSA) ซึ่งอธิบายไว้ในรายงานล่าสุดของ MiniMax, MiniMax Sparse Attention MSA เปลี่ยนสิ่งที่โมเดลอ่านในแต่ละขั้นตอน ก่อนที่จะใส่ใจ (attend) มันจะทำการกรองล่วงหน้าแบบเบา: Index Branch จะให้คะแนนบริบทเป็นบล็อก เลือกบล็อกที่เกี่ยวข้องมากที่สุดกับโทเค็นปัจจุบัน และโมเดลจะใส่ใจเฉพาะบล็อกเหล่านั้น มันอ่านดัชนีแทนที่จะอ่านทั้งห้องสมุด ซึ่งทำให้ต้นทุนในแต่ละขั้นตอนคงที่โดยประมาณ แม้ว่าบริบทจะเพิ่มขึ้นเป็นหลายแสนโทเค็น
MiniMax Sparse Attention: Index Branch แบบเบาจะให้คะแนน key-value blocks และเลือก top-k ต่อ query group และ main branch จะใส่ใจเฉพาะบล็อกเหล่านั้น ที่มา: MiniMax Sparse Attention paper.
ความหมายสำหรับคุณหากกำลังสร้างด้วย M3:
- ต้นทุนที่คาดการณ์ได้ทุกความยาว เอกสารกำหนด Bk = 128 และ k = 16 ดังนั้นแต่ละ query และ GQA group จะเลือก 16 บล็อก หรือ 2,048 key-value tokens การรันที่ยาวนานยังมีค่าใช้จ่ายในการทำดัชนี แต่เมน attention budget ยังคงที่
- บริบทระยะยาวราคาถูก ในการกำหนดค่าโมเดลของเอกสาร พวกเขารายงานการลด FLOPs ของ attention ต่อโทเค็นลง 28.4 เท่าที่ความยาวลำดับที่มาก เมื่อเทียบกับ dense GQA ภายใต้การตั้งค่า head เดียวกัน
- เร็วในระบบ production บน H800 ที่ความยาวลำดับมาก พวกเขารายงานความเร็ว prefill เพิ่มขึ้น 14.2 เท่า และ decoding เพิ่มขึ้น 7.6 เท่า (wall-clock speedups) การ benchmark top-k แยกต่างหากระบุว่าเคอร์เนลเฉพาะของ MiniMax นั้นเร็วที่สุดเมื่อเทียบกับ torch.topk และ TileLang ในการตั้งค่าที่ทดสอบทั้งหมด
- ต้นทุนคุณภาพน้อยที่สุด ในการทดลอง 109B MoE เอกสารรายงานพารามิเตอร์ที่ทำงานอยู่ 6B ต่อโทเค็น และกล่าวว่า MSA-CPT ยังคงใกล้เคียงกับ baseline full-attention หลังจากการขยายบริบทระยะยาว มันประเมิน MMLU, GSM8K, HumanEval, RULER, HELMET และ benchmark อื่นๆ อีกมากมาย ในขณะที่แต่ละ query ใส่ใจกับ 2,048 โทเค็น
Per-token attention FLOPs และ latency ยังคงเกือบคงที่สำหรับ MSA เมื่อความยาวลำดับเพิ่มขึ้น ในขณะที่ dense GQA (grouped-query attention) เพิ่มขึ้นอย่างรวดเร็ว: คำนวณน้อยลง 28.4 เท่า, prefill เร็วขึ้น 14.2 เท่า และ decoding เร็วขึ้น 7.6 เท่าที่ความยาวลำดับมาก ที่มา: MiniMax Sparse Attention paper.
สิ่งนี้ปลดล็อคอะไรบ้าง
ส่วนที่น่าสนใจไม่ใช่แค่ M3 สามารถเก็บโทเค็นได้มากขึ้น แต่คือบริบทระยะยาวมีราคาถูกและเร็วพอที่จะอยู่ในระบบวนซ้ำที่ต้องคงสถานะไว้เมื่อเวลาผ่านไป
- เอเจนต์ที่ปรับปรุงตัวเองได้ นี่คือแอปพลิเคชันแรกที่ผมจะจับตามอง เอเจนต์ที่ปรับปรุงตัวเองได้ต้องเก็บโค้ดปัจจุบัน, การแก้ไขที่ล้มเหลวก่อนหน้านี้, ログการประเมิน, ผลลัพธ์ benchmark และสมมติฐานของตัวเองไว้ในมุมมอง ขณะที่มันเสนอการเปลี่ยนแปลงครั้งต่อไป Sparse attention ไม่ได้แก้ปัญหาการประเมิน แต่มันทำให้วงจรการเสนอ, ตรวจสอบ และแก้ไขที่ทำงานยาวนาน มีโอกาสล่มน้อยลงมากเนื่องจากต้นทุนบริบท
- วิศวกรรมระดับ repository Fireworks เน้นย้ำความเข้าใจโค้ดทั้ง repository และการเขียนโค้ดแบบ agentic ที่แข็งแกร่ง นั่นสำคัญเพราะงานวิศวกรรมจริงไม่ค่อยพอดีกับ prompt ที่เรียบร้อย การดีบักข้าม codebase, การติดตาม regression และการเปลี่ยนแปลงหลายไฟล์ ล้วนได้ประโยชน์จากเอเจนต์ที่สามารถเก็บ repository, ผลลัพธ์การทดสอบ และประวัติการแก้ไขไว้ในเซสชันเดียว
- งานวิจัยทางวิทยาศาสตร์และระบบ Fireworks ชี้ไปที่การทำงานอัตโนมัติระยะยาวในการทำซ้ำเอกสารและการปรับแต่งเคอร์เนล CUDA ตัวอย่างเหล่านี้มีประโยชน์เพราะงานไม่ใช่คำตอบเดียว แต่เป็นลำดับของการทดลอง, ログ, ความล้มเหลว, การแก้ไข และการวัดผล ซึ่งความต่อเนื่องคือคุณสมบัติของผลิตภัณฑ์
- เวิร์กโฟลว์ multimodal บริบทระยะยาว M3 เป็น multimodal แบบเนทีฟ ไม่ใช่แค่ข้อความที่มีการมองเห็นต่อท้าย มันรวมบริบทระยะยาวเข้ากับความเข้าใจภาพและวิดีโอแบบเนทีฟ ดังนั้นการรันครั้งเดียวสามารถให้เหตุผลข้ามข้อความ, โค้ด, ภาพหน้าจอ, ไดอะแกรม และเฟรมวิดีโอไปพร้อมกัน สิ่งนี้เปิดทางไปสู่การแปลงภาพเป็นโค้ดจาก mockup หรือภาพหน้าจอ, การวิเคราะห์วิดีโอ, การตรวจสอบเอกสาร multimodal และเอเจนต์ที่คงบริบทภาพไว้พร้อมกับร่องรอยโค้ดและเครื่องมือตลอดเซสชันยาว
นี่คือสาเหตุที่โมเดลนี้น่าสนใจสำหรับนักพัฒนา มันย้ายบริบทระยะยาวจากคุณสมบัติการอ่านเอกสาร ไปสู่พื้นผิวการทำงาน (execution substrate) สำหรับเอเจนต์ที่ต้องการความจำ, การวนซ้ำ และการตรวจสอบ
เป็นที่น่าสังเกตว่าทำไมสิ่งนี้ถึงมาถึงตอนนี้ MiniMax นำเสนอ sparse attention ในช่วงรุ่น M2 และพักไว้เพราะโครงสร้างพื้นฐานยังไม่สมบูรณ์ สำหรับ M3 จุดเน้นอยู่ที่เคอร์เนล MSA แบ่งพาร์ติชันบริบทออกเป็นบล็อก อ่านแต่ละบล็อกครั้งเดียวด้วยการเข้าถึงหน่วยความจำแบบต่อเนื่อง และใส่ใจเฉพาะบล็อกที่เกี่ยวข้อง ซึ่งทำให้มันทำงานเร็วกว่าวิธี sparse attention แบบเปิดอื่นๆ หลายเท่า ในขณะที่รักษาคุณภาพ
สิ่งนี้เชื่อมโยงโดยตรงกับงานวิศวกรรมบริบทที่ผมให้ความสำคัญ เป็นเวลาหลายปีที่ผมสนับสนุนให้นักพัฒนาคัดสรรสิ่งที่เข้าไปในหน้าต่างบริบท MSA คือโมเดลที่เรียนรู้ที่จะคัดสรรสิ่งที่มันใส่ใจภายในหน้าต่าง หลักการเดียวกันขยับลงไปอีกชั้นในสถาปัตยกรรม
สำหรับนักพัฒนาและนักวิจัย นี่คือความแตกต่างระหว่างการสาธิตสั้นๆ กับเครื่องมือที่คุณพึ่งพาได้ มันหมายถึงเอเจนต์ที่อ่านทั้ง repository ในครั้งเดียว, ดีบักข้าม codebase ทั้งหมดในเซสชันต่อเนื่องเดียว หรือทำงานวิจัยผ่านการทดลอง, ログ และการแก้ไขเป็นเวลาหลายชั่วโมงโดยไม่สูญเสียบริบท ในการรันระยะยาวของ MiniMax เอง ผลลัพธ์ที่แข็งแกร่งที่สุดมักจะเกิดขึ้นลึกเข้าไปในเซสชันหลายชั่วโมง หลังจากที่โมเดลส่วนใหญ่จะถึงที่ราบสูงและหยุดไปนานแล้ว บริบทระยะยาวที่ราคาไม่แพงคือสิ่งที่ทำให้เอเจนต์มีความพากเพียรแบบนั้น
นี่คือส่วนที่ผมพบว่าน่าสนใจที่สุด เอเจนต์ที่ผมสร้างมักจะล้มเหลวไม่ใช่เพราะโมเดลอ่อนแอ แต่เพราะพวกมันไม่สามารถทำงานระยะยาวได้ และบริบทระยะยาวที่เชื่อถือได้คือโครงสร้างพื้นฐานพื้นฐานที่จัดการกับปัญหานี้ในที่สุด
จะเริ่มต้นกับ MiniMax M3 ได้ที่ไหน
สำหรับทีมเทคนิค จุด @FireworksAI_HQ นั้นใช้งานได้จริง การออกแบบ sparse-attention ของ M3 จะมีประโยชน์ก็ต่อเมื่อเลเยอร์การให้บริการสามารถรักษา latency, throughput และต้นทุนให้คงที่ที่บริบทระยะยาว Fireworks กล่าวว่ามันขับเคลื่อน API inference แรกของ MiniMax, นำเสนอ endpoint ที่เร็วที่สุดในซีรีส์โมเดล MiniMax และกำหนดราคา M3 เริ่มต้นที่ $0.60 ต่อ 1M input tokens พร้อมตัวเลือกการปรับใช้แบบ serverless และ on-demand ในอัตรานั้น M3 มีราคาถูกกว่า GLM 5.2 ประมาณ 75% สำหรับการใช้งานที่เทียบเคียงได้ ซึ่งทำให้เรื่องราวไม่ใช่แค่หน้าต่างบริบทที่ใหญ่ขึ้น แต่อยู่ที่ว่าเอเจนต์ระยะยาวสามารถทำงานได้อย่างประหยัดในระบบ production หรือไม่
การกำหนดราคามีประโยชน์เพราะมันจัดกรอบ M3 ใหม่เป็นเส้นทางอัปเกรดจาก M2.7 ไม่ใช่แค่โมเดล frontier ใหม่ Fireworks กล่าวว่าราคาเปิดตัว open-weight ลดลงมาอยู่ในระดับเดียวกับ M2.7 สำหรับการใช้งาน serverless มาตรฐาน ดังนั้นทีมงานจะได้รับบริบทระยะยาวและความเข้าใจ multimodal แบบเนทีฟของ M3 โดยไม่ต้องจ่ายพรีเมียมเหนือรุ่นก่อนหน้า
ในการทดสอบ M3 ให้ใช้ endpoint chat completions ของ Fireworks เดียวกับที่คุณใช้กับโมเดล Fireworks อื่นๆ model id คือ accounts/fireworks/models/minimax-m3 และเนื่องจากโมเดลเป็น multimodal คำขอเดียวจึงสามารถรวมข้อความบวกกับ URL รูปภาพในข้อความเดียวกันได้
1import json2import requests34url = "https://api.fireworks.ai/inference/v1/chat/completions"56payload = {7 "model": "accounts/fireworks/models/minimax-m3",8 "max_tokens": 32768,9 "temperature": 0.6,10 "top_p": 1,11 "top_k": 40,12 "messages": [13 {14 "role": "user",15 "content": [16 {"type": "text", "text": "คุณช่วยอธิบายภาพนี้ได้ไหม?"},17 {18 "type": "image_url",19 "image_url": {20 "url": "https://images.unsplash.com/photo-1582538885592-e70a5d7ab3d3?auto=format&fit=crop&w=1770&q=80"21 },22 },23 ],24 }25 ],26}2728headers = {29 "Accept": "application/json",30 "Content-Type": "application/json",31 "Authorization": "Bearer <FIREWORKS_API_KEY>",32}3334response = requests.post(url, headers=headers, data=json.dumps(payload), timeout=120)35response.raise_for_status()36print(response.json())
สำหรับงาน agentic หรือ reasoning ที่ยากขึ้น ให้เพิ่ม "thinking": {"type": "enabled"} ลงใน payload สำหรับปริมาณงาน production Fireworks วางตำแหน่ง serverless เป็นเส้นทางที่เร็วที่สุดในการประเมินผล และ on-demand deployments เป็นตัวเลือกสำหรับ throughput ที่คาดการณ์ได้
ลองใช้งานได้ที่นี่:Fireworks AI





