Mistral Large 4 เปิด public preview: โมเดลใหญ่ขึ้น แต่คำตอบสำคัญยังอยู่หลังคำว่า preview

Mistral AI เปิด public preview ของ Mistral Large 4 เมื่อ 6 ตุลาคม 2026 พร้อมตัวเลขที่สะดุดตา: mixture-of-experts ขนาดรวมหนึ่งล้านล้านพารามิเตอร์ แต่เปิดใช้ประมาณ 49 พันล้านพารามิเตอร์ต่อ token รองรับมากกว่า 160 ภาษา และรวม text กับ vision ไว้ในโมเดลเดียวกันครับ บริษัทบอกว่าเปิดใช้ผ่าน Mistral Studio แล้ว ส่วน weights ตั้งเป้าปล่อยปลายเดือนตุลาคม

ข่าวนี้น่าสนใจเพราะการแข่งขันไม่ได้มีแค่ “ใครมีโมเดลใหญ่ที่สุด” แต่เป็น “ใครส่งมอบโมเดลที่องค์กรควบคุมต้นทุน ข้อมูล และ deployment ได้จริง” อย่างไรก็ตามคำว่า public preview ยังสำคัญมาก ตัวเลข benchmark ในประกาศเป็นผลจากผู้ผลิต และ artifacts ที่คนภายนอกต้องใช้ตรวจซ้ำ—weights, model card ฉบับสมบูรณ์, serving recipe และเงื่อนไข license—ยังมาไม่ครบ

สรุป 30 วินาที

• Mistral ระบุ ว่า Large 4 เป็น multimodal MoE ขนาดรวม 1T parameters ใช้งานประมาณ 49B ต่อ token และรองรับภาษาเกิน 160 ภาษา
• การใช้ experts บางส่วนต่อ token มีเป้าหมายให้ capacity สูงโดยไม่จ่าย compute เท่ากับ dense model หนึ่งล้านล้านพารามิเตอร์ทุกครั้ง
• โมเดลอยู่ใน public preview ผ่าน Mistral Studio; weights ยังไม่ออกในวันที่ตรวจ และบริษัทคาดว่าจะออกปลายเดือน
• บริษัทอ้างว่า train บน NVIDIA GB GPU ประมาณ 3,800 ตัว ตัวเลขนี้ช่วยเห็นขนาดโครงการ แต่ยังไม่พอคำนวณต้นทุน inference ของ workload เรา
• Axios และ Le Monde วางข่าวนี้ในสนามแข่ง open-weight กับผู้เล่นจีนและสหรัฐฯ ซึ่งเป็นบริบทธุรกิจ ไม่ใช่ผลรับรองคุณภาพโมเดล
• ข้อสรุปวันนี้จึงเป็น “น่าทดลองแบบมี guardrail” ไม่ใช่ “พร้อมย้าย production”

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าทีมใช้ AI ผ่าน API อย่างเดียว เราอาจมองว่ารุ่นใหม่คือรายการใน dropdown แต่ open-weight model เปลี่ยนสมการมากกว่านั้น องค์กรสามารถวาง inference ในภูมิภาคที่ต้องการ เก็บ prompt ภายใน boundary ของตัวเอง และปรับ serving stack ให้เหมาะกับ latency หรือ batch งานได้ แลกกับภาระ GPU, patching, monitoring, abuse control และการประเมิน license

สำหรับคนทำผลิตภัณฑ์ไทย คำว่า “รองรับ 160+ ภาษา” เปิดคำถามที่ควรทดสอบจริง: ภาษาไทยแบบทางการกับภาษาพูดดีแค่ไหน, รักษาชื่อเฉพาะและตัวเลขหรือไม่, อ่านเอกสารสองภาษาได้ไหม, และเมื่อภาพมีข้อความไทยจะเชื่อม vision กับ text ถูกหรือเปล่า จำนวนภาษาไม่เท่ากับคุณภาพเท่ากันทุกภาษา เหมือนร้านข้าวตามสั่งที่มีเมนูยาวมาก เราต้องชิมเมนูที่ทีมสั่งจริง ไม่ใช่นับจำนวนบรรทัดบนป้าย

