Kimi K3 แข่งขันกับ Fable และการผสานสองโมเดลช่วยให้ได้ประสิทธิภาพระดับสูงสุด

 (fireworks.ai)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการเปรียบเทียบ Kimi K3 กับ Fable 5 ใน งานเอเจนต์ราว 1,030 งาน พบว่าการกำหนดเส้นทางตามงานทำได้คุณภาพสูงกว่าโมเดลเดี่ยว ด้วย ความแม่นยำ 93%
  • ประสิทธิภาพโดยรวมในงาน SWE, เทอร์มินัล, อัลกอริทึม, หลายภาษา และกฎหมายใกล้เคียงกัน แต่ ขอบเขตงานที่แต่ละโมเดลทำได้โดดเด่น แตกต่างกัน
  • Oracle routing จัดสรรงาน 72–96% ให้ K3 และ K3 คุ้มค่าด้านต้นทุนมากกว่า Fable ในทั้ง 5 กลุ่มงาน
  • ใน agent loop ที่ยาว K3 มีความคุ้มค่าด้านต้นทุนสูงกว่าการใช้ Fable เพียงอย่างเดียวได้สูงสุดราว 50 เท่า แต่เมื่อมีขั้นตอนการดำเนินงานมาก เวลาในการประมวลผลอาจนานขึ้น
  • เราเตอร์ที่ปรับตามเวิร์กโหลด ซึ่งใช้โมเดลโอเพนราคาถูกเป็นค่าเริ่มต้น และส่งงานยากไปยังโมเดลอื่น สามารถยกระดับทั้งคุณภาพและต้นทุนได้

วัดผลด้วยงานเอเจนต์จริง

  • รัน Kimi K3 และ Fable 5 บน harness เดียวกัน เพื่อทำ งานราว 1,030 งาน ในรูปแบบ agent loop จริง
    • SWE: งาน 460 งานที่คล้ายการแก้บั๊กในรีโพซิทอรีจริง
    • เทอร์มินัล: งานเอเจนต์ระยะยาว 89 งาน เช่น ความปลอดภัย, วิทยาการเข้ารหัสลับ, reverse engineering และการดูแลระบบ
    • อัลกอริทึม: ปัญหา 100 ข้อในรูปแบบ LeetCode และ AtCoder
    • หลายภาษา: งานอิมพลีเมนต์ใน 6 ภาษา จำนวน 225 งาน
    • กฎหมาย: งานเอเจนต์ด้านกฎหมาย 120 งานที่ให้ทนายความเป็นผู้ให้คะแนน
  • เปรียบเทียบสองโมเดลโดยเฉลี่ยผล benchmark จากงานหลายประเภท

ความหมายและข้อจำกัดของ Oracle routing

  • Oracle routing คือวิธีวัดเชิงทฤษฎีที่รันงานแต่ละงานกับทุกโมเดลก่อน แล้วเลือกโมเดลที่ถูกที่สุดในบรรดาตัวเลือกที่ตอบถูก
  • เราเตอร์จริงไม่สามารถรันงานล่วงหน้ากับหลายโมเดลได้ จึงต้องคาดการณ์ล่วงหน้าว่าโมเดลใดให้สมดุลระหว่างต้นทุนและคุณภาพดีที่สุด
  • ในวิธีนี้ K3 ถูกเลือกสำหรับ 72–96% ของงานทั้งหมด
  • อาจเป็นไปได้ที่จะมีเราเตอร์ที่แยกงานทั่วไปออกจากงานหางยาวที่ต้องใช้โมเดลระดับบนสุด
    • หากต้องการยืนยันเรื่องนี้ จำเป็นต้องมี ข้อมูล routing เพิ่มเติมในระดับ 10 เท่า ไม่ใช่แค่ระดับหลักหน่วย และต้องตรวจสอบประสิทธิภาพในสภาพแวดล้อมจริง

