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

ในการทดสอบ Sakana Fugu API ใน Apidog ให้สร้างคำขอ HTTP ใหม่ที่ชี้ไปยังพาธ `/chat/completions` ที่เข้ากันได้กับ OpenAI ของ Fugu เพิ่มส่วนหัว Authorization: Bearer พร้อมคีย์ของคุณ และส่งเพย์โหลดที่ระบุโมเดล fugu หรือ fugu-ultra เนื่องจาก Fugu มี ปลายทางที่เข้ากันได้กับ OpenAI เพียงหนึ่งเดียว เครื่องมือใดๆ ที่ใช้รูปแบบการแชทของ OpenAI จึงทำงานได้โดยไม่ต้องเปลี่ยน SDK และ Apidog ช่วยให้คุณตรวจสอบการสตรีม, บันทึกรูปแบบคำขอที่แตกต่างกัน, และเปรียบเทียบความแตกต่างของคำตอบได้ในหน้าต่างเดียว คู่มือนี้จะอธิบายขั้นตอนทั้งหมด: สร้างคำขอ, ดูความเปลี่ยนแปลงของ SSE, อ่านออบเจกต์ usage, และเปรียบเทียบเวลาแฝงระหว่าง Fugu รุ่นสมดุลกับ Fugu Ultra ที่ช้ากว่า เพื่อให้คุณเห็นค่าใช้จ่ายของการประสานงาน (orchestration hop) ในการตอบสนองจริง

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

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

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

การออกแบบนี้มีความสำคัญต่อการทดสอบ เมื่อคุณส่งคำขอหนึ่งครั้ง Fugu จะตัดสินใจว่าจะตอบโดยตรง หรือจะรวบรวมทีมเบื้องหลัง คุณจะเห็นการตอบสนองเพียงหนึ่งเดียว แต่การทำงานเบื้องหลังอาจเกี่ยวข้องกับหลายโมเดล ดังนั้น สิ่งที่ควรวัดใน Apidog จึงแตกต่างจากการทดสอบโมเดลทั่วไป: คุณจะสังเกตเวลาแฝง (latency) เพื่อดูว่า Fugu ทำงานแบบผ่านครั้งเดียว หรือผ่านการประสานงานหลายขั้นตอน (orchestration hop) และอ่านออบเจกต์ usage เพื่อดูค่าใช้จ่ายโทเค็นในการเรียกหลัก

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

• Fugu (เวอร์ชันที่สมดุลและมีเวลาแฝงต่ำ) เหมาะสำหรับงานประจำวัน: การเขียนโค้ด, การตรวจสอบโค้ด, แชทบอท, และบริการเชิงโต้ตอบ
• Fugu Ultra มุ่งเน้นคุณภาพการตอบสนองสูงสุด: การวิจัย AI, การทำซ้ำงานวิจัย, การวิเคราะห์ความปลอดภัยทางไซเบอร์, และการตรวจสอบวรรณกรรมหรือสิทธิบัตร

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

รับ Base URL และคีย์ก่อนเริ่มต้น

Fugu อยู่หลังกำแพงการเข้าสู่ระบบ คุณสามารถลงชื่อเข้าใช้ที่ console.sakana.ai ด้วย Google หรืออีเมล และคอนโซลคือที่ที่คุณจะคัดลอกคีย์ API และ Base URL ของคุณ

ข้อควรทราบที่สำคัญสำหรับวันที่ 2026-06-22: Base URL ไม่ได้เผยแพร่ในหน้าสาธารณะใดๆ ของ Sakana อย่าคาดเดา คัดลอกโฮสต์จริงจากคอนโซลและเก็บไว้เป็นตัวแปร ทุกที่ในคู่มือนี้ที่คุณเห็น <YOUR_FUGU_BASE_URL_FROM_CONSOLE> ให้แทนที่ด้วยค่าที่คอนโซลแสดงให้คุณเห็น การเข้าถึงยังเปลี่ยนจากการทดสอบเบต้าที่มีผู้ใช้ประมาณ 500 คนไปสู่การเปิดให้ใช้งานทั่วไปแล้ว; ว่าการสมัครใช้งานด้วยตนเองเปิดเต็มที่หรือไม่ และมีข้อจำกัดสำหรับ EU/EEA หรือไม่ ทั้งสองประเด็นนี้ควรตรวจสอบในคอนโซลแบบเรียลไทม์

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