ฝั่งวิศวกรรม 49B active parameters บอกใบ้ว่า serving อาจเบากว่า dense 1T มาก แต่ “เบากว่า” ไม่ได้แปลว่าใช้เครื่องเล็กได้ทันที น้ำหนัก experts ทั้งระบบ, KV cache, context length, quantization, routing overhead และจำนวน concurrent requests ยังเป็นตัวกำหนดหน่วยความจำกับ throughput

ทำงานยังไง: ห้องครัวใหญ่ แต่เปิดเฉพาะสถานีที่ต้องใช้

Mixture-of-experts เปรียบได้กับศูนย์อาหารที่มีร้านจำนวนมาก เมื่อ order เข้ามา router เลือกร้านผู้เชี่ยวชาญเพียงบางส่วนมาช่วย token นั้น เราจึงมีความจุความรู้รวมสูง แต่ไม่ต้องเปิดเตาทุกร้านพร้อมกันทุกคำ หลักการนี้ทำให้ตัวเลข total parameters กับ active parameters ต่างกันมาก

จุดแลกคือ router ต้องเลือกให้ดี หากข้อมูลบางภาษาไหลไป experts ไม่สมดุล อาจเกิดคุณภาพแกว่งหรือคอขวดตอนเสิร์ฟหลายคำขอ การกระจาย experts ข้าม GPU ยังเพิ่มการสื่อสารระหว่างเครื่อง บนกระดาษ FLOPs อาจดูดี แต่ latency จริงขึ้นกับ topology และ implementation

Multimodal หมายถึงโมเดลรับภาพกับข้อความใน workflow เดียวกันได้ แต่ทีมยังต้องตรวจประเภทภาพ ความละเอียด OCR ภาษาไทย การอ้างอิงตำแหน่ง และ prompt injection ที่ซ่อนในเอกสารหรือ screenshot ห้ามให้ภาพที่ผู้ใช้ upload กลายเป็นคำสั่งเชื่อถือได้ แล้วส่งผลต่อ tool call โดยไม่มี policy ชั้นกลาง

Mistral ยังชูความสามารถ reasoning, coding และ multilingual ผ่าน benchmark ของตนเอง ตัวเลขเหล่านี้ใช้ตั้งสมมติฐานทดลองได้ แต่ก่อนซื้อ capacity ควรสร้าง eval set จากงานจริง มีคำตอบอ้างอิง วัด factuality, refusal, citation, latency และต้นทุนต่อ successful task ไม่เลือกจากค่าเฉลี่ย leaderboard เพียงเส้นเดียว

เงินและผลกระทบ

สำหรับ cloud API ค่าใช้จ่ายจะขึ้นกับราคา token, caching, output length และ retry; สำหรับ self-host ต้นทุนย้ายไปที่ GPU hour, network fabric, storage, orchestration และคน on-call ตัวเลข active 49B ไม่บอกค่าใช้จ่ายทั้งหมด เพราะ runtime อาจต้องถือ experts มากกว่าที่ใช้ต่อ token และ batching ที่ไม่ดีทำให้ GPU ว่างเป็นช่วง

ทีมควรทำ cost sheet สามชั้น: งาน interactive ที่เน้น p95 latency, งาน batch ที่เน้น throughput และงาน confidential ที่ยอมจ่ายเพิ่มเพื่อ data boundary จากนั้นเทียบ cost ต่อผลลัพธ์ที่ผ่าน quality gate ไม่ใช่ cost ต่อหนึ่งล้าน token อย่างเดียว โมเดลที่ถูกกว่าแต่ต้อง retry สองรอบอาจแพงกว่า

ในระดับตลาด Mistral พยายามเสนอทางเลือกยุโรปและ open-weight ท่ามกลางการแข่งขันที่ Axios กับ Le Monde เน้นย้ำ หาก weights กับ license ใช้งานเชิงพาณิชย์ได้ตามที่องค์กรต้องการจริง ผู้ซื้อมี leverage มากขึ้น แต่การมีตัวเลือกเพิ่มไม่ได้ทำให้ migration ฟรี ทั้ง prompt, eval, safety filters และ observability ต้องปรับตาม model behavior

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

สิ่งแรกคือคำว่า open-weight ยังเป็นอนาคตในวันที่ตรวจ ประกาศบริษัทบอกว่าจะปล่อย weights ปลายเดือน แต่ยังไม่มี artifact ให้ตรวจ checksum, tensor format, model card, license และ serving requirements แบบลงมือได้ ดังนั้นเรายังยืนยัน supply-chain path ของไฟล์น้ำหนักไม่ได้

