วิธีทดสอบ Sakana Fugu API ใน Apidog

ในการทดสอบ Sakana Fugu API ใน Apidog ให้สร้างคำขอ HTTP ใหม่ไปที่พาธ /chat/completions ที่เข้ากันได้กับ OpenAI เพิ่ม header Authorization: Bearer พร้อม API key ของคุณ แล้วส่ง payload ที่ระบุโมเดล fugu หรือ fugu-ultra เนื่องจาก Fugu มี ปลายทางที่เข้ากันได้กับ OpenAI เพียงหนึ่งเดียว เครื่องมือที่ใช้รูปแบบ Chat Completions ของ OpenAI จึงทำงานได้โดยไม่ต้องเปลี่ยน SDK และ Apidog ช่วยให้คุณทดสอบ streaming, บันทึกรูปแบบ request, ตรวจสอบ usage, และเปรียบเทียบ latency ของ Fugu กับ Fugu Ultra ได้ในที่เดียว

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

หากคุณต้องการเส้นทางรวมระบบแบบเน้นโค้ด ให้ดู คู่มือการใช้ Sakana Fugu API ซึ่งครอบคลุมการเชื่อมต่อ SDK ส่วนบทความนี้จะเน้นการทดสอบและสังเกตพฤติกรรม Fugu ภายใน Apidog

สิ่งที่คุณกำลังทดสอบกับ Fugu จริงๆ คืออะไร

Fugu ไม่ใช่โมเดลแชทเดี่ยวแบบทั่วไป ตามที่ Sakana ระบุไว้ Fugu คือระบบประสานงานหลายเอเจนต์ (multi-agent orchestration system) ที่ถูกนำเสนอผ่าน API เดียวในรูปแบบโมเดลพื้นฐานเดียว โมเดลนี้เชี่ยวชาญด้านการมอบหมายงาน การสื่อสารระหว่างเอเจนต์ และการสังเคราะห์ผลลัพธ์ จากนั้นจะประสานงาน LLM หลายตัวแบบไดนามิก รวมถึงอินสแตนซ์ซ้ำของตัวมันเอง หากต้องการเข้าใจภาพรวมเชิงสถาปัตยกรรม อ่านเพิ่มเติมได้ที่ คำอธิบายเกี่ยวกับ Sakana Fugu

การออกแบบนี้มีผลต่อวิธีทดสอบ API โดยตรง เมื่อคุณส่ง request หนึ่งครั้ง Fugu อาจตอบโดยตรง หรืออาจเรียกหลายโมเดลเบื้องหลังแล้วสังเคราะห์คำตอบกลับมา คุณจะเห็น response เดียว แต่ latency และ token usage อาจสะท้อนต้นทุนของ orchestration hop ได้

สิ่งที่ควรตรวจใน Apidog:

• เวลาแฝงของ request เพื่อดูว่า Fugu ตอบเร็วแบบ direct path หรือมี orchestration หลายขั้น
• usage เพื่อดูจำนวน token ของ request หลัก
• SSE delta เมื่อเปิด streaming
• ความแตกต่างของคำตอบระหว่าง fugu และ fugu-ultra

Fugu มีสองเวอร์ชันหลักที่ใช้ endpoint เดียวกัน:

• Fugu: เวอร์ชันสมดุลและ latency ต่ำ เหมาะกับงานทั่วไป เช่น coding, code review, chatbot และ interactive services
• Fugu Ultra: เน้นคุณภาพคำตอบสูงสุด เหมาะกับงานวิจัย AI, การทำซ้ำงานวิจัย, การวิเคราะห์ความปลอดภัยไซเบอร์, และการตรวจสอบวรรณกรรมหรือสิทธิบัตร

หมายเหตุ: เอกสารหรือสื่อช่วงเบต้าบางแห่งอาจเรียกเวอร์ชันเล็กว่า “Fugu Mini” แต่หน้าเปิดตัวใช้ชื่อ “Fugu” และ “Fugu Ultra” ดังนั้นควรใช้ชื่อเหล่านี้ในการตั้งค่า request

รับ Base URL และ API key ก่อนเริ่ม

