GitHub เปิด Project HydraFusion — เราเตอร์หลายโมเดลใน Copilot CLI ที่ลดต้นทุน 36-67% แต่ตารางของ GitHub เองบอกว่าคุณภาพชนะ Opus 5 แค่เบนช์มาร์กเดียวจากสาม และวัดทุกโมเดลที่ระดับ medium

วันที่ 4 ก.ย. เวลา 16:04 UTC GitHub เปิดตัว Project HydraFusion เป็น research preview ใน GitHub Copilot CLI แนวคิดคือเลิกถามว่า “งานนี้ควรใช้โมเดลไหน” แล้วเปลี่ยนเป็น “งานนี้ควรใช้ แผนการทำงาน แบบไหน” — ระบบสร้างแผนการรันเต็มรูปแบบให้แต่ละคำขอ เลือกโมเดลข้ามผู้ให้บริการหลายรายมาร่าง วิจารณ์ แก้ไข หรือส่งต่อขึ้นไปยังโมเดลที่แรงกว่า โดยผู้ใช้เลือก HydraFusion เป็น “โมเดล” ตัวหนึ่งเหมือนเลือกตัวอื่น

พาดหัวที่ GitHub เลือกใช้คือ “frontier quality via multi-model orchestration” และตัวเลขที่ยกขึ้นมาในย่อหน้าแรกคือ TerminalBench 2.1 ที่ คุณภาพสูงขึ้น 4.9 จุดที่ต้นทุนต่ำลง 67% เทียบกับ Claude Opus 5 แต่ตารางเต็มที่อยู่ห่างลงไปไม่กี่ย่อหน้าในบทความเดียวกันเล่าเรื่องที่ต่างออกไป

ตารางเดียวกัน อ่านทั้งสามแถว

เบนช์มาร์ก	ต้นทุน เทียบ Opus 5	คุณภาพ เทียบ Opus 5
TerminalBench 2.1	ต่ำลง 67%	+4.9 จุด
DeepSWE	ต่ำลง 36%	-1.5 จุด
CheckpointBench	ต่ำลง 65%	-0.1 จุด

ต้นทุนลดลงทั้งสามแถว ส่วนคุณภาพ ชนะแถวเดียว อีกสองแถวแพ้ ในหน้าเดียวกันนั้น GitHub เขียนถึง DeepSWE ว่า “เข้าใกล้ Opus 5 ในระยะ 1.5 จุดขณะลดต้นทุน 36%” ซึ่งเป็นการอ่านที่ซื่อสัตย์ — แต่พาดหัวที่ว่า “matched or exceeded” ทำงานได้ก็ต่อเมื่อคุณนับ -1.5 จุดว่า “เสมอ”

สำหรับคนที่จะเอาไปใช้จริง คำถามไม่ใช่ว่าตัวเลขสวยหรือไม่ แต่คือ การแลก 1.5 จุดกับเงิน 36% คุ้มไหมสำหรับงานของคุณ ซึ่งคำตอบต่างกันมากระหว่างสคริปต์ CI ที่รันวันละพันครั้งกับการรีแฟกเตอร์โมดูลหลักที่ทำเดือนละครั้ง ตารางนี้ตอบคำถามนั้นได้จริง ส่วนพาดหัวตอบไม่ได้

เงื่อนไขใต้ตารางที่เปลี่ยนความหมายของตัวเลข

บรรทัดที่สำคัญที่สุดในบทความทั้งชิ้นคือคำอธิบายใต้ตาราง: ผลทั้งหมด “จำเพาะกับเวอร์ชันเบนช์มาร์ก การตั้งค่าเวิร์กโฟลว์ กลุ่มโมเดล และสมมติฐานด้านราคาที่ใช้ประเมิน โดยโมเดลทุกตัวถูกวัดที่ระดับ reasoning เดียวกันคือ medium”

