Sakana Fugu Benchmarks: เทียบชั้น Fable 5 หมายถึงอะไรกันแน่

เกณฑ์มาตรฐาน Fugu ของ Sakana ควรอ่านเป็น “คำกล่าวอ้างจากผู้จำหน่าย” ไม่ใช่ผลประเมินอิสระ ตามหน้าเผยแพร่ของ Sakana, Fugu Ultra “มีความสามารถทัดเทียมกับโมเดลชั้นนำอย่าง Fable 5 และ Mythos Preview” ในงานวิศวกรรม วิทยาศาสตร์ และการให้เหตุผล และ Fugu “ทำงานได้ดีกว่าอย่างสม่ำเสมอ” เมื่อเทียบกับ Gemini 3.1 Pro, Opus 4.8 และ GPT 5.5 ในชุดแอปพลิเคชันที่ระบุ ประเด็นสำคัญสำหรับนักพัฒนาคือ Fugu ไม่ใช่โมเดลเดี่ยวแบบเดียวกับ Fable 5 แต่เป็นตัวควบคุมที่เรียกใช้โมเดลระดับแนวหน้าของผู้จำหน่ายรายอื่น ดังนั้นตัวเลขของมันจึงควรถูกประเมินเหมือนระบบ orchestration ไม่ใช่ชัยชนะของโมเดลเดี่ยว

ลองใช้ Apidog วันนี้

Fugu คืออะไร และทำไมต้องอ่าน benchmark แบบต่างออกไป

Fugu ไม่ใช่ foundation model เดี่ยว แต่เป็นระบบประสานงานแบบหลายเอเจนต์ที่ถูกนำเสนอเป็นโมเดลเดียวผ่าน API ที่เข้ากันได้กับ OpenAI Sakana อธิบายว่า Fugu ถูกฝึกมาเพื่อ:

• มอบหมายงานให้เอเจนต์หรือโมเดลอื่น
• จัดการการสื่อสารระหว่างเอเจนต์
• สังเคราะห์ผลลัพธ์จากหลายโมเดล
• ตัดสินใจว่าจะตอบเองหรือสร้างทีมย่อยเพื่อแก้ปัญหา

ผลกระทบต่อการอ่าน benchmark คือ:

• ถ้าโมเดลเดี่ยวรายงานคะแนน คะแนนนั้นสะท้อนน้ำหนักและความสามารถของโมเดลนั้น
• ถ้า Fugu รายงานคะแนน คะแนนนั้นอาจสะท้อนการเรียกใช้ Opus 4.8, GPT 5.5, Gemini 3.1 Pro หรือโมเดลอื่น แล้วสังเคราะห์คำตอบร่วมกัน

ดังนั้นถ้าเห็นข้อความว่า “Fugu เหนือกว่า Opus 4.8” ให้แปลเชิงเทคนิคว่า “ระบบ orchestration ของ Fugu สร้างผลลัพธ์ดีกว่าในการทดสอบนั้น” ไม่ใช่ “โมเดล Sakana เดี่ยวมี reasoning ดีกว่า Opus”

ถ้าต้องการพื้นหลังด้านสถาปัตยกรรมเพิ่มเติม ดูคำอธิบาย Sakana Fugu

คำกล่าวอ้างแรก: “ทัดเทียมกับ Fable 5 และ Mythos Preview”

Sakana ระบุว่า Fugu Ultra “มีความสามารถทัดเทียมกับโมเดลชั้นนำอย่าง Fable 5 และ Mythos Preview” ใน benchmark ด้านวิศวกรรม วิทยาศาสตร์ และการให้เหตุผล

จุดที่ควรอ่านให้ชัด:

1. นี่คือคำกล่าวอ้างเรื่อง “ความทัดเทียม” ไม่ใช่ “เหนือกว่า”
2. คู่แข่งที่ระบุคือ “Mythos Preview” ไม่ใช่ Mythos 5 เวอร์ชันปัจจุบัน
3. ยังไม่มีตารางคะแนนต่อภารกิจหรือวิธีทดสอบที่บุคคลภายนอกสามารถรันซ้ำได้

