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

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

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

• Context window: 200,000 token (ประมาณ 150,000 คำ) นี่คือการกำหนดค่า subnet ในเครือข่าย Gonka แม้แต่สถาปัตยกรรม MiniMax เองจะรองรับ Context ที่ยาวกว่านี้อย่างมาก แต่ขีดจำกัดทางปฏิบัติในแต่ละช่วงเวลาจะถูกกำหนดโดยการตั้งค่า inference บนโฮสต์
• Output สูงสุด: 8,192 token ต่อหนึ่งคำตอบ ตัวเลขนี้ถูกวัดในเชิงประจักษ์โดยการส่งคำขอให้สร้างข้อความยาวจนถึงขีดจำกัด (finish_reason: length) ขณะนี้ขีดจำกัดนี้เท่ากันสำหรับโมเดลทุกตัวในเครือข่าย คือสูงสุด 8,192 token ซึ่งไม่ใช่ขีดจำกัดของตัวโมเดลเอง แต่เป็นส่วนหนึ่งของการกำหนดค่า vLLM-subnet
• ข้อกำหนด VRAM ของโฮสต์: ประมาณ 320 GB VRAM ต่อโหนด นี่เป็นข้อกำหนดทั่วไปสำหรับโมเดลขนาดใหญ่แบบ MoE ในการทำ quantization ด้วย FP8 ซึ่งใช้ 320 GB เท่ากันกับ Kimi K2.6 ในทางปฏิบัติหมายถึงต้องใช้ GPU ระดับ H100/H200 หลายตัวรวมกันในโหนดเดียว

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

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

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

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

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

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

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

MiniMax M2.7 ตัวเดียวกันผ่าน OpenRouter ราคาอยู่ที่ $0.279/$1.20 ต่อ 1M ในขณะที่ JoinGonka คิดราคาเพียง $0.003/$0.009

วิธีที่ตรงที่สุดคือผ่าน JoinGonka API Gateway เนื่องจาก Gateway จัดเตรียม OpenAI-compatible API รหัสเดียวกับที่ใช้กับ GPT, Claude หรือ 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)

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

stream = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "เขียนเรียงความสั้นๆ เกี่ยวกับ long context"}],
    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: ชื่อโมเดลในไฟล์คอนฟิก
• LangChain, n8n: พารามิเตอร์ model เมื่อเริ่มต้นใช้งาน Client

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

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

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

RAG และการทำงานกับฐานความรู้: ในสถานการณ์ retrieval-augmented ที่มีการผสมผสานข้อมูลหลายสิบส่วนจากเวกเตอร์ฐานข้อมูล ความสามารถของโมเดลในการรักษาชิ้นส่วนข้อความที่หลากหลายมีผลโดยตรงต่อคุณภาพของคำตอบ นี่คือช่องทางธรรมชาติสำหรับโมเดลที่มี long context

การประมวลผลทรานสคริปต์และบันทึก: ถอดความการโทร, การสนทนาของฝ่ายสนับสนุนที่ยาว, สตรีมมิ่งบันทึก (logs) ซึ่งเป็นงานที่มีปริมาณข้อมูลขาเข้ามากแต่คำตอบมักจะสั้น ที่นี่ขีดจำกัด output ที่ 8 192 โทเค็นไม่เป็นอุปสรรค: ขาเข้ามีข้อมูลมากและขาออกเป็นเพียงสรุปหรือข้อมูลที่สกัดออกมา

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

ในทางเทคนิค การสลับระหว่างโมเดลคือการเปลี่ยนบรรทัดเดียวในฟิลด์ model ดังนั้นสถาปัตยกรรมแอปที่ชาญฉนบนเครือข่าย Gonka จะไม่ "เลือกโมเดลถาวร" แต่ช่วยให้สามารถกำหนดเส้นทางคำขอระหว่าง Kimi K2.6 และ MiniMax M2.7 ตามประเภทของงาน ซึ่งการทำ inference ราคาประหยัดทำให้การกำหนดเส้นทางดังกล่าวมีความคุ้มค่าทางเศรษฐกิจ