Fugu ต้องใช้งานผ่านคอนโซลของ Sakana ให้ลงชื่อเข้าใช้ที่ console.sakana.ai ด้วย Google หรืออีเมล แล้วคัดลอกข้อมูลต่อไปนี้:

• API key
• Base URL สำหรับเรียก Fugu

ข้อควรระวัง ณ วันที่ 2026-06-22: Base URL ยังไม่ได้เผยแพร่ในหน้าสาธารณะของ Sakana อย่าคาดเดา host เอง ให้คัดลอกจากคอนโซลเท่านั้น ทุกจุดในบทความนี้ที่ใช้ค่า:

<YOUR_FUGU_BASE_URL_FROM_CONSOLE>

ให้แทนที่ด้วย Base URL จริงจากคอนโซล

สถานะการเข้าถึงอาจเปลี่ยนจากช่วงเบต้าที่มีผู้ใช้จำกัดไปสู่การใช้งานทั่วไปแล้ว แต่เงื่อนไขการสมัครใช้งานเองและข้อจำกัดสำหรับ EU/EEA ควรตรวจสอบจากคอนโซลแบบเรียลไทม์

ตั้งค่าคำขอ Fugu ใน Apidog

สร้างโปรเจกต์ใหม่ใน Apidog แล้วเพิ่ม HTTP request ใหม่สำหรับ Fugu

1. ใช้ Environment Variables สำหรับ host และ key

อย่าใส่ API key ตรงๆ ใน URL หรือ request ที่แชร์ได้ ให้สร้าง environment เช่น Fugu Prod แล้วเพิ่มตัวแปรสองตัว:

Variable	Value
fugu_base_url	<YOUR_FUGU_BASE_URL_FROM_CONSOLE>
fugu_key	API key จาก Sakana console

จากนั้นใช้ตัวแปรเหล่านี้ใน request:

{{fugu_base_url}}/chat/completions

และ header:

Authorization: Bearer {{fugu_key}}

ข้อดีคือเมื่อสลับ staging/production คุณเปลี่ยน environment ได้ทันที ไม่ต้องไล่แก้ request ทุกตัว รูปแบบนี้คล้ายกับการเปลี่ยน Base URL และ Bearer token ใน คู่มือ Claude Code with OpenRouter

2. สร้าง Request Body

ตั้งค่า request ดังนี้:

Method: POST
URL: {{fugu_base_url}}/chat/completions

Headers:

Authorization: Bearer {{fugu_key}}
Content-Type: application/json

Body:

{
  "model": "fugu",
  "messages": [
    { "role": "system", "content": "You are a concise API testing assistant." },
    { "role": "user", "content": "Summarize what an SSE delta is in two sentences." }
  ],
  "stream": false
}

รูปแบบนี้ตรงกับ OpenAI Chat Completions API เพราะ Fugu ใช้ endpoint ที่เข้ากันได้กับ OpenAI

Model ID ที่ระบุเมื่อเปิดตัวคือ:

• fugu
• fugu-ultra

อาจมี ID แบบมีวันที่กำกับ เช่น fugu-ultra-20260615 ให้ยืนยันชื่อจริงในคอนโซลก่อนใช้งานจริง และหลีกเลี่ยงการ hardcode ID ที่อาจเปลี่ยนได้

เมื่อส่ง request แล้ว คุณควรได้ response แบบ Chat Completion ที่มี choices และ usage ให้บันทึก request นี้ใน Apidog เป็น:

Fugu balanced

ส่งไปยัง Fugu Ultra และบันทึก request ที่สอง

Duplicate request เดิม แล้วเปลี่ยนเฉพาะ field model เป็น fugu-ultra

{
  "model": "fugu-ultra",
  "messages": [
    {
      "role": "user",
      "content": "Reproduce the core result of the Trinity coordinator paper in plain language and note one limitation."
    }
  ],
  "stream": false
}

บันทึก request นี้เป็น:

Fugu Ultra

ตอนนี้คุณมี request สองตัวที่ใช้ endpoint เดียวกัน ต่างกันเฉพาะ model:

• Fugu balanced ใช้ model: "fugu"
• Fugu Ultra ใช้ model: "fugu-ultra"

