MiniMax M2.7: โมเดลที่สามของเครือข่าย Gonka

MiniMax M2.7 เป็นโมเดลภาษาขนาดใหญ่ (LLM) จากบริษัท MiniMax ซึ่งตั้งอยู่ในเซี่ยงไฮ้ MiniMax ก่อตั้งขึ้นในปี 2021 โดยทีมนักวิจัยภายใต้การนำของ Yan Junjie (เคยทำงานที่ SenseTime) และได้กลายเป็นหนึ่งในห้องปฏิบัติการ AI ชั้นนำของจีนอย่างรวดเร็ว บริษัทได้ระดมทุนจาก Alibaba, Tencent และ HongShan ซึ่งเป็นกลุ่มนักลงทุนเชิงกลยุทธ์เดียวกันกับที่อยู่เบื้องหลัง “เสือ AI ของจีน” อื่นๆ รวมถึง Moonshot AI ผู้พัฒนา Kimi K2.6

นอกเหนือจากโมเดลภาษาล้วนๆ แล้ว MiniMax ยังเป็นที่รู้จักกันดีในด้านผลิตภัณฑ์สำหรับผู้บริโภค: ผู้ช่วยแชท Talkie และ Hailuo รวมถึงหนึ่งในเครื่องกำเนิดวิดีโอที่โดดเด่นที่สุดในอุตสาหกรรม แต่สำหรับเครือข่าย Gonka สิ่งสำคัญคือกลุ่มผลิตภัณฑ์โมเดลข้อความซีรีส์ M ซึ่งเป็นรุ่นต่อจากโมเดล abab ที่เก่ากว่า

คุณลักษณะทางสถาปัตยกรรมหลักของซีรีส์ M คือการให้ความสำคัญกับกลไกความสนใจที่มีประสิทธิภาพ หากโมเดลขนาดใหญ่รุ่นก่อนๆ ใช้ quadratic attention แบบคลาสสิก (ต้นทุนการคำนวณจะเพิ่มขึ้นตามสัดส่วนกำลังสองของความยาวบริบท) MiniMax เป็นหนึ่งในผู้บุกเบิกการนำ linear attention แบบไฮบริดออกสู่สาธารณะ สิ่งนี้ช่วยให้สามารถประมวลผลลำดับที่ยาวมากได้โดยไม่มีการเพิ่มขึ้นอย่างรวดเร็วของต้นทุนการคำนวณ ซึ่งเป็นจุดเด่นทางประวัติศาสตร์ของกลุ่มผลิตภัณฑ์ เช่นเดียวกับ Qwen3-235B และ Kimi K2.6 โมเดลนี้สร้างขึ้นบนสถาปัตยกรรม MoE (Mixture of Experts): พารามิเตอร์หลายแสนล้านรายการ “บนกระดาษ” แต่สำหรับทุกคำขอจะมีการเปิดใช้งานเพียงส่วนเล็กๆ ซึ่งช่วยลดต้นทุนการอนุมานได้อย่างมาก

ในเครือข่าย Gonka โมเดลจะถูกระบุว่าเป็น MiniMaxAI/MiniMax-M2.7 — นี่คือสตริงที่ต้องส่งในฟิลด์ model ของคำขอ API เวอร์ชัน M2.7 เป็นรุ่นปรับปรุงล่าสุดของซีรีส์ M ณ เวลาที่เผยแพร่บทความ

สิ่งสำคัญคือต้องแยกความแตกต่างระหว่างคุณสมบัติของโมเดล “ออกจากกล่อง” และคุณสมบัติที่นำไปใช้ในเครือข่ายเฉพาะ เมื่อโมเดลทำงานในเครือข่าย Gonka แบบกระจายอำนาจ พารามิเตอร์การทำงานของมันจะถูกกำหนดโดยการกำหนดค่า vLLM-inference บนโฮสต์ GPU ไม่ใช่แค่สถาปัตยกรรมของโมเดล นี่คือค่าจริงที่ Gateway ของเราส่งคืน:

• หน้าต่างบริบท: 131,072 โทเค็น (ประมาณ 100,000 คำ) นี่คือการกำหนดค่า subnet ในเครือข่าย Gonka สถาปัตยกรรม MiniMax เองรองรับบริบทที่ยาวกว่ามาก แต่เพดานในทางปฏิบัติ ณ ทุกเวลาจะถูกกำหนดโดยการตั้งค่าการอนุมานบนโฮสต์
• ผลลัพธ์สูงสุด: 4,096 โทเค็นต่อการตอบกลับหนึ่งครั้ง ตัวเลขนี้ถูกวัดเชิงประจักษ์ — โดยการร้องขอด้วยการสร้างที่ยาวที่ถูกบังคับซึ่งชนเพดาน (finish_reason: length) สำหรับการเปรียบเทียบ เพดานนี้สำหรับ Qwen3-235B คือ 8,192 และสำหรับ Kimi K2.6 คือ 3,072 โทเค็น นี่ไม่ใช่ข้อจำกัดของโมเดลเอง แต่เป็นการกำหนดค่าของ vLLM-subnet
• ข้อกำหนด VRAM ของโฮสต์: ประมาณ 320 GB VRAM ต่อโหนด นี่เป็นข้อกำหนดทั่วไปสำหรับโมเดล MoE ขนาดใหญ่ในการควอนไตซ์ FP8 — Qwen3-235B และ Kimi K2.6 ต้องการ 320 GB เท่ากัน ในทางปฏิบัติหมายถึง GPU หลายตัวในระดับ H100/H200 รวมกันเป็นโหนดเดียว

ราคา inference ในเครือข่าย Gonka ไม่ขึ้นอยู่กับการเลือกโมเดลและถูกกำหนดโดยพารามิเตอร์เครือข่าย: ผ่าน JoinGonka Gateway MiniMax M2.7 มีให้บริการในอัตราเดียวกับ Qwen และ Kimi ราคาที่เป็นหนึ่งเดียวเป็นผลมาจากความจริงที่ว่าเครือข่ายนี้อิงตามการคำนวณต้นทุนเดียวสำหรับงานคอมพิวเตอร์ ไม่ใช่ราคาของผู้จำหน่ายเฉพาะ

เป็นครั้งแรกที่ผู้ใช้เครือข่าย Gonka มีทางเลือกจากโมเดลเรือธงสามรุ่น และทั้งสามรุ่นสามารถเข้าถึงได้ผ่านอินเทอร์เฟซที่เข้ากันได้กับ OpenAI แบบครบวงจร JoinGonka Gateway การเปรียบเทียบด้านล่างนี้ช่วยให้เข้าใจว่าแต่ละโมเดลเหมาะสมกับโปรไฟล์งานประเภทใด ไม่ใช่ว่า “รุ่นไหนดีกว่า”

ข้อจำกัดความรับผิดชอบที่สำคัญเกี่ยวกับเกณฑ์มาตรฐานในปี 2026: ช่องว่างระหว่างโมเดล open-weights ชั้นนำในการทดสอบสาธารณะลดลงเหลือไม่กี่เปอร์เซ็นต์ และความแตกต่างนี้มักจะอยู่ในขอบเขตของข้อผิดพลาดทางสถิติของเกณฑ์มาตรฐานเอง สำหรับการทำงานจริง สิ่งที่สำคัญไม่ใช่ตำแหน่งสัมบูรณ์ในการจัดอันดับ MMLU แต่เป็นลักษณะของงาน: ความยาวของบริบท ความซับซ้อนของห่วงโซ่ตรรกะ ภาษาที่ต้องการ การมี tool calling

แนวทางปฏิบัติ: สำหรับงานที่มีเอกสารยาวมากและการประมวลผลข้อความจำนวนมาก ควรทดสอบ MiniMax M2.7 — attention ที่มีประสิทธิภาพของซีรีส์นี้ได้รับการปรับให้เหมาะสมสำหรับสถานการณ์ดังกล่าวในอดีต สำหรับการทำงานหลายภาษาแบบสากลและ tool calling ที่เสถียรในการผลิต ตัวเลือกที่พิสูจน์แล้วคือ Qwen3-235B สำหรับงาน reasoning ที่มีตรรกะซับซ้อน — Kimi K2.6 กลยุทธ์ที่ดีที่สุดในการผลิตคือการเก็บโมเดลทั้งสามไว้ในโค้ดและสลับไปมาระหว่างกันด้วยพารามิเตอร์ model เพียงตัวเดียวโดยไม่เปลี่ยนสถาปัตยกรรมแอปพลิเคชัน