ดาวน์โหลด Apidog หากคุณยังไม่มี จากนั้นสร้างโปรเจกต์ใหม่และคำขอ HTTP ใหม่

ใช้ตัวแปรสภาพแวดล้อมสำหรับคีย์และโฮสต์

อย่าคัดลอกข้อมูลที่เป็นความลับไปวางในแถบ URL สภาพแวดล้อมของ Apidog ช่วยให้คุณจัดเก็บ Base URL และคีย์ได้เพียงครั้งเดียว และอ้างอิงถึงข้อมูลเหล่านั้นในทุกคำขอ สร้างสภาพแวดล้อม (ตั้งชื่อว่า Fugu Prod) และเพิ่มตัวแปรสองตัว:

• fugu_base_url ตั้งค่าเป็นค่า <YOUR_FUGU_BASE_URL_FROM_CONSOLE> ของคุณ
• fugu_key ตั้งค่าเป็นคีย์ API ของคุณจากคอนโซล

ตอนนี้ URL คำขอของคุณจะกลายเป็น {{fugu_base_url}}/chat/completions และค่าส่วนหัวของคุณจะกลายเป็น Bearer {{fugu_key}} การสลับระหว่างคีย์สำหรับ staging และคีย์สำหรับ production ทำได้เพียงแค่เปลี่ยนในเมนูดรอปดาวน์ ไม่ใช่การค้นหาและแทนที่ในทุกคำขอ หากคุณเคยเชื่อมต่อผู้ให้บริการอื่นที่เข้ากันได้กับ OpenAI ผ่านเกตเวย์มาก่อน รูปแบบนี้จะคล้ายกับที่อธิบายไว้ใน คู่มือการใช้งาน Claude Code with OpenRouter โดยที่ Base URL และ Bearer token เดียวกันสามารถเปลี่ยนเส้นทางไคลเอ็นต์ OpenAI ไปยังแบ็คเอนด์ใหม่ได้

สร้าง Request Body

ตั้งค่าเมธอดเป็น POST, URL เป็น {{fugu_base_url}}/chat/completions, และเพิ่มส่วนหัวเหล่านี้:

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

จากนั้นวางเพย์โหลดแชทมาตรฐานของ OpenAI ลงใน 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 ทุกประการ ซึ่งเป็นจุดประสงค์ของปลายทางที่เข้ากันได้กับ OpenAI สตริง ID ของโมเดลที่รายงานเมื่อเปิดตัวคือ fugu และ fugu-ultra (และอาจเป็นรูปแบบที่มีวันที่กำกับ เช่น fugu-ultra-20260615) ยืนยัน ID ที่แน่นอนในคอนโซล แทนที่จะฮาร์ดโค้ดสตริงที่มีวันที่กำกับ เนื่องจาก ID ที่มีวันที่อาจมีการเปลี่ยนแปลง

ส่งคำขอ คุณควรได้รับออบเจกต์การทำ Chat Completion กลับมา โดยมีอาร์เรย์ choices และบล็อก usage บันทึกคำขอนี้ใน Apidog เป็น “Fugu balanced”

ส่งไปยังเวอร์ชัน 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
}

บันทึกสิ่งนี้เป็น “Fugu Ultra” ตอนนี้คุณมีคำขอที่บันทึกไว้สองรายการที่ส่งไปยังปลายทางเดียวกัน โดยแตกต่างกันเพียงฟิลด์ model เท่านั้น นี่คือการตั้งค่าที่ทำให้ส่วนที่เหลือของการทดสอบมีความหมาย คุณส่งข้อความแจ้ง (prompt) เดียวกันไปยังทั้งสองรายการ จากนั้นเปรียบเทียบความแตกต่างของการตอบสนองและเวลา Apidog เก็บประวัติการตอบสนองสำหรับแต่ละคำขอ ดังนั้นคุณสามารถเรียกใช้แต่ละรายการซ้ำได้ และดูว่าคำตอบและเวลาแฝงเปลี่ยนแปลงไปอย่างไร สำหรับรูปแบบที่กว้างขึ้นเกี่ยวกับการเชื่อมโยงและการเปรียบเทียบการเรียก API, คู่มือการประสานงานการทดสอบ API จะครอบคลุมวิธีการจัดลำดับและยืนยันผลลัพธ์ในคำขอหลายรายการ