สิ่งที่สองคือ benchmark ผู้ผลิตบอกว่าแข่งขันได้กับโมเดลชั้นนำ ขณะที่สำนักข่าวรายงานในกรอบ “ลดช่องว่าง” หรือการแข่งขันกับ open-weight จีน ถ้อยคำสองแบบไม่ได้ขัดกันตรง ๆ แต่มีระดับความมั่นใจต่างกัน: ผู้ผลิตเสนอผลทดสอบที่เลือกและควบคุมเอง ส่วนข่าวอิสระยังมองว่าเป็นผู้ท้าชิง ไม่ใช่ผู้ชนะที่พิสูจน์แล้ว

สิ่งที่สามคือไม่มีราคาไทย, SLA production, quota, data-retention detail ต่อ deployment mode และ hardware recipe สำหรับ self-host ครบถ้วนในประกาศเดียว Public preview อาจเปลี่ยน behavior หรือราคาได้ และเราไม่ควรแปลงตัวเลข GPU ตอน train เป็นคำตอบเรื่องจำนวน GPU ตอน inference

สิ่งที่สี่คือ multilingual coverage ไม่ได้บอกคะแนนภาษาไทยแยกรูปแบบ ทีมไทยต้องสร้างชุดทดสอบของตนเอง โดยเฉพาะข้อความไม่มีเว้นวรรค, วันเดือนปี พ.ศ., ชื่อหน่วยงาน, การถอดเสียง และเอกสารที่มีตารางหรือภาพสแกน

แล้วเราควรทำอะไร

ทีมทดลองควรเริ่มจาก sandbox ไม่มี production secret เลือกงาน 30–50 เคสที่แทน traffic จริง แยกไทย/อังกฤษ/text/vision และบันทึก prompt, model version, parameter, latency, token, error กับ rubric ทุกครั้ง ห้ามให้ preview agent เขียน database, push code หรือส่งข้อความออกนอกระบบโดยตรง

ทีม platform ควรรอ weights, license และ checksum ก่อนออกแบบ self-host จริง เมื่อ artifacts มาให้ pin digest, mirror ใน registry องค์กร, สแกนไฟล์และ container, จำกัด network egress และทดลองบนข้อมูลสังเคราะห์ก่อน ต่อให้ weights เปิดก็ไม่ได้แปลว่า image หรือ dependency ใน serving stack ปลอดภัยอัตโนมัติ

ทีมจัดซื้อควรถามราคา, SLA, retention, training-on-customer-data, region, incident response และวิธี pin model version ส่วนทีม security ควร threat-model prompt injection จากภาพ, data exfiltration ผ่าน tool, model extraction และ log ที่เก็บข้อมูลลูกค้า

หากผล eval ดี ให้ rollout แบบ canary เปรียบเทียบกับ baseline โดยมี kill switch และ fallback อย่าย้าย prompt ทั้งระบบในวันเดียว เพราะ preview สามารถเปลี่ยนได้และข้อผิดพลาดภาษาไทยมักไม่โผล่ใน benchmark ภาษาอังกฤษ

Recap

• แยก 1T total parameters ออกจาก 49B active ต่อ token
• มอง public preview เป็นพื้นที่ทดลอง ไม่ใช่ production guarantee
• รอ weights, license, checksum และ serving recipe ก่อนตัดสิน self-host
• ทดสอบภาษาไทยและ vision ด้วยข้อมูลจริงที่ลดความลับแล้ว
• วัด cost ต่อ successful task รวม retry และคนดูแล
• จำกัด tool, network และ secret พร้อม kill switch
• เปรียบเทียบคำอ้างผู้ผลิตกับผล eval ภายในและแหล่งอิสระ

Mistral Large 4 เป็นสัญญาณว่าตลาด open-weight ระดับใหญ่ยังเดินเร็วครับ แต่สิ่งที่ทีมควรรีบทำไม่ใช่จอง GPU—คือเตรียม eval และ boundary ให้พร้อม เพื่อวันที่ weights มาจริงเราจะตอบได้ด้วยข้อมูลของเราเอง