ถ้าคุณติดตามโมเดลตระกูล Mythos จะเห็นว่า Preview และเวอร์ชันที่เปิดตัวทั่วไปเป็นคนละบริบทกัน การอ้างความเท่าเทียมกับ Preview จึงไม่ควรถูกตีความว่าเทียบเท่ากับ Mythos รุ่นปัจจุบันโดยอัตโนมัติ

สำหรับนักพัฒนา วิธีใช้งานข้อมูลนี้คืออย่านำคำว่า “ทัดเทียม” ไปใส่ใน decision matrix โดยไม่มีการทดสอบ workload ของคุณเอง

คำกล่าวอ้างที่สอง: “ทำงานได้ดีกว่าอย่างสม่ำเสมอ” ในแอปพลิเคชันเฉพาะ

Sakana ยังอ้างว่า Fugu “ทำงานได้ดีกว่าอย่างสม่ำเสมอ” เมื่อเทียบกับคู่แข่งที่ตั้งค่าไว้ดังนี้:

• Gemini 3.1 Pro ระดับสูง
• Opus 4.8 ระดับสูงสุด
• GPT 5.5 ระดับสูงมาก

แอปพลิเคชันที่ใช้ทดสอบคือ:

• AutoResearch
• Rubik’s Cube
• Mechanical Design
• Japanese Handwriting Analysis
• One-Shot Chess
• Financial Time Series Prediction

นี่เป็นการวัดระดับ application workflow ไม่ใช่ benchmark วิชาการมาตรฐาน จุดนี้สำคัญมาก เพราะระบบ orchestration ได้เปรียบในงาน end-to-end ที่สามารถแตกปัญหาเป็นงานย่อย แล้วส่งต่อให้โมเดลที่เหมาะที่สุดในแต่ละขั้น

ตัวอย่างการตีความที่ถูกต้อง:

ผิด: Fugu เป็นโมเดลเดี่ยวที่เก่งกว่า Opus 4.8
ถูก: Fugu เป็นระบบ orchestration ที่อาจใช้ Opus 4.8 ร่วมกับโมเดลอื่นเพื่อสร้างผลลัพธ์ที่ดีกว่าในงานบางประเภท

ดังนั้นอย่าพูดว่า “Fugu เอาชนะ Fable 5” เพราะ Sakana ไม่ได้อ้างแบบนั้น และคำกล่าวอ้างเรื่อง “ทัดเทียม” กับ “ทำงานดีกว่า” ใช้กับคู่แข่งคนละชุด

ทำไมตัวเลขเหล่านี้ยังตรวจสอบอิสระไม่ได้

ยังไม่มีการทำซ้ำโดยอิสระ

ณ วันที่ 2026-06-22 ตัวเลข benchmark ของ Fugu เป็นข้อมูลที่ Sakana รายงานเอง โดยวัดบนระบบของ Sakana ด้วยการตั้งค่าคู่แข่งที่ Sakana เลือก ยังไม่มีบุคคลที่สามรันงานเหล่านี้ซ้ำ ไม่มีตารางคะแนนต่อภารกิจที่เผยแพร่ และไม่มี evaluation harness ที่เปิดให้ใช้สาธารณะ

นี่ไม่ใช่ปัญหาเฉพาะของ Sakana แต่เป็นสถานะปกติของโมเดลใหม่ในวันเปิดตัว ความแตกต่างคือ Fugu ทำให้การ reproduce ยากกว่าโมเดลเดี่ยว เพราะคุณต้องควบคุมหลายอย่างพร้อมกัน:

• เวอร์ชันของ Fugu
• โมเดลพื้นฐานทุกตัวที่ Fugu เรียกใช้
• effort setting ของแต่ละโมเดล
• routing logic ภายใน
• agent structure ต่อ task
• prompt และ test set เดิม

เมื่อ Fugu สามารถปรับโครงสร้างเอเจนต์แบบไดนามิก การรัน prompt เดียวกันสองครั้งอาจไม่ได้ใช้ทีมภายในชุดเดียวกัน นี่ดีต่อผู้ใช้จริง แต่อาจทำให้ benchmark ซ้ำยาก