ตรวจสอบความเปลี่ยนแปลงของการสตรีม SSE

การสตรีมคือจุดที่พฤติกรรมของ Fugu น่าสนใจ เพราะแม้จะเป็นการประสานงานหลายขั้นตอนที่ใช้เวลานาน ก็ยังคงสตรีมโทเค็นออกมาเมื่อเสร็จสิ้น เปลี่ยน stream เป็น true:

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

เมื่อเปิดการสตรีม การตอบสนองจะเป็น text/event-stream และมาถึงในรูปแบบของชุด data: ชิ้น Apidog แสดงผลสตรีม SSE แบบเรียลไทม์ ทำให้คุณเห็นความเปลี่ยนแปลงปรากฏขึ้นแทนที่จะจ้องมองไอคอนโหลด แต่ละชิ้นจะมีลักษณะดังนี้:

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 บรรจุเนื้อหาโทเค็นที่เพิ่มขึ้นทีละน้อย ชิ้นแรกมักจะบรรจุ role จากนั้นชิ้นถัดๆ ไปจะบรรจุส่วนย่อยของ content และการสตรีมจะสิ้นสุดลงเมื่อมีการตั้งค่า finish_reason และมีบรรทัด data: [DONE] สุดท้าย สังเกตช่วงห่างก่อนที่ delta ตัวแรกจะมาถึงในเวอร์ชัน Ultra การหยุดพักนานๆ ก่อนที่โทเค็นจะเริ่มมาถึง ตามด้วยการสตรีมที่สม่ำเสมอ เป็นสัญญาณที่มีประโยชน์ว่า Fugu ได้รวบรวมทีมก่อนที่จะตอบคำถาม เวอร์ชันสมดุลมักจะเริ่มสตรีมเร็วกว่า เพราะมันมักจะตอบโดยตรง

อ่านออบเจกต์ Usage และเปรียบเทียบค่าใช้จ่าย

เมื่อการเรียกที่ไม่ใช่การสตรีมส่งผลตอบกลับมา ให้เปิดบล็อก usage ในการตอบสนอง:

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

จำนวนโทเค็นในการเรียกหลักคือสิ่งที่ Apidog แสดงให้คุณเห็นโดยตรง ข้อควรระลึกอย่างหนึ่งคือ: Fugu เป็นตัวประสานงาน (orchestrator) ที่เรียกใช้โมเดลชั้นนำของผู้ขายรายอื่น รวมถึงตัวมันเองซ้ำๆ ค่า usage ที่คุณอ่านคือการนับการใช้งานตามคำขอของคุณที่ส่งไปยัง Fugu ไม่ใช่การมองเห็นโมเดลปลายน้ำทุกตัวที่ Fugu อาจเรียกใช้ โครงสร้างราคา ตามที่ Sakana ระบุ มีทั้งแบบ subscription tiers สำหรับการใช้งานทั่วไป และแบบ pay-as-you-go สำหรับงานที่หนักขึ้นและงานระดับองค์กร

สำหรับจุดเปรียบเทียบที่เป็นรูปธรรม อัตราที่ Anthropic เผยแพร่ (2026-06-09) ระบุว่า Fable 5 และ Mythos 5 มีราคา $10 ต่ออินพุต 1 ล้านโทเค็น และ $50 ต่อเอาต์พุต 1 ล้านโทเค็น คู่มือ Claude Fable 5 API ฉบับคู่กันจะครอบคลุมปลายทางนั้น หากคุณต้องการฐานข้อมูลโมเดลเดียวเพื่อทดสอบควบคู่กับ Fugu ในโปรเจกต์ Apidog เดียวกัน

วัดค่าใช้จ่ายของการประสานงาน (orchestration hop) ในแง่ของเวลาแฝง

