Fireworks เปิดตัว Nexus — เลเยอร์ routing ที่โยนงานโค้ดง่าย ๆ ไปโมเดลโอเพนเวต อ้างลดต้นทุน 3–5 เท่าโดยไม่เปลี่ยนเครื่องมือที่ทีมใช้อยู่

Fireworks AI เปิดตัว Fireworks Nexus เมื่อ 26 กรกฎาคม 2026 — เลเยอร์จัดการและ routing ที่เสียบเข้าไประหว่างเครื่องมือ AI ที่ทีมนักพัฒนาใช้อยู่แล้ว กับชั้นของ โมเดลโอเพนเวตแบบ managed โดยมีเป้าหมายเดียวคือ ลดบิลค่าโมเดลโดยไม่ต้องเปลี่ยนเวิร์กโฟลว์ของทีม

ไอเดียตั้งอยู่บนข้อสังเกตที่ทีมที่ใช้ AI coding agent จริงจังน่าจะพยักหน้าตาม: งานที่ agent ทำในหนึ่งวันไม่ได้ยากเท่ากันทั้งหมด การเปลี่ยนชื่อตัวแปรทั่วทั้งไฟล์ เขียนเทสต์ตามแพตเทิร์นเดิม หรือแก้ lint error ไม่ได้ต้องการโมเดลระดับสูงสุด แต่ในเวิร์กโฟลว์ปัจจุบัน งานพวกนั้นก็ถูกยิงไปที่โมเดลราคาแพงที่สุดพอ ๆ กับงานออกแบบสถาปัตยกรรม

FireRouter ทำงานอย่างไร

หัวใจของ Nexus คือ FireRouter ซึ่งใช้ โมเดลที่เทรนขึ้นมาเฉพาะ ทำหน้าที่ ให้คะแนนความยากของแต่ละคำขอ แล้วตัดสินใจว่าจะส่งไปที่ไหน งานที่เป็นงานประจำถูกส่งไปโมเดลโอเพนเวตที่ต้นทุนต่ำกว่า ส่วนงานที่ยากจริงถูกส่งต่อ (pass-through) ไปยังผู้ให้บริการเดิมที่ทีมใช้อยู่

การจับคู่โมเดลที่ Fireworks ระบุไว้มีสองแบบ:

• แบบผสม: Claude Opus 5 คู่กับ GLM-5.2 — แบบนี้ต้องใช้ คีย์ Anthropic ของคุณเอง สำหรับส่วนที่ส่งต่อ
• แบบโอเพนล้วน: Kimi K3 คู่กับ GLM-5.2 — ไม่ต้องพึ่งผู้ให้บริการโมเดลปิดเลย

ฝั่งการเชื่อมต่อคือ FireConnect ซึ่งเป็น Apache-2.0 และติดตั้งได้ด้วยคำสั่งเดียวจาก Fireworks Dashboard ส่วน ตัว router เองยังอยู่ในสถานะ research preview — ข้อนี้สำคัญ อย่าอ่านข้ามไป

ตัวเลขที่ Fireworks อ้าง (และควรอ่านอย่างไร)

• ลดต้นทุน 3–5 เท่าโดยทั่วไป “โดยไม่ลดทอนคุณภาพ”
• การทดสอบกับ Notion และ Doximity ระบุว่า Nexus “ตัดต้นทุนต่อ PR ที่ merge สำเร็จลงหนึ่งในสาม”
• อัตราค่าโทเคนแบบผสมอยู่ที่ราว หนึ่งในสี่ของแล็บโมเดลปิด
• การประเมินโดย Faros พบว่า Claude Code ที่รันบน GLM-5.2 มีต้นทุน ราวครึ่งหนึ่งต่องานที่ทำเสร็จ

ตัวเลขทั้งหมดนี้มาจากฝั่งผู้ขาย และคำที่ต้องตั้งคำถามมากที่สุดคือ “โดยไม่ลดทอนคุณภาพ” เพราะนั่นคือข้ออ้างที่ยากที่สุดจะพิสูจน์ และเป็นข้ออ้างที่ผลิตภัณฑ์ประเภทนี้ทุกเจ้าพูดเหมือนกันหมด