ประสิทธิภาพรวมใกล้เคียงกัน แต่จุดแข็งต่างกัน

  • ผล SWE ตัวแทนแทบไม่ต่างกัน โดย K3 ได้ 92.4% และ Fable ได้ 92.6%
  • เมื่อดูทั้ง 5 ประเภทงาน ความต่างระหว่างสองโมเดลโดยทั่วไปอยู่ภายในไม่กี่จุดเปอร์เซ็นต์ และ Fable นำเล็กน้อยในช่วงงานเขียนโค้ดหลายภาษา
  • แม้คะแนนรวมใกล้เคียงกัน แต่งานย่อยแสดงให้เห็นว่ามีขอบเขตที่แต่ละโมเดลเหนือกว่าอย่างชัดเจน

ความแตกต่างตามขอบเขตงาน

  • เมื่อแบ่ง SWE ตามขอบเขตปัญหา K3 เหนือกว่าใน symbolic math และเครื่องมือพัฒนา ส่วน Fable เหนือกว่าในงานเว็บและการทำข้อมูลเป็นภาพ
  • ในงานหลายภาษา Fable นำใน Java, Python และ C++ ขณะที่ K3 ทัดเทียมใน JavaScript และ Rust
  • K3 แสดงจุดแข็งในงานเทอร์มินัลระยะยาวที่ต้องสั่งงาน shell หลายสิบครั้ง
    • แก้โจทย์ที่ Fable แก้ไม่ได้ เช่น แฮช 7z, การวิเคราะห์รหัสลับ FEAL, ข้อมูลลับที่รั่วไหล, ช่องโหว่จริง และงาน asynchronous ที่ควบคุมไม่ได้
  • เมื่อเปรียบเทียบทั้งความแม่นยำและต้นทุน Fable นำในงานหลายภาษา ส่วน K3 นำในงานเทอร์มินัลและกฎหมาย ขณะที่ส่วนที่เหลือโดยรวมใกล้เคียงกัน

โครงสร้างที่ทำให้ต้นทุนต่างกัน

  • ความได้เปรียบด้านต้นทุนของ K3 มาจาก ราคาโทเคน, prompt caching และปริมาณการใช้งานต่อหนึ่งงาน
  • ต่อหนึ่งงาน SWE K3 ใช้ราว 55 เทิร์นและ 1.3 ล้านโทเคน ขณะที่ Fable ใช้ราว 21 เทิร์นและ 130,000 โทเคน
  • ในงานเทอร์มินัลที่ยาวกลับกัน Fable ใช้ได้ถึงราว 64 เทิร์นและ 1.5 ล้านโทเคน และบางครั้งไปถึง timeout
  • แม้ K3 จะอ่านโทเคนมากกว่า 10 เท่าในงาน SWE แต่ด้วย การ hit ของ prompt cache ต้นทุนการรันจึงต่ำกว่า Fable
  • เมื่อมีขั้นตอนการดำเนินงานมากขึ้น เวลาในการประมวลผลจริงอาจนานขึ้น
    • สำหรับงานที่ต้องตอบภายใน 2 วินาที latency มีความสำคัญ
    • สำหรับเอเจนต์เบื้องหลังขนาดใหญ่ ยอดค่าใช้จ่ายที่ต่ำกว่ามีความสำคัญมากขึ้น

ผลลัพธ์จากการรวมสองโมเดล

  • หากส่งงานแต่ละงานไปยังโมเดลที่เหมาะกว่า จะได้ ประสิทธิภาพสูงกว่าโมเดลเดี่ยวแต่ละตัว ไม่ใช่แค่ระดับกึ่งกลางระหว่างสองโมเดล
  • Oracle routing ตามงานให้ประสิทธิภาพสูงกว่าการรันโมเดลเดี่ยวเสมอ และความแม่นยำรวมแตะ 93%
  • แม้ส่งทราฟฟิก 72–96% ไปยัง K3 ซึ่งเป็นโมเดลที่เหมาะที่สุดด้านต้นทุน แต่คุณภาพรวมยังสูงกว่าแต่ละโมเดล และต้นทุนเข้าใกล้การใช้ K3 เพียงอย่างเดียว
  • K3 คุ้มค่าด้านต้นทุนมากกว่า Fable ในทั้ง 5 กลุ่มงาน และใน agent loop ที่ยาวทำความคุ้มค่าด้านต้นทุนสูงกว่าได้สูงสุดราว 50 เท่า