ดังนั้นหากเห็นตัวเลข “Fugu ได้คะแนน X” จากแหล่งรอง ให้ตรวจสอบว่าแหล่งนั้นระบุ:

• ใช้ Fugu หรือ Fugu Ultra
• เปรียบเทียบกับ Mythos Preview หรือ Mythos รุ่นปัจจุบัน
• มี methodology หรือไม่
• มี prompt/task list หรือไม่
• มีการรันซ้ำโดยบุคคลภายนอกหรือไม่

การเปรียบเทียบ Fugu Ultra กับ Fable 5 กับ Mythos จึงควรถูกอ่านเชิงคุณภาพมากกว่าตารางตัดสินอันดับสุดท้าย

งานวิจัยที่อยู่เบื้องหลัง Fugu

การตลาดของ Sakana อ้างอิงจากงานวิจัยจริง แต่เอกสารเหล่านี้ไม่ควรถูกอ่านเป็น product spec ของ Fugu โดยตรง

เอกสารแรกคือ Trinity, “An Evolved LLM Coordinator” (arXiv:2512.04695)

Trinity เป็นตัวประสานงานที่มีพารามิเตอร์น้อยกว่า 20,000 ตัว ได้รับการปรับปรุงด้วย derivative-free evolution และมีบทบาทหลัก เช่น Thinker, Worker และ Verifier

เอกสารที่สองคือ Conductor, “Learning to Orchestrate Agents in Natural Language” (arXiv:2512.04388)

Conductor เป็นโมเดล 7B ที่ฝึกด้วย Reinforcement Learning เพื่อเรียนรู้โครงสร้างการสื่อสารระหว่างเอเจนต์ เอกสารระบุว่าสามารถเอาชนะ Mixture-of-Agents ได้ด้วยต้นทุนต่ำกว่า

สิ่งที่ต้องระวัง:

• Trinity และ Conductor เป็นวิธีคนละแบบ
• Trinity มีขนาดน้อยกว่า 20K parameters
• Conductor มีขนาด 7B
• ไม่มีเอกสารใดระบุว่าเป็นข้อมูลจำเพาะของผลิตภัณฑ์ Fugu ที่เปิดตัว
• จำนวนพารามิเตอร์ของ Fugu เวอร์ชันผลิตภัณฑ์ยังไม่ได้ถูกเผยแพร่อย่างเป็นทางการ

ข้อมูลจำเพาะที่ควรใช้เป็น checklist

รายการ	สิ่งที่ Sakana / แหล่งข้อมูลกล่าว	ความน่าเชื่อถือ
ประเภทระบบ	ตัวประสานงานแบบหลายเอเจนต์ที่อยู่เบื้องหลังโมเดลเดียว	ระบุในหน้าเผยแพร่
รุ่นย่อย	Fugu สำหรับสมดุล/เวลาแฝงต่ำ และ Fugu Ultra สำหรับคุณภาพสูงสุด	ระบุในหน้าเผยแพร่
ชื่อเบต้าเก่า	รุ่นย่อยขนาดเล็กเคยถูกเรียกว่า “Fugu Mini”	ข้อมูลในอดีต
API	endpoint เดียวที่เข้ากันได้กับ OpenAI	ระบุในหน้าเผยแพร่
โมเดลพื้นฐาน	เรียกใช้ LLM ระดับแนวหน้าหลายตัว รวมถึงเรียกตัวเองซ้ำ	ระบุในหน้าเผยแพร่
จำนวนพารามิเตอร์ของผลิตภัณฑ์	ยังไม่เผยแพร่	ต้องตรวจสอบ
methodology ของ benchmark	รายงานโดยผู้จำหน่าย ไม่มี evaluation tool สาธารณะ	ต้องตรวจสอบ

ชื่อที่ควรใช้ตอนนี้คือ “Fugu” และ “Fugu Ultra” แม้ในช่วงเบต้าเคยมีชื่อ “Fugu Mini” ก็ตาม