นี่คือการทดสอบที่ยืนยันความจำเป็นในการรันทั้งสองเวอร์ชัน ส่งข้อความแจ้ง (prompt) เดียวกันไปยัง “Fugu balanced” และ “Fugu Ultra” จากนั้นอ่านเวลาตอบสนองที่ Apidog รายงานที่ด้านล่างของแต่ละผลลัพธ์

โดยปกติคุณจะเห็นเวอร์ชันสมดุลตอบสนองเร็วกว่า ตามที่ Sakana ระบุ “Fugu” แบบสมดุลมุ่งเป้าไปที่เวลาแฝงต่ำและบริการแบบโต้ตอบ ในขณะที่ Ultra มุ่งเป้าไปที่คุณภาพสูงสุดสำหรับงานวิจัย ความแตกต่างของเวลาแฝงคือสัญญาณที่มองเห็นได้ของการประสานงานหลายขั้นตอน: เมื่อ Ultra ใช้เวลานานขึ้น เวลาที่เพิ่มขึ้นนั้นคือ Fugu กำลังประสานงานทีมแทนที่จะตอบในครั้งเดียว การจับเวลาต่อคำขอและประวัติที่บันทึกไว้ของ Apidog ช่วยให้คุณสามารถรันแต่ละเวอร์ชันได้หลายครั้งและประเมินด้วยตาเปล่าว่าความแตกต่างนั้นคงที่หรือขึ้นอยู่กับข้อความแจ้ง (prompt)

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

การกำหนดเส้นทางและการกำกับดูแลของเอเจนต์ที่คุณสามารถตรวจสอบได้

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

ที่มาของการวิจัยเป็นของจริงและสามารถอ้างอิงได้ แนวทางนี้มีพื้นฐานมาจากบทความวิจัย ICLR 2026 สองฉบับ: Trinity, “An Evolved LLM Coordinator” ซึ่งเป็นตัวประสานงานที่มีพารามิเตอร์น้อยกว่า 20,000 ตัว ที่ได้รับการปรับให้เหมาะสมด้วย derivative-free evolution โดยมีบทบาท Thinker, Worker และ Verifier และ Conductor, “Learning to Orchestrate Agents in Natural Language” ซึ่งเป็นโมเดล 7 พันล้านพารามิเตอร์ที่ได้รับการฝึกฝนด้วยการเรียนรู้แบบเสริมกำลัง (reinforcement learning) ซึ่งเรียนรู้โครงสร้างการสื่อสารของตัวเองและอ้างว่าสามารถเอาชนะ Mixture-of-Agents ได้ด้วยต้นทุนที่ต่ำกว่า ทั้งสองใช้เมธอดและขนาดที่แตกต่างกัน ดังนั้นอย่าสับสน และโปรดทราบว่าการกำหนดจำนวนพารามิเตอร์ที่เฉพาะเจาะจงกับผลิตภัณฑ์ที่จัดส่งนั้นเป็นการอนุมานของบุคคลที่สาม ไม่ใช่ตัวเลขอย่างเป็นทางการ

สิ่งนี้เข้ากับเวิร์กโฟลว์ Apidog ของคุณได้อย่างไร

จุดประสงค์ของการทดสอบ Fugu ใน Apidog แทนที่จะใช้คำสั่ง curl เพียงครั้งเดียว คือความสามารถในการทำซ้ำ คุณบันทึกคำขอทั้งสองเวอร์ชัน เก็บข้อมูลคีย์และโฮสต์ของคุณไว้ในสภาพแวดล้อม เรียกใช้ซ้ำด้วยข้อความแจ้งใหม่ เปรียบเทียบความแตกต่างของการตอบสนองแบบเคียงข้างกัน และอ่านค่าเวลาแฝงและ usage โดยไม่ต้องออกจากเครื่องมือ เมื่อ Fugu หมุนเวียน ID โมเดล หรือคุณสลับจากคีย์ staging ไปยัง production คุณเพียงแค่เปลี่ยนตัวแปรสภาพแวดล้อมเดียว และคำขอที่บันทึกไว้ทั้งหมดก็จะตามไปด้วย นั่นคือวงจรการทดสอบและสังเกตการณ์: สร้างเพียงครั้งเดียว จากนั้นดูว่าระบบการประสานงานทำงานอย่างไรเมื่อคุณป้อนข้อความแจ้งที่แตกต่างกันเข้าไป