วิธีทดสอบที่แนะนำ:

1. ใช้ prompt เดียวกันกับทั้งสอง request
2. ส่ง request ซ้ำหลายรอบ
3. เปรียบเทียบ response quality
4. ดู latency ที่ Apidog แสดงในแต่ละ response
5. ตรวจ usage.total_tokens

Apidog เก็บ response history ของแต่ละ request ทำให้คุณย้อนดูผลลัพธ์และเวลาแฝงจากหลายรอบได้ หากต้องการทดสอบหลาย request แบบเป็นลำดับ อ่านเพิ่มได้ที่ คู่มือการประสานงานการทดสอบ API

ตรวจสอบ SSE Streaming

การ streaming ช่วยให้เห็นพฤติกรรมของ Fugu ชัดขึ้น โดยเฉพาะเวลาที่ Ultra ใช้เวลาประสานงานก่อนเริ่มปล่อย token

เปลี่ยน stream เป็น true:

{
  "model": "fugu-ultra",
  "messages": [
    {
      "role": "user",
      "content": "Walk through a one-shot chess opening analysis, step by step."
    }
  ],
  "stream": true
}

เมื่อเปิด streaming response จะเป็น:

Content-Type: text/event-stream

และจะส่งข้อมูลเป็นชุดของ data: event เช่น:

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":" Sicilian"},"finish_reason":null}]}

data: [DONE]

สิ่งที่ต้องดู:

• delta.content: token หรือข้อความย่อยที่เพิ่มเข้ามา
• chunk แรกอาจมี role
• chunk ถัดไปมี content
• stream จบเมื่อเจอ data: [DONE]
• หากมีช่องว่างนานก่อน delta แรก โดยเฉพาะใน fugu-ultra อาจสะท้อนเวลาที่ใช้ในการประสานงานหลายโมเดลก่อนตอบ

ใน Apidog คุณสามารถดู SSE stream แบบ real-time ได้โดยไม่ต้องเขียน parser เอง

อ่าน usage และเปรียบเทียบต้นทุน token

สำหรับ request ที่ไม่ได้เปิด streaming ให้ดู block usage ใน response:

{
  "usage": {
    "prompt_tokens": 38,
    "completion_tokens": 412,
    "total_tokens": 450
  }
}

ความหมายหลัก:

• prompt_tokens: token จาก input
• completion_tokens: token จาก output
• total_tokens: รวม input + output

ข้อควรจำ: Fugu เป็น orchestrator ที่อาจเรียกใช้โมเดลอื่นเบื้องหลัง รวมถึงอินสแตนซ์ของตัวเองซ้ำๆ ค่า usage ที่คุณเห็นคือการใช้งานของ request หลักที่ส่งไปยัง Fugu ไม่ใช่รายละเอียด token ของทุกโมเดล downstream ที่ Fugu อาจเรียกใช้

โครงสร้างราคาตามที่ Sakana ระบุมีทั้ง subscription tiers สำหรับการใช้งานทั่วไป และ pay-as-you-go สำหรับงานที่หนักขึ้นหรืองานระดับองค์กร

สำหรับจุดเปรียบเทียบกับผู้ให้บริการอื่น อัตราที่ Anthropic เผยแพร่เมื่อ 2026-06-09 ระบุว่า Fable 5 และ Mythos 5 มีราคา $10 ต่อ input 1 ล้าน token และ $50 ต่อ output 1 ล้าน token ดูตัวอย่างการตั้งค่า endpoint นั้นได้ใน คู่มือ Claude Fable 5 API

วัดต้นทุนของ Orchestration Hop ผ่าน Latency

การทดสอบที่มีประโยชน์ที่สุดคือส่ง prompt เดียวกันไปยัง fugu และ fugu-ultra แล้วเปรียบเทียบเวลาตอบสนอง

ตัวอย่าง prompt:

Analyze this API design for reliability, security, and developer experience. Give concrete fixes.

ขั้นตอน:

1. เปิด request Fugu balanced
2. ใส่ prompt เดียวกัน
3. ส่ง request และจด latency
4. เปิด request Fugu Ultra
5. ใช้ prompt เดิม
6. ส่ง request และจด latency
7. เปรียบเทียบ response quality, latency และ usage