วิธีทดสอบ Fugu ด้วยตัวเอง

คุณไม่สามารถตรวจสอบ benchmark ของ Sakana ได้โดยตรง แต่คุณสามารถทดสอบ workload ของคุณเองได้

เพราะ Fugu ใช้รูปแบบ Chat Completions ที่เข้ากันได้กับ OpenAI คุณสามารถชี้ OpenAI client ที่มีอยู่ไปยัง base URL ของ Fugu ได้ โดยไม่จำเป็นต้องเปลี่ยน SDK

ณ วันที่ 2026-06-22 base URL ยังไม่ได้เผยแพร่ในหน้าสาธารณะ ให้คัดลอกจากคอนโซลของคุณที่ console.sakana.ai และอย่าใช้ hostname ที่เดาเอง

ตัวอย่าง Python:

from openai import OpenAI

# คัดลอก base URL จริงจาก console.sakana.ai หลังจากเข้าสู่ระบบ
client = OpenAI(
    api_key="YOUR_FUGU_API_KEY",
    base_url="<YOUR_FUGU_BASE_URL_FROM_CONSOLE>",
)

resp = client.chat.completions.create(
    model="fugu-ultra",  # ใช้ "fugu" สำหรับรุ่นสมดุล ตรวจสอบ id จริงในคอนโซล
    messages=[
        {
            "role": "system",
            "content": "คุณคือผู้ตรวจสอบโค้ดที่แม่นยำ"
        },
        {
            "role": "user",
            "content": "ตรวจสอบฟังก์ชันนี้เพื่อหาปัญหาด้านความปลอดภัย:\n<วางโค้ด>"
        },
    ],
)

print(resp.choices[0].message.content)

สิ่งที่ควร log ทุกครั้ง:

model_id
prompt_version
input_tokens
output_tokens
latency_ms
cost_estimate
status_code
response_quality_score
notes

เพราะ Fugu ตัดสินใจต่อ request ว่าจะตอบเองหรือสร้างทีมเอเจนต์ เวลาแฝงและค่าใช้จ่ายอาจต่างกันแม้ใช้ prompt เดิม

ตัวอย่างโครงสร้างไฟล์ evaluation แบบง่าย:

evals/
  prompts/
    code-review-security.md
    api-design-review.md
    test-case-generation.md
  results/
    fugu-ultra.csv
    opus-4-8.csv
    fable-5.csv

ตัวอย่าง CSV:

run_id,model,prompt,latency_ms,input_tokens,output_tokens,score,notes
1,fugu-ultra,code-review-security,8420,1200,980,4.2,"พบ issue สำคัญครบ แต่ตอบยาว"
2,opus-4.8,code-review-security,6100,1200,760,4.0,"สั้นกว่า แต่พลาด edge case"

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

วิธีใช้ Apidog เพื่อเปรียบเทียบ endpoint

คุณไม่จำเป็นต้องสร้างเครื่องมือ benchmark ใหม่ทั้งหมด สิ่งที่ต้องมีคือวิธีส่ง prompt เดียวกันไปยังหลาย endpoint แล้วเทียบผลลัพธ์แบบสม่ำเสมอ

ใช้ Apidog เพื่อสร้าง workflow ประเมินผลได้แบบนี้:

1. ลงทะเบียน endpoint ของ Fugu เป็น API ที่เข้ากันได้กับ OpenAI
2. สร้าง request สำหรับ prompt จริงของคุณ เช่น code review, API design review หรือ test generation
3. สร้าง environment แยกสำหรับ Fugu, Fable 5, Opus หรือโมเดลอื่น
4. ส่ง input เดียวกันไปยังทุก endpoint
5. บันทึก response, status code, latency และ token usage
6. รันซ้ำเมื่อมีโมเดลเวอร์ชันใหม่

ตัวอย่าง body สำหรับ Chat Completions:

{
  "model": "fugu-ultra",
  "messages": [
    {
      "role": "system",
      "content": "คุณคือผู้ช่วยด้าน API design review"
    },
    {
      "role": "user",
      "content": "ตรวจสอบ OpenAPI spec ต่อไปนี้และเสนอการปรับปรุง:\n<วางสเปก>"
    }
  ]
}