Routing ตามเวิร์กโหลดแทนโมเดลเดี่ยว

  • การ route Kimi K3 และ Fable ร่วมกันช่วยใช้ประโยชน์จากจุดแข็งที่ต่างกัน พร้อมลดต้นทุนได้
  • เนื่องจากแต่ละโมเดลมีราคาและความเชี่ยวชาญต่างกัน AI คุณภาพสูงสุดอาจมาจาก การผสานหลายโมเดล มากกว่าผู้ให้บริการรายเดียว
  • โมเดลโอเพนอย่าง K3 ซึ่งมีต้นทุนต่ำกว่าสูงสุด 50 เท่าและ oracle จัดสรรทราฟฟิกส่วนใหญ่ให้ สามารถใช้เป็นตัวเลือกเริ่มต้นได้
  • เราเตอร์ต้องปรับให้เข้ากับเวิร์กโหลดจริง และต้องเรียนรู้ความเหมาะสมระหว่างงานกับโมเดลอย่างต่อเนื่อง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • พอลองรันและทดสอบเองแล้ว โมเดลเหล่านี้ล้วน overfit กับ benchmark กันหมด ต่อให้เข้าใกล้โมเดลแนวหน้าในบางตัวชี้วัด แต่พอเป็นงานจริงก็พัง และประสิทธิภาพการใช้โทเคนก็ต่ำจนน่าขัน
    Fireworks ต่างจากโมเดลปิดตรงที่ได้ประโยชน์อย่างมากจากการโฮสต์ K3 จึงมีแรงจูงใจสูงมากที่จะใช้พาดหัวแบบนี้

    • หลังจากลอง K3, Qwen 3.8 Max Preview, Fable และ Sol มาหลายวัน ก็เห็นด้วยบางส่วนว่า benchmark เชื่อได้ยาก โมเดลจีนช้า และประสิทธิภาพการใช้โทเคนก็ต่ำ
      ถึงอย่างนั้นก็อยู่ในระดับใกล้เคียงกับ โมเดลท็อปรุ่นก่อนหน้า อย่าง Opus 4.8 และ GPT 5.5 และยังเทียบกันได้ที่ https://senko.net/vibecode-bench/
      เมื่อลองใช้ API ทางการและเครื่องมือเขียนโค้ดของแต่ละตัว ให้สร้างเว็บแอปที่เรียบง่ายแต่ไม่หมูจากสเปกละเอียดเพียงอย่างเดียว ผลลัพธ์ของ K3, Qwen 3.8 และ Fable แทบไม่ต่างกันในการทดสอบกับผู้ใช้ และในการรีวิวโค้ดโดย Sol ก็ถือว่าผ่านทั้งหมด โดย Fable นำเล็กน้อย
      ในงานจริงยังคงชอบ Opus 4.8 กับ Sol มากกว่า แต่ถ้าต้องการทางเลือก K3 และ Qwen 3.8 ก็ใช้งานได้ดีพอ
    • ทุกตัว overfit กับ benchmark แต่ประเด็นสำคัญคือ overfit มากน้อยแค่ไหนเมื่อเทียบกันเอง
      โดยหลัก ๆ ประเมินความสามารถด้านโค้ดในสภาพแวดล้อม multi-agent แบบเปิดที่ไม่มีชุดคำตอบถูก และ agent มีอิทธิพลต่อกัน ซึ่งโมเดลจีนมักทำคะแนนต่ำกว่าโมเดลสหรัฐฯ เมื่อเทียบกับที่โฆษณาไว้ใน model card
      Kimi K3 เป็นข้อยกเว้นที่ใกล้แนวหน้าจริง ๆ แต่ช้ามาก Muse Spark 1.1 แข็งแกร่งรองจาก Fable และ Sol และยังคุ้มค่าต้นทุนที่สุด ถือเป็นการพลิกกลับครั้งใหญ่หลัง Llama 4 ข้อมูลอยู่ที่ https://gertlabs.com/rankings
    • Fable ทำงานได้ดีมากแม้กับ codebase ที่ค่อนข้างใหญ่ ต้องแก้หรือชี้ทิศทางให้บ้างไม่กี่ครั้ง แต่ส่วนใหญ่เป็นเพราะข้อกำหนดในพรอมป์ไม่เพียงพอ และกรณีที่ผิดจริง ๆ มีแค่ราวสองครั้ง อัตราผิดพลาดจึงต่ำกว่าตลอดเส้นทางอาชีพของผมเสียอีก
      คุณภาพโค้ด อยู่ในระดับเดียวกับที่ผมเขียนเอง และในด้านที่ไม่คุ้นเคยยังดีกว่าด้วย งานอย่าง refactoring, integration/regression test, การตรวจ audit log และการแจ้งเตือน error ซึ่งคนมักผัดผ่อนหรือรู้สึกน่าเบื่อ ก็ทำได้อย่างสม่ำเสมอ ทำให้ระดับ software engineering โดยรวมสูงขึ้น
      เป็นระบบ production จริงบน Ruby on Rails ที่ค่อนข้างซับซ้อนและใช้ PostgreSQL โดยในแพ็กเกจ Max เดือนละ 200 ดอลลาร์ งบโทเคนไม่ใช่ปัญหา และคุ้มค่าเงินอย่างเพียงพอ
    • ยังไม่ได้อ่านบทความ แต่ก็รู้สึกน่าสงสัยตั้งแต่พาดหัวที่ผู้ให้บริการ inference ชู โมเดลระดับ Mythos ที่ตนเองให้บริการอยู่แล้ว GLM 5.2 ซึ่งมีพารามิเตอร์น้อยกว่า Kimi K3 ไม่ถึงหนึ่งในสามยังคงเป็นโมเดลหลักอยู่
    • การประเมินทั้งหมดนี้ต้องมีเงื่อนไขว่า ณ ตอนนี้ เมื่อดูแนวโน้มแล้ว ต่อให้ยังไม่ดีพอสำหรับการเขียนโค้ดในวันนี้ ก็ชัดเจนว่าจะไปถึงในไม่ช้า และเราควรเตรียมพร้อมสำหรับโลกที่โมเดลเปิดทำงานซอฟต์แวร์ได้แทบทั้งหมด

  • น่าสนใจที่ทดสอบ Kimi K3 และ Fable กับงานราว 1,000 งาน แบ่งเป็น 5 สาขา เช่น software engineering และกฎหมาย
    มี router model อยู่ด้านหน้าเพื่อคาดการณ์ว่าโมเดลใดจะถูกกว่าในการให้คำตอบที่ถูกต้อง และท้ายที่สุดคิดว่าควรให้มันเรียนรู้อย่างต่อเนื่องจาก workload ของแต่ละคน
    router เลือก Kimi ใน 72–96% ของงาน แล้วแต่สาขา และช่วยลดต้นทุนได้ 1.5–50 เท่าตามสาขา

    • router ในที่นี้คือ oracle baseline ที่รันทั้งสองโมเดล ตรวจว่าผ่านหรือไม่ แล้วเลือกโมเดลที่ถูกกว่า
      เป็นเพียงสมมติฐานของ Fireworks ว่าหากมี router ที่ทำนายผลแบบเดียวกันล่วงหน้าได้ ก็จะลดต้นทุนได้ และการมีอยู่ของมันเป็นสมมติฐานสำคัญมาก
    • router ลักษณะคล้ายกันมีหลายตัว เช่น https://openrouter.ai/openrouter/auto

  • ถ้าเป็นโมเดลที่คุยเหมือนมนุษย์ ผมยอมรับได้แม้ คะแนน benchmark ลดลง 5%

    • ผมกลับชอบโมเดลที่ไม่พยายามพูดเหมือนคนมากกว่า
    • ไม่จำเป็นต้องยอมเสีย 5% ก็ได้ แค่เอา output ของ Fable ใส่ Gemini Flash ให้เขียนใหม่เป็นประโยคที่อ่านง่ายขึ้น
    • ผมอยากอย่างยิ่งให้โมเดลไม่เลียนแบบน้ำเสียงแบบมนุษย์ของผม พฤติกรรมที่ Claude ทำตัวเหมือนเพื่อนและตอบมุกด้วย LOL ไม่ใช่แค่น่าขำ แต่ยังเป็นโทษด้วย
    • โดยปกติ Opus จะสร้างสำนวนที่ผมเรียกว่า ภาษา Claude ออกมา เป็นประโยคที่ถูกทำให้ง่ายเกินไปและไม่สมบูรณ์ทางไวยากรณ์จนอ่านลำบาก แม้มันอาจอ่านเขียนง่ายสำหรับโมเดล แต่ไม่ใช่สำหรับมนุษย์
      ตัวอย่างเช่น มันสรุปคำแนะนำยาว ๆ สำหรับบทความวิชาการออกมาเป็นบรรทัดเดียวที่แน่นไปด้วยคำสั่งเป็นท่อน ๆ แบบ “ตอนนี้ให้กวาดตาดูหนึ่งรอบ แล้วค่อยอ่าน Part II พร้อมย้อนกลับมาอ้างอิง” พร้อมคีย์เวิร์ดตัวหนาและลูกศรเชื่อมเต็มไปหมด
    • LLM ไม่ใช่มนุษย์ แล้วทำไมต้องพูดเหมือนคนด้วย

  • Anthropic ดูเหมือนกำลัง เล่นภาพจักรวรรดิโรมันแบบเร่งความเร็ว ราวกับผ่านจุดสูงสุดและเข้าสู่ช่วงขาลงแล้ว ทั้งที่ยังไม่ทัน IPO

  • สงสัยว่าเมื่อสมัครแพ็กเกจเขียนโค้ดของ Kimi K3 แล้ว การกำกับดูแลข้อมูลและการคุ้มครองความเป็นส่วนตัว จะถูกนำไปใช้อย่างไร อยากย้ายมาจาก Anthropic

    • ตาม https://platform.kimi.ai/docs/agreement/modeluse เนื้อหาอาจถูกใช้เพื่อให้บริการ บำรุงรักษา พัฒนา และปรับปรุงบริการได้ และลูกค้าที่ต้องการจำกัดการใช้เพื่อฝึกโมเดลต้องหารือเรื่องสัญญาองค์กรหรือข้อตกลงเป็นลายลักษณ์อักษรแยกต่างหาก
      ต่างจาก Claude ตรงที่ไม่มี ตัวเลือกปฏิเสธการใช้ข้อมูล สำหรับการฝึกโมเดล และตามเงื่อนไข Kimi สามารถใช้โค้ดของลูกค้าในการฝึกได้
    • คงต้องรอจนกว่าผู้ให้บริการฝั่งตะวันตกจะเริ่มโฮสต์ให้
    • วิธีที่ง่ายที่สุดคือสมัคร OpenRouter แล้วตัดผู้ให้บริการทั้งหมดที่ไม่ใช่ ไม่เก็บรักษาข้อมูล (ZDR) ออกไป อย่างไรก็ตาม ค่า API อาจแพงกว่าแพ็กเกจเขียนโค้ด และโทเคน 1.7 พันล้านที่มีให้ในแพ็กเกจเดือนละ 20 ดอลลาร์ของ MiniMax มีมูลค่าตามราคา API มากกว่า 200–500 ดอลลาร์ ขึ้นอยู่กับสัดส่วนอินพุต/เอาต์พุตและแคช
      ถ้าไม่อยากติดต่อบริษัทจีนโดยตรง AtlasCode เดือนละ 20 ดอลลาร์, OpenCode Go เดือนละ 10 ดอลลาร์ และ Cline Pass เดือนละ 10 ดอลลาร์ ให้โควตาการใช้งานมากกว่า 2–6 เท่าสำหรับโมเดล open weights ยอดนิยมบางตัว
      ส่วนตัวสมัคร Z.ai เดือนละ 17 ดอลลาร์ และจ่ายค่า API ให้ผู้ให้บริการต้นทางของ MiMo v2.5, Hy3, Qwen 3.7 Plus และ DeepSeek v4 แยกต่างหาก
    • ดูเงื่อนไขความเป็นส่วนตัวได้ที่ https://www.kimi.com/user/agreement/zh/userPrivacy

  • สงสัยว่าสามารถรับเงินมาเขียนบทความแบบนี้เพื่อโปรโมตโมเดลเปิดได้หรือไม่ และถ้าได้ เป้าหมายคืออะไร
    จากที่เคยทำงานกับ FastAPI·Python และ Spring Boot·Java ในผลิตภัณฑ์ SaaS สมัยใหม่ โมเดลเปิดที่ทั้งเก่งและมีประสิทธิภาพมีเพียง Qwen 3.7 Max เท่านั้น
    GLM 5.2 และ Kimi มักค้น codebase อยู่เกือบ 70,000–80,000 โทเคนก่อนจะเขียนโค้ด แล้วสุดท้ายก็ทำโค้ดพัง ต้องให้สเปกละเอียดมากเหมือนเมื่อปีก่อนถึงจะทำได้ดี แต่ Qwen 3.7 ทำงานเสร็จโดยแทบไม่ต้องออกแรง

    • เป็น คอนเทนต์มาร์เก็ตติ้ง ที่ดี Fireworks เป็นผู้ให้บริการ inference สำหรับโมเดลขนาดใหญ่ที่ขายสิทธิ์เข้าถึง Kimi K3
    • Fireworks เชี่ยวชาญด้านการรันโมเดลเปิดให้เร็ว และรายได้ส่วนใหญ่ได้จากโมเดลจีน ดังนั้นแรงจูงใจทางเศรษฐกิจก็คือตัวโมเดลธุรกิจทั้งหมด
    • ธุรกิจอิทธิพลในแวดวงเทคโนโลยีมีเงินจำนวนมาก แต่ส่วนใหญ่จะมาจากผู้เล่นรายใหญ่ เช่น การซื้อกิจการ tbpn ของ OpenAI หรือการให้กลุ่มอินฟลูเอนเซอร์บางส่วนเข้าถึงก่อน
    • Lin Qiao เป็นผู้ร่วมก่อตั้งและ CEO ของ Fireworks AI LLM เป็นเหมือนการแข่งขันอวกาศในสงครามเย็นระหว่างสหรัฐฯ กับจีน ดังนั้นแรงจูงใจในการพิสูจน์ ความเหนือกว่าทางชาติพันธุ์และอารยธรรม อาจมากกว่าเรื่องเงิน

  • สงสัยว่า Kimi มีอะไรที่ดีกว่าเป็นพิเศษในกรณีนี้หรือไม่ เข้าใจว่าราคาใกล้เคียงกับ Sonnet 5 เลยสงสัยว่าถ้าใช้ Sonnet 5 กับ Fable หรือใช้ Grok 4.5 ที่ถูกกว่าจะเป็นอย่างไร

    • ในบทความบอกว่า Kimi ดีกว่า Fable ในบางงาน แต่มีความเป็นไปได้สูงว่าไม่ได้ดีกว่า Sonnet
    • ข้อดีของโมเดลเปิดคือองค์กรขนาดใหญ่สามารถ รันในเครื่องและ fine-tune ในดาต้าเซ็นเตอร์ของตนเองได้

  • ชอบโมเดลจีนมาก ใช้แต่ DeepSeek และตอนนี้ก็ใช้ Kimi K3 เป็นผู้ช่วยวางแผนที่ยอดเยี่ยมสำหรับงานเขียนโค้ดขั้นสูงด้วย
    DeepSeek v4 Flash เร็วมาก และจัดการงานแทบทุกอย่างที่มอบหมายใน Rust, PostgreSQL, Angular และ Terraform ได้
    โฮสต์ Bifrost เองในฐานะ LLM gateway แต่อยากให้ผู้ให้บริการคิดเงินอัตโนมัติตามปริมาณใช้งานจริงรายเดือน/รายวันแบบ VPS แทนการเติมเงินล่วงหน้าและเติมเงินอัตโนมัติ อยากจ่ายเฉพาะการใช้งานจริง ไม่ใช่ต้องคงยอดขั้นต่ำที่ขอคืนไม่ได้ไว้กับหลายเจ้า
    OpenRouter ช่วยได้ แต่ไม่ชอบตัวบริการเองและค่าธรรมเนียมเพิ่ม

    • ช่วงนี้ใช้ DeepSeek v4 Pro เป็นหลัก และเพราะมีงานพร้อมกันหลายอย่าง ความเร็วจึงสำคัญน้อยลง ถ้าล้มเหลวก็สลับไป GPT 5.5 ระหว่างคุยเพื่อให้หาปัญหา จากนั้นคงการวิเคราะห์นั้นไว้ในบริบทแล้วสลับกลับมา DeepSeek
      Kimi k2.5/6 ช้าลงและประสิทธิภาพแย่ลง แถมมีข้อผิดพลาด engine overloaded มากขึ้น ส่วน k3 คิดนานแต่ผลลัพธ์ไม่ได้ดีขึ้นอย่างเห็นได้ชัด คิดว่าอาจมีการ quantize โมเดลชั่วคราวเพราะแรงกดดันด้านทรัพยากรคอมพิวต์
      ล่าสุดใช้ DeepSeek v4 Pro เป็นหลัก และใช้ GPT 5.5 เมื่อต้องการโมเดลที่ทรงพลัง GLM 5.2 ดีในบางงานแต่แย่มากในงานอื่น ส่วนโมเดลของ Google หรือ Anthropic ยังไม่น่าประทับใจ
    • ถ้าใช้เครื่องมืออย่าง reasonix หรือ whale จะทำ อัตรา cache hit ได้ราว 98% ทำให้ต้นทุนคำขอแทบเหมือนฟรี ทำได้แม้กับผู้ให้บริการสหรัฐฯ ที่ไม่มีเงินอุดหนุนอย่าง Cloudflare หรือ DigitalOcean
    • ระบบเติมเงินล่วงหน้าช่วยป้องกันไม่ให้ผู้ใช้ใช้ทรัพยากร inference จำนวนมากแล้วค่อยยกเลิกบัตรหนีไป VPS เป็นการลงทุนระยะยาว จึงย้ายออกยากกว่า และแม้ผู้ใช้บางคนเบี้ยวค่าบริการหนึ่งเดือน ต้นทุนของผู้ให้บริการก็ค่อนข้างต่ำกว่า
    • กำลังพิจารณา Bifrost อยู่ เลยสงสัยว่าทำไมถึงเลือกใช้ LLM gateway
      OpenRouter มีโมเดลแทบทุกตัวตั้งแต่วันเปิดตัว แต่ข้อดีของ Bifrost คือถ้าภายหลังย้ายออกจาก OpenRouter ก็ไม่ต้องไปแตะส่วนอื่นของสแต็กเทคโนโลยี หากการโฮสต์เองทำได้จริง ก็จะลดการพึ่งพา OpenAI·Anthropic·OpenRouter และลดความเสี่ยงที่โมเดลที่พึ่งอยู่จะถูกยกเลิกกะทันหัน
    • นอกจากค่าธรรมเนียมเพิ่มแล้ว ไม่ชอบอะไรในบริการของ OpenRouter

  • เป็นสถานการณ์ที่บริษัทโฮสต์โมเดลเปิดออกมาบอกว่า โมเดลเปิดยอดเยี่ยม

    • พวกเขาเปิดเผยวิธีการและผลลัพธ์ และทำให้ได้รู้จุดแข็งจุดอ่อนเชิงเปรียบเทียบของ Kimi กับ Fable ที่ไม่เคยเห็นจากที่อื่น การทำธุรกิจโฮสต์โมเดลไม่ได้ทำให้หมดสิทธิ์แชร์ผลลัพธ์
    • Fireworks ไม่ได้โฮสต์เฉพาะโมเดลแบบ open weights และการที่ข่าวใหญ่สามารถดึงลูกค้าใหม่ได้ ก็ไม่ได้แปลว่าเนื้อหานั้นเป็นเท็จ
    • คนที่เคยลองใช้เองจะรู้ว่าการประเมินของพวกเขาเป็นความจริง

  • ตามที่อธิบายไว้ในบทความ กำลังมองหา เครื่องมือ routing ที่ใช้ร่วมกับ Claude Code ได้ หรือแพลตฟอร์ม routing อื่น ๆ ที่ดี ทราบอยู่แล้วว่า router ในบทความนี้เป็นแบบ oracle

    • https://github.com/code-yeongyu/oh-my-openagent นำ oracle pattern จากต้นฉบับไปใช้งานครอบคลุม 11 บทบาท
      แต่ละบทบาทมีการจัดอันดับ LLM ที่แนะนำจากหลายผู้ให้บริการ เช่น ใช้ Sisyphus (claude-opus-4-8 / kimi-k3 / glm-5) เป็น orchestrator หลัก