การเพิ่ม MiniMax M2.7 ไม่ใช่ “การอัปโหลดไฟล์ไปยังเซิร์ฟเวอร์” แต่เป็นผลมาจากการอัปเกรดเครือข่ายที่ผ่านการลงคะแนนเสียงแบบ on-chain การสนับสนุนโมเดลรวมอยู่ในโปรโตคอล v0.2.13 ซึ่งได้รับการอนุมัติโดยข้อเสนอ #54: ได้รับการยอมรับเมื่อวันที่ 21 พฤษภาคม 2026 (ประมาณ 63% ของคะแนนเสียง “เห็นด้วย”) และเปิดใช้งานที่ความสูงของบล็อกที่กำหนด นี่คือกลไกการกำกับดูแลเดียวกันกับที่เครือข่ายใช้ในการเปลี่ยนแปลงที่สำคัญใดๆ — ตั้งแต่ค่าธรรมเนียมไปจนถึงโมเดลใหม่

การเป็นหลายโมเดลสำหรับเครือข่ายแบบกระจายอำนาจเป็นขั้นตอนที่สำคัญ เครือข่ายที่ผูกอยู่กับโมเดลเดียวมีความเปราะบางพื้นฐาน: การเปิดตัวโมเดลเวอร์ชันใหม่จะกลายเป็นวิกฤตการย้ายข้อมูล และความล้มเหลวของโมเดลเดียวจะทำให้บริการทั้งหมดล่ม เครือข่ายที่สามารถเก็บโมเดลหลายตัวพร้อมกันจะพัฒนาอย่างราบรื่น: โมเดลใหม่จะถูกเพิ่มเป็น “ช่องทาง” เพิ่มเติม โมเดลเก่าจะยังคงทำงานต่อไป และโฮสต์ GPU จะได้รับทางเลือกในการให้บริการอะไร กลไกเดียวกันนี้ (DevShards) เคยถูกใช้สำหรับการเปิดตัว Kimi K2.6

ข้อควรระวังพิเศษสำหรับช่วงเริ่มต้น: อาจมีความล่าช้าระหว่าง “โมเดลปรากฏในรายการเครือข่าย” และ “โมเดลเปิดให้ลูกค้าทุกคน” ในช่วงแรก การอนุมาน MiniMax M2.7 ในโหมด broker มีให้บริการเฉพาะคีย์พิเศษและส่งข้อผิดพลาดสำหรับการร้องขอปกติ — เป็นขั้นตอนการทดลองใช้งานตามปกติ เมื่อปลายเดือนพฤษภาคม 2026 การเข้าถึงสาธารณะได้เปิดขึ้น และโมเดลก็พร้อมใช้งานสำหรับลูกค้า Gateway ทุกคน ดูรายละเอียดเพิ่มเติมเกี่ยวกับโครงสร้างเครือข่ายและเหตุผลที่โมเดลเปิดตัวในลักษณะนี้ — ในบทความเกี่ยวกับ สถาปัตยกรรมเครือข่าย Gonka

วิธีที่ตรงที่สุดคือผ่าน JoinGonka API Gateway เนื่องจาก Gateway ให้บริการ OpenAI-compatible API โค้ดเดียวกันที่ใช้กับ GPT, Claude, Qwen หรือ Kimi จะเริ่มทำงานกับ MiniMax หลังจากเปลี่ยนค่าของฟิลด์ model

ตัวอย่างน้อยที่สุดผ่าน curl:

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [
      {"role": "user", "content": "อธิบายสั้นๆ ว่า linear attention คืออะไร"}
    ]
  }'

คำขอเดียวกันใน Python ผ่านไลบรารี openai:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://gate.joingonka.ai/v1",
)

response = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "สวัสดี MiniMax"}],
)
print(response.choices[0].message.content)

Streaming (Server-Sent Events) — สำหรับอินเทอร์เฟซแบบอินเทอร์แอคทีฟที่แสดงคำตอบในขณะที่กำลังสร้าง:

stream = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "เขียนเรียงความสั้นๆ เกี่ยวกับบริบทยาว"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

เมื่อคุณ ลงทะเบียน ที่ JoinGonka Gateway คุณจะได้รับ 10 ล้านโทเค็นฟรีสำหรับการทดสอบโมเดลเครือข่ายใดๆ — ซึ่งเพียงพอที่จะเปรียบเทียบโมเดลทั้งสามกับงานของคุณเอง

ความเข้ากันได้กับเครื่องมือพัฒนา: ทุกสิ่งที่ทำงานกับ OpenAI API ก็ทำงานกับ MiniMax ผ่าน Gateway ด้วย เพียงแค่เปลี่ยนพารามิเตอร์ model:

• Cursor: ในการตั้งค่า Custom Model ให้ระบุ MiniMaxAI/MiniMax-M2.7
• Claude Code, Cline, Continue.dev: ชื่อโมเดลใน config
• LangChain, n8n: พารามิเตอร์ model เมื่อเริ่มต้นไคลเอนต์

รายการโมเดลปัจจุบันสามารถเข้าถึงได้เสมอใน endpoint GET /v1/models — สะดวกในการดึงข้อมูลแบบไดนามิกเพื่อให้ UI ของแอปพลิเคชันของคุณแสดงชุดข้อมูลล่าสุด หากได้รับ 429 too many concurrent requests — เป็นระยะที่ปกติสำหรับโมเดลใหม่ในระยะเริ่มต้นของการเติบโตของเครือข่าย: โปรดลองส่งคำขออีกครั้งในอีกไม่กี่วินาที

การมีสามโมเดลในเครือข่ายเดียวกันมีค่าตรงที่สามารถเลือกเครื่องมือที่แตกต่างกันสำหรับงานที่แตกต่างกันได้โดยไม่จำเป็นต้องเปลี่ยนผู้ให้บริการหรือโค้ดการรวม นี่คือสถานการณ์ที่ควรเริ่มต้นการทดสอบด้วย MiniMax M2.7

การวิเคราะห์เอกสารยาวๆ หากงานคือการสรุปสัญญา การวิเคราะห์เอกสารทางเทคนิค การประมวลผลข้อความทางกฎหมายหรือการเงินขนาดใหญ่ attention ที่มีประสิทธิภาพของซีรีส์ M ได้รับการปรับแต่งมาเพื่อรักษาบริบทที่ยาวโดยไม่มีต้นทุนเพิ่มขึ้นอย่างรวดเร็ว ส่งเอกสารทั้งหมดในการร้องขอเดียวและให้โมเดลทำงานกับปริมาณทั้งหมดพร้อมกัน ไม่ใช่เป็นส่วนๆ

RAG และการทำงานกับฐานความรู้ ในสถานการณ์ Retrieval-Augmented (RAG) ที่มีการผสมผสานข้อมูลหลายสิบส่วนจากฐานข้อมูลเวกเตอร์เข้าไปในบริบท ความสามารถของโมเดลในการรักษาชิ้นส่วนข้อความที่หลากหลายจำนวนมากมีผลโดยตรงต่อคุณภาพของคำตอบ นี่เป็นจุดแข็งโดยธรรมชาติสำหรับโมเดลที่มีบริบทที่ยาว

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

เมื่อใดควรเลือกโมเดลอื่น หากแอปพลิเคชันของคุณต้องการคำตอบที่ยาวมากในการร้องขอเดียว (เอกสารที่สร้างขึ้นขนาดใหญ่ ส่วนโค้ดจำนวนมาก) โปรดจำเพดานผลลัพธ์ 4,096 โทเค็น — Qwen3-235B มีเพดานสูงกว่าสองเท่า (8,192) หากการเรียกใช้งาน tool calling แบบ native ที่เสถียรมีความสำคัญต่อการใช้งานจริง — Qwen3-235B ได้รับการพิสูจน์มานานกว่า สำหรับงานที่มีการให้เหตุผลที่ซับซ้อนหลายขั้นตอน ควรเปรียบเทียบคำตอบกับ Kimi K2.6 คำแนะนำทั่วไป: เรียกใช้ชุดคำร้องขอจริงของคุณผ่านโมเดลทั้งสามและเปรียบเทียบผลลัพธ์ — 10 ล้านโทเค็นฟรีเมื่อลงทะเบียนเพียงพอสำหรับการทดสอบเปรียบเทียบที่สมบูรณ์

ในทางเทคนิค การสลับระหว่างโมเดลคือการเปลี่ยนหนึ่งบรรทัดในฟิลด์ model ดังนั้นสถาปัตยกรรมแอปพลิเคชันที่ดีบนเครือข่าย Gonka จะไม่ “เลือกโมเดลตลอดไป” แต่จะอนุญาตให้กำหนดเส้นทางคำร้องขอระหว่าง Qwen, Kimi และ MiniMax ขึ้นอยู่กับประเภทของงาน — การอนุมานที่มีราคาถูกทำให้การกำหนดเส้นทางดังกล่าวคุ้มค่าทางเศรษฐกิจ