นั่นแปลว่าเส้นฐาน Opus 5 ในตารางนี้ไม่ใช่ Opus 5 ที่ตั้งค่าให้เก่งที่สุด แต่คือ Opus 5 ที่ถูกล็อกไว้ที่ระดับกลาง ถ้าคุณกำลังเทียบว่าจะจ่ายให้ HydraFusion หรือจ่ายให้ Opus 5 ตรง ๆ ตัวเลือกที่คุณมีในโปรดักชันคือ Opus 5 ที่คุณหมุน reasoning ขึ้นได้ ซึ่งไม่ใช่ตัวที่อยู่ในตารางนี้ — และเมื่อรวมกับข้อค้นพบของ ARC Prize เรื่องช่องว่างระหว่างฮาร์เนสที่เราเขียนไปเมื่อ 4 ก.ย. ภาพรวมของปี 2026 ชัดขึ้นเรื่อย ๆ ว่า ตัวเลขเบนช์มาร์กของโมเดลกลายเป็นตัวเลขของการตั้งค่ามากกว่าของตัวโมเดล

ข้อที่สองที่ GitHub เขียนเองอย่างเปิดเผยคือวิธีจูน: ทีมใช้ beam search ค้นหานโยบายการตัดสินใจที่ดีที่สุด “โดยปรับข้าม CheckpointBench, DeepSWE และ TerminalBench 2.1 แทนที่จะปรับให้เบนช์มาร์กใดเบนช์มาร์กหนึ่ง” การกระจายเป้าหมายข้ามสามชุดดีกว่าจูนชุดเดียวจริง แต่ก็ยังหมายความว่า ชุดที่ใช้จูนกับชุดที่ใช้รายงานผลคือชุดเดียวกัน และตัวเลขที่รายงานคือ “การตั้งค่า HydraFusion ที่จูนมาดีที่สุด” ตามคำของ GitHub เอง

GitHub ยังเขียนอีกสองอย่างที่คู่แข่งคงไม่เขียนให้: ระหว่าง 11-25 ส.ค. มีความล้มเหลวเชิงปฏิบัติการของฮาร์เนสประเมินผลสองครั้ง ทำให้เกิดรันที่ใช้ไม่ได้ ซึ่งถูกตัดออกจากกราฟแนวโน้ม; และ TerminalBench 2.1 — เบนช์มาร์กที่ให้ตัวเลขพาดหัว — “ค่อนข้างอิ่มตัว จึงทำให้การตรวจสอบในวงกว้างมีความสำคัญ” ส่วน CheckpointBench เป็นเบนช์มาร์กภายในที่สร้างจากเซสชัน Copilot จริง ผูกกับ repo สาธารณะและ commit ที่ตรึงไว้เพื่อให้เล่นซ้ำได้ — แต่คนนอก GitHub เล่นซ้ำไม่ได้

สามรูปแบบ กับสิ่งที่ยังไม่บอก

HydraFusion เลือกหนึ่งในสามรูปแบบต่อคำขอ:

• Single — โมเดลเดียวแก้งานตรง ๆ เก็บความเร็วไว้เมื่อไม่ต้องการอะไรมากกว่านั้น
• Cascade — โมเดลที่ประหยัดกว่าร่างก่อน แล้ว quality gate ตัดสินว่ารับหรือส่งต่อขึ้นไปยังโมเดลที่แรงกว่า
• Critique — โมเดลหนึ่งร่าง แล้ว critic แบบ read-only จากตระกูลโมเดลอื่น ตรวจ (ใช้รูปแบบเดียวกับ Rubber Duck) จากนั้นตัวร่างแก้หนึ่งรอบ

หลักปฏิบัติห้าข้อที่ GitHub วางไว้อ่านเหมือนสเปกของทีมที่เคยโดนของจริงมาแล้ว: complete accounting (รวมต้นทุนทุกขาไม่เว้น retry และ fallback), bounded execution (ทุกขามี timeout และ cancel ชัดเจน), isolated review (ขั้นตอนตรวจรันในคอนเท็กซ์ที่ไม่มีเครื่องมือและแตะ repo ไม่ได้ ส่วนขั้นตอนแก้ใช้ workspace ร่วมตามปกติ), fail-safe application (ถ้าเวิร์กโฟลว์ถูกยกเลิกหรือ validate ไม่ผ่าน ไม่ apply patch เลย) และ validated routing (ตรวจ model binding กับ fallback ก่อนเริ่มรัน)

สิ่งที่ยังไม่บอกมีสามข้อ และทั้งสามข้อกระทบการตัดสินใจ:

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