อย่างไรก็ตาม ผมคิดว่ามีอย่างหนึ่งที่ Fireworks ทำถูก คือการเลือกวัดผลด้วย ต้นทุนต่อ PR ที่ merge สำเร็จ แทนที่จะวัดด้วยราคาต่อล้านโทเคน เพราะเมตริกแรกเป็นเมตริกเชิงผลลัพธ์ที่ลงโทษการ routing ผิดโดยอัตโนมัติ — ถ้า router ส่งงานยากไปโมเดลที่อ่อนเกินไป agent จะวนแก้หลายรอบ จำนวนโทเคนรวมพุ่ง และ PR ก็ merge ไม่ผ่านอยู่ดี ต้นทุนต่อ PR จึงแย่ลงแม้ราคาต่อโทเคนจะถูกลง

มุมมอง AI Curator

นี่เป็นผลิตภัณฑ์ routing ตัวที่สองในรอบไม่ถึงสัปดาห์ ต่อจาก Cursor Router ที่เปิดตัวเมื่อ 22 กรกฎาคม ซึ่งบอกอะไรบางอย่างชัดเจน: routing กำลังกลายเป็นหมวดผลิตภัณฑ์ของตัวเอง ไม่ใช่ฟีเจอร์ประกอบอีกต่อไป

เหตุผลเชิงโครงสร้างก็ตรงไปตรงมา ตอนที่ทุกคนใช้ AI ผ่านหน้าต่างแชท ต้นทุนต่อคนต่อเดือนคาดเดาได้ แต่พอ agent ทำงานยาวเป็นชั่วโมงและเรียกโมเดลเองหลายร้อยรอบ ค่าใช้จ่ายก็ผูกกับ ปริมาณงานที่ agent ตัดสินใจทำ ไม่ใช่จำนวนคนในทีมอีกต่อไป เมื่อบิลกลายเป็นตัวแปรที่ควบคุมไม่ได้ ตลาดก็ตอบสนองด้วยชั้นควบคุม — และนั่นคือสิ่งที่เรากำลังเห็น

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

ข้อควรระวังที่ผมอยากให้ชั่งน้ำหนักมีสามข้อ

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

สอง — สถานะ research preview ตัว router ยังไม่ใช่ของที่ประกาศว่าพร้อมใช้งานจริงเต็มรูปแบบ การเอาสิ่งที่อยู่ระหว่างวิจัยมาวางไว้บนเส้นทางที่ทุกคำขอของทีมต้องวิ่งผ่าน คือการรับความเสี่ยงที่ควรทดลองในโปรเจกต์รองก่อน ไม่ใช่ในไปป์ไลน์หลัก ส่วน FireConnect ที่เป็น Apache-2.0 นั้นน่าสนใจกว่าในเชิงระยะยาว เพราะอย่างน้อยชั้นเชื่อมต่อก็ตรวจสอบได้และไม่ล็อกคุณไว้

สาม — และข้อนี้ไทยควรคิดมากกว่าที่คิด ตัวเลือกแบบโอเพนล้วนของ Nexus คือ Kimi K3 คู่กับ GLM-5.2 ซึ่งเป็นโมเดลจากจีนทั้งคู่ ในเชิงเทคนิคนี่คือทางเลือกที่สมเหตุสมผลที่สุดในตลาดตอนนี้ แต่มันวางตัวสวนทางกับทิศทางนโยบายฝั่งสหรัฐฯ ที่กำลังพิจารณาจำกัดการใช้โมเดลโอเพนจากจีน ตรง ๆ ทีมไทยที่ทำงานให้ลูกค้าอเมริกัน หรืออยู่ในซัพพลายเชนของบริษัทสหรัฐฯ ควรตรวจสอบเงื่อนไขในสัญญาก่อน — ไม่ใช่เพราะโมเดลไม่ดี แต่เพราะข้อกำหนดของลูกค้าอาจเปลี่ยนก่อนที่คุณจะย้ายกลับทัน

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

แหล่งข่าว

• Introducing Fireworks Nexus — Fireworks AI
• Fireworks AI Releases Fireworks Nexus: A Drop-In Routing and Cost-Control Layer — MarkTechPost