การเปรียบเทียบแบบนี้มีประโยชน์กว่าการอ้าง “ทัดเทียม” โดยไม่มี methodology เพราะคุณวัดจากงานจริงของคุณเอง และเห็นผลลัพธ์ด้าน latency/cost ที่เกิดจาก adaptive routing ของ Fugu ในแต่ละครั้ง

คำถามที่พบบ่อย

Fugu เอาชนะ Fable 5 ใน benchmark หรือไม่?

ไม่ Sakana ไม่ได้อ้างว่า Fugu เอาชนะ Fable 5 คำกล่าวอ้างคือ Fugu Ultra “มีความสามารถทัดเทียมกับ” Fable 5 และ Mythos Preview ส่วนคำกล่าวอ้างว่า “ทำงานได้ดีกว่า” ใช้กับ Gemini 3.1 Pro, Opus 4.8 และ GPT 5.5 ในแอปพลิเคชันเฉพาะ ไม่ใช่ Fable 5 ดูเพิ่มเติมได้ที่เกณฑ์มาตรฐาน Claude Fable 5

ตัวเลข benchmark ของ Fugu ตรวจสอบโดยอิสระแล้วหรือยัง?

ยังไม่ ณ วันที่ 2026-06-22 ตัวเลขทั้งหมดเป็นการรายงานจาก Sakana เอง ยังไม่มีบุคคลที่สามรันซ้ำ และยังไม่มี evaluation harness สาธารณะ ให้ถือว่าเป็นคำกล่าวอ้างจนกว่าจะมีการทำซ้ำจากภายนอก

ทำไมการที่ Fugu เป็นตัวประสานงานจึงสำคัญ?

เพราะ Fugu อาจเรียกใช้โมเดลระดับแนวหน้าของผู้จำหน่ายรายอื่น รวมถึงเรียกตัวเองซ้ำ ผลลัพธ์ที่ดูเหมือน “เหนือกว่า Opus 4.8” อาจมาจากระบบที่ใช้ Opus ร่วมกับโมเดลอื่นแล้วสังเคราะห์คำตอบ นี่คือชัยชนะของระบบหลายโมเดล ไม่ใช่ชัยชนะของโมเดลเดี่ยว เมื่อเทียบกับ Fable 5 และตระกูล Mythos จึงไม่ใช่การเปรียบเทียบแบบเดียวกันโดยตรง

Sakana เปรียบเทียบกับ Mythos เวอร์ชันใด?

Sakana ระบุ Mythos Preview เวอร์ชันเก่าจากเดือนเมษายน ไม่ใช่ Mythos 5 เวอร์ชันปัจจุบัน บทความรองบางแห่งอาจระบุเวอร์ชันผิด ดูรายละเอียดเพิ่มเติมในคำอธิบายโมเดลตระกูล Mythos

Trinity และ Conductor ต่างกันอย่างไร?

Trinity (arXiv:2512.04695) เป็นตัวประสานงานที่มีพารามิเตอร์น้อยกว่า 20,000 ตัว และปรับปรุงด้วย evolution ส่วน Conductor (arXiv:2512.04388) เป็นโมเดล 7B ที่ฝึกด้วย Reinforcement Learning ทั้งสองเป็นงานวิจัยคนละแนว และไม่ควรถูกใช้เป็น product spec ของ Fugu โดยตรง

ฉันควรทดสอบ Fugu อย่างไรในโปรเจกต์จริง?

ใช้ OpenAI-compatible client ชี้ไปยัง base URL จาก console.sakana.ai แล้วส่ง workload จริงของคุณ เช่น code review, agentic research, API design หรือ test generation วัดคุณภาพ เวลาแฝง ค่าใช้จ่าย และ token usage จากนั้นลงทะเบียน endpoint ใน Apidog เพื่อเปรียบเทียบ Fugu กับโมเดลเดี่ยวที่คุณใช้อยู่ ด้วย prompt และ metric ชุดเดียวกัน