สอง — คิดเงินเป็นผลรวมของทุกขา ราคาคือ “โทเคนที่โมเดลซึ่ง HydraFusion ใช้บริโภค ในอัตรามาตรฐานของแต่ละโมเดล” ไม่มีค่าธรรมเนียม HydraFusion แยก แต่ก็ไม่มีเพดาน — ถ้างานหนึ่งวิ่งครบ Cascade แล้วต่อด้วย retry ค่าใช้จ่ายคือผลรวมของทุกขา ตัวเลข “ลด 67%” เป็นค่าเฉลี่ยบนเบนช์มาร์ก ไม่ใช่การรับประกันต่องาน

สาม — ยังมองไม่เห็นข้างใน ระบบแสดงสถานะของเวิร์กโฟลว์แต่ซ่อนร่างระหว่างทางไว้จนกว่าจะได้ผลลัพธ์เดียวที่สมบูรณ์ เหตุผลที่ GitHub ให้คือร่างเหล่านั้นอาจถูกแก้หรือทิ้ง การโชว์สดจึงทำให้งานที่ยังไม่เสร็จดูเหมือนเสร็จแล้ว — และ GitHub ยอมรับเองว่า “การรอโดยไม่เห็นอะไรเลยคือ trade-off จริงสำหรับนักพัฒนา” ในกระทู้ community นักพัฒนายังรายงานตรงกันว่ามองไม่ออกว่าโมเดลไหนลงมือขั้นไหน ขอ breakdown ต้นทุนต่อโมเดล และเจอว่าโหมด Plan ยังใช้ร่วมกันไม่ได้

วิธีลอง: รัน /update เพื่ออัปเดต Copilot CLI, /experimental on, แล้ว /model เลือก HydraFusion (Research Preview) ใช้ได้กับทุกแพ็กเกจ Copilot GitHub แนะนำให้เริ่มจากงานโค้ดแบบ พรอมต์เดียวจบในเทิร์นแรก เพราะประสิทธิภาพแบบหลายเทิร์นเป็นสิ่งที่ทีมจะทำต่อ ไม่ใช่สิ่งที่พร้อมแล้ว

มุมมอง AI Curator

HydraFusion คือการยอมรับที่กลายเป็นสินค้า — ยอมรับว่า “โมเดลที่ดีที่สุด” ไม่ใช่คำตอบที่มีความหมายอีกต่อไป และสิ่งที่ตัดสินผลลัพธ์คือลำดับการเรียกโมเดล ไม่ใช่ตัวโมเดล เราเห็นแนวคิดเดียวกันนี้มาทั้งปีจากคนละทิศ: Cursor Auto, NeMo Switchyard ของ NVIDIA, ปลั๊กอิน shunt ของ Spotify และงานวัดของ Armature ที่พบว่าเอเจนต์สามตัวเลือกบริการต่างกันในโจทย์เดียวกัน สิ่งที่ทำให้ HydraFusion ต่างคือมันมาจากเจ้าของแพลตฟอร์มที่โฮสต์โค้ดของคนทั้งโลกและวางมันเป็น “โมเดล” ตัวหนึ่งในเมนู — ชั้นการเลือกโมเดลกำลังกลายเป็นชั้นที่มีเจ้าของ

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

สำหรับทีมไทยและ SEA นี่คือหนึ่งในไม่กี่ข่าวปีนี้ที่ผลลัพธ์เป็นบวกทันทีโดยไม่ต้องมีทุนหนา ต้นทุนต่อ pass คือข้อจำกัดจริงของทีมเล็ก และการลด 36-65% ที่แลกกับคุณภาพ 0.1-1.5 จุดคือดีลที่คุ้มสำหรับงานส่วนใหญ่ในชีวิตประจำวัน แต่ควรใช้แบบตาสว่างสองข้อ: อย่าเอา research preview ที่ยังไม่รองรับหลายเทิร์นไปวางในไปป์ไลน์ที่ต้องพึ่งพา และก่อนเชื่อว่า “ลด 67%” ให้วัดต้นทุนต่องานของทีมเองสองสัปดาห์แล้วเทียบ เพราะเวิร์กโหลดของคุณไม่ใช่ TerminalBench และตัวเลขที่ GitHub เขียนไว้ก็บอกเองว่าเบนช์มาร์กนั้นอิ่มตัวแล้ว

แหล่งข่าว

• Project HydraFusion: Frontier quality via multi-model orchestration — The GitHub Blog
• กระทู้ research preview ใน GitHub Community (ข้อจำกัดและฟีดแบ็กนักพัฒนา)
• GitHub’s HydraFusion cuts AI coding costs in every benchmark. It only matches quality in one — VentureBeat