โดยทั่วไปเวอร์ชันสมดุลควรตอบเร็วกว่า เพราะ Sakana วางตำแหน่ง fugu สำหรับงาน latency ต่ำและ interactive services ส่วน fugu-ultra เน้นคุณภาพสูงสุดสำหรับงานวิจัยและงานที่ต้องใช้ reasoning มากกว่า

หาก Ultra ช้ากว่าอย่างชัดเจน เวลาที่เพิ่มขึ้นนั้นอาจเป็นสัญญาณของ orchestration hop: Fugu อาจกำลังประสานงานหลายโมเดลก่อนสังเคราะห์คำตอบสุดท้าย

เพื่อให้เห็นความต่างชัดขึ้น ลองใช้ prompt จากกลุ่มงานที่ Sakana ระบุว่า Fugu ทำได้ดี เช่น:

• AutoResearch
• การออกแบบทางกล
• การคาดการณ์อนุกรมเวลาทางการเงิน
• การวิเคราะห์หมากรุกแบบ one-shot
• งาน cybersecurity analysis

ตามที่ Sakana ระบุ Fugu มีผลลัพธ์ที่แข็งแกร่งในงานเฉพาะเหล่านี้เมื่อเทียบกับ Gemini 3.1 Pro, Opus 4.8 และ GPT 5.5 แต่ควรอ่านอย่างระมัดระวัง เพราะ Fugu เป็นระบบประสานงานหลายโมเดล ผลลัพธ์ที่ดีกว่าโมเดลเดี่ยวอาจมาจากการเรียกหลายโมเดลและสังเคราะห์ผลรวม ไม่ใช่การชนะของโมเดลเดี่ยวแบบตรงไปตรงมา

ตรวจสอบ Routing และ Governance ของ Agent

หน้าเปิดตัวของ Fugu อธิบายว่ามี agent pool ที่สามารถสลับเปลี่ยนได้ ทีมสามารถเลือกไม่ใช้ agent บางตัวได้ด้วยเหตุผลด้านข้อมูลหรือ compliance และ Fugu สามารถ route แบบไดนามิกเพื่อหลีกเลี่ยงข้อจำกัดของผู้ให้บริการ

หากคอนโซลของคุณมีตัวควบคุม agent pool ให้ทดสอบแบบนี้:

1. บันทึก request ใน Apidog ไว้ก่อน
2. ส่ง prompt ชุดเดิมและบันทึกผลลัพธ์
3. เปลี่ยนการตั้งค่า agent/model pool ในคอนโซล
4. รัน request เดิมซ้ำ
5. เปรียบเทียบ response, latency และ usage

งานวิจัยที่เกี่ยวข้องมีสองฉบับที่ควรแยกให้ออก:

• Trinity, “An Evolved LLM Coordinator”: ตัวประสานงานที่มีพารามิเตอร์น้อยกว่า 20,000 ตัว ปรับด้วย derivative-free evolution และมีบทบาท Thinker, Worker, Verifier
• Conductor, “Learning to Orchestrate Agents in Natural Language”: โมเดล 7 พันล้านพารามิเตอร์ที่ฝึกด้วย reinforcement learning เพื่อเรียนรู้โครงสร้างการสื่อสารของตัวเอง

ทั้งสองงานใช้วิธีและขนาดต่างกัน อย่าสับสนระหว่างงานวิจัยกับตัวเลขของผลิตภัณฑ์ที่จัดส่งจริง เพราะการผูกจำนวนพารามิเตอร์เฉพาะกับ Fugu เวอร์ชัน production เป็นการอนุมาน ไม่ใช่ตัวเลขทางการจากผลิตภัณฑ์

เวิร์กโฟลว์ที่แนะนำใน Apidog

เหตุผลที่ควรทดสอบ Fugu ใน Apidog แทนการใช้ curl ครั้งเดียว คือการทำซ้ำและเปรียบเทียบได้ง่าย

เวิร์กโฟลว์ที่แนะนำ:

1. สร้าง environment Fugu Prod
2. เก็บ fugu_base_url และ fugu_key
3. สร้าง request Fugu balanced
4. Duplicate เป็น Fugu Ultra
5. ใช้ prompt เดียวกันกับทั้งสอง request
6. เปรียบเทียบ response, latency และ usage
7. เปิด stream: true เพื่อดู SSE delta
8. บันทึก history เพื่อดูแนวโน้ม latency และคุณภาพคำตอบ

เมื่อ Sakana เปลี่ยน model ID หรือคุณสลับจาก staging ไป production คุณแก้แค่ environment variable ไม่ต้องแก้ request ทุกตัว

Sakana มาจากคำภาษาญี่ปุ่นที่แปลว่าปลา และแนวคิดฝูงปลาก็เข้ากับระบบที่ประสานหลายโมเดลให้กลายเป็นคำตอบเดียว Fugu หรือปลาปักเป้าเป็นอาหารที่ปลอดภัยเมื่อผู้เชี่ยวชาญเตรียมอย่างถูกต้อง การเปรียบเทียบนี้ใช้เป็นภาพจำได้ แต่อย่าใช้แทน benchmark จริง

หากต้องการเริ่มทดสอบ ให้ชี้ request ที่เข้ากันได้กับ OpenAI ไปยัง Fugu บันทึกเวอร์ชัน fugu และ fugu-ultra ใน Apidog แล้วส่ง prompt เดียวกันเพื่อดูต้นทุนของ orchestration hop ด้วยตัวเอง

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

ฉันควรใช้ Base URL ใดในการทดสอบ Fugu ใน Apidog?

ให้คัดลอก Base URL จาก console.sakana.ai หลังจากลงชื่อเข้าใช้ Sakana ยังไม่ได้เผยแพร่ host ในหน้าสาธารณะ ณ วันที่ 2026-06-22 ดังนั้นอย่าคาดเดาเอง ให้เก็บเป็น environment variable ใน Apidog แล้วเรียกใช้แบบนี้:

{{fugu_base_url}}/chat/completions

ต้องใช้ SDK พิเศษในการเรียก Fugu หรือไม่?

ไม่จำเป็น Fugu มี endpoint ที่เข้ากันได้กับ OpenAI ดังนั้นไคลเอ็นต์หรือเครื่องมือที่รองรับ Chat Completions API สามารถใช้งานได้ด้วยการเปลี่ยน Base URL และ API key เท่านั้น รูปแบบนี้คล้ายกับที่อธิบายใน คู่มือ Claude Code with OpenRouter

ทดสอบ streaming response จาก Fugu อย่างไร?

ตั้งค่าใน body:

"stream": true

response จะมาเป็น text/event-stream โดยแต่ละ event มี prefix data: และบรรจุ delta ที่เพิ่มขึ้นทีละส่วน stream จะจบด้วย:

data: [DONE]

Apidog สามารถแสดง SSE stream แบบ real-time ได้ ทำให้เห็น token หรือข้อความย่อยที่ส่งกลับมาทีละช่วง

Fugu และ Fugu Ultra ต่างกันอย่างไร?

fugu เป็นเวอร์ชันสมดุล latency ต่ำ เหมาะกับ coding, code review, chatbot และงาน interactive ทั่วไป ส่วน fugu-ultra มุ่งเน้นคุณภาพคำตอบสูงสุดสำหรับงานวิจัย งาน reasoning และการวิเคราะห์ที่ซับซ้อน ทั้งสองใช้ endpoint เดียวกันและต่างกันที่ค่า model

ทำไม Fugu Ultra ถึงช้ากว่าเวอร์ชันสมดุล?

เพราะ Ultra อาจใช้ orchestration ที่ลึกกว่าเพื่อให้ได้คำตอบคุณภาพสูงขึ้น ตามที่ Sakana ระบุ Fugu สามารถตอบเองหรือรวบรวมทีมโมเดลเบื้องหลังได้ latency ที่สูงขึ้นใน Apidog จึงเป็นสัญญาณที่ช่วยให้สังเกตต้นทุนของ orchestration hop ได้

ผลลัพธ์ benchmark ของ Fugu มาจากโมเดลเดียวหรือไม่?

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