Sakana มาจากคำภาษาญี่ปุ่นที่แปลว่าปลา และแนวคิดการสร้างแบรนด์ที่เหมือนฝูงปลา ก็เหมาะสมกับตัวประสานงานที่ประสานโมเดลหลายตัวเข้าเป็นคำตอบเดียว ฟุกุ (Fugu) ซึ่งเป็นปลาปักเป้า เป็นอาหารโอชะที่ปลอดภัยก็ต่อเมื่อเชฟผู้เชี่ยวชาญเตรียมมันเท่านั้น การเปรียบเทียบกับการเตรียมอาหารอย่างระมัดระวังเป็นวิธีที่สมเหตุสมผลในการพิจารณาการกำหนดเส้นทางงานข้ามเอเจนต์ ตราบใดที่คุณจำไว้ว่ามันเป็นเพียงสีสัน ไม่ใช่เกณฑ์มาตรฐาน

ชี้คำขอที่เข้ากันได้กับ OpenAI ของคุณไปยัง Fugu บันทึกเวอร์ชันที่แตกต่างกัน และให้ Apidog แสดงให้คุณเห็นว่าตัวประสานงาน (orchestrator) ทำงานอย่างไรภายใต้ภาระงาน ดาวน์โหลด Apidog เพื่อตั้งค่าสภาพแวดล้อม Fugu แรกของคุณ และเริ่มต้นด้วยการส่งข้อความแจ้ง (prompt) เดียวกันไปยังทั้งสองเวอร์ชัน เพื่อดูการประสานงาน (orchestration hop) ด้วยตัวคุณเอง

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

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

คัดลอก Base URL จาก console.sakana.ai หลังจากที่คุณลงชื่อเข้าใช้ Sakana ยังไม่ได้เผยแพร่โฮสต์ในหน้าสาธารณะใดๆ ณ วันที่ 2026-06-22 ดังนั้นอย่าคาดเดา จัดเก็บเป็นตัวแปรสภาพแวดล้อมของ Apidog และอ้างอิงโดยใช้ {{fugu_base_url}}/chat/completions

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

ไม่จำเป็น Fugu มีปลายทางที่เข้ากันได้กับ OpenAI เพียงหนึ่งเดียว ดังนั้นไคลเอ็นต์ OpenAI หรือเครื่องมือใดๆ ที่ใช้รูปแบบการแชทของ OpenAI จะสามารถทำงานได้โดยแค่เปลี่ยน Base URL และคีย์เท่านั้น รูปแบบการเปลี่ยนเส้นทางเดียวกันนี้ปรากฏอยู่ใน คู่มือ Claude Code with OpenRouter เช่นกัน

ฉันจะทดสอบการตอบสนองแบบสตรีมมิ่งจาก Fugu ได้อย่างไร?

ตั้งค่า "stream": true ใน request body การตอบสนองจะมาในรูปแบบ text/event-stream พร้อมกับส่วนย่อย data: ที่บรรจุเนื้อหา delta แบบเพิ่มขึ้นทีละน้อย โดยจะสิ้นสุดด้วย data: [DONE] Apidog แสดงผลสตรีม SSE แบบเรียลไทม์ เพื่อให้คุณสามารถดูความเปลี่ยนแปลงปรากฏขึ้นได้ทันที

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

Fugu เป็นเวอร์ชันที่สมดุลและมีเวลาแฝงต่ำ เหมาะสำหรับงานเขียนโค้ด การตรวจสอบโค้ด และแชทบอทในชีวิตประจำวัน Fugu Ultra มุ่งเป้าไปที่คุณภาพการตอบสนองสูงสุดสำหรับการวิจัย การทำซ้ำงานวิจัย และการวิเคราะห์ความปลอดภัย ทั้งสองทำงานผ่านปลายทางเดียวกัน โดยแตกต่างกันเพียงแค่ฟิลด์ model ซึ่งทำให้ง่ายต่อการบันทึกและเปรียบเทียบความแตกต่างใน Apidog

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

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

ผลลัพธ์การชนะเกณฑ์มาตรฐานของ Fugu มาจากโมเดลเดียวหรือไม่?

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