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 ก็สามารถเลือกว่าจะให้บริการอะไร ในทางเทคนิคแล้ว แต่ละโมเดลจะอยู่ใน shard ของเครือข่ายตัวเอง ซึ่งเป็นกลไกเดียวกันกับที่ (DevShards) เคยใช้ในการรัน Kimi K2.6 มาก่อน

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

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

วิธีที่ตรงที่สุดคือผ่านทาง 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": "เขียนเรียงความสั้นๆ เกี่ยวกับ context ยาวๆ"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

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

ความเข้ากันได้กับเครื่องมือพัฒนา: ทุกสิ่งที่ทำงานร่วมกับ 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 ที่มีการเพิ่มข้อมูลหลายสิบส่วนจากฐานข้อมูลเวกเตอร์ลงใน context ความสามารถของโมเดลในการรักษาชิ้นส่วนข้อความที่หลากหลายส่งผลโดยตรงต่อคุณภาพของคำตอบ นี่เป็นจุดเด่นสำหรับโมเดลที่มี context ยาว

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

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

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