any-llm - อินเทอร์เฟซเดียวสำหรับผู้ให้บริการ LLM หลากหลายราย

 (github.com/mozilla-ai)
7 คะแนน โดย xguru 2025-07-25 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไลบรารี Python จากทีม Mozilla AI ที่ทำให้สามารถใช้งาน ผู้ให้บริการ LLM มากกว่า 20 ราย ได้ด้วย ฟังก์ชันเดียว
    • เมื่อต้องการสลับโมเดลของ OpenAI, Anthropic, Google, Mistral, AWS Bedrock เป็นต้น ก็เพียงเปลี่ยน provider_id/model_id
  • ให้ความสำคัญกับการใช้ SDK ทางการของผู้ให้บริการก่อน เพื่อ ลดปัญหาความเข้ากันได้ให้เหลือน้อยที่สุด และไม่จำเป็นต้องติดตั้งพร็อกซี/เกตเวย์เซิร์ฟเวอร์แยก ทำให้ ติดตั้งผ่าน pip แล้วใช้งานได้ทันที
  • เป็นมิตรกับนักพัฒนา ด้วย type hints ใน IDE ที่ครบถ้วน การจัดการข้อยกเว้นที่เข้าใจง่าย custom exceptions รวมถึงเอกสารและคู่มือแบบรวดเร็ว
  • มี เราเตอร์น้ำหนักเบา ที่ไม่ผูกกับเฟรมเวิร์ก และ ไม่ต้องใช้พร็อกซี/เกตเวย์เซิร์ฟเวอร์แยก (มีเพียง API Key ก็ใช้งานได้ทันที)
  • แก้ปัญหาของโซลูชันเดิม พร้อมมี การดูแลรักษาอย่างต่อเนื่อง : ถูกใช้งานอยู่ในผลิตภัณฑ์จริงอย่าง any-agent ของ Mozilla
    • LiteLLM: ทำเองโดยไม่ใช้ SDK ทางการ → อาจมีความกังวลเรื่องความเข้ากันได้/บั๊ก
    • AISuite: โครงสร้างแบบโมดูลาร์ แต่การจัดการและการทำไทป์ยังไม่ดีพอ
    • แบบผูกกับเฟรมเวิร์ก: แตกย่อยซ้ำอีกตามแต่ละโปรเจกต์
    • แบบพร็อกซีอย่างเดียว: ต้องมีเซิร์ฟเวอร์แยก เพิ่มความซับซ้อน

เอกสารที่เกี่ยวข้อง

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

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

 
kaydash 2025-07-26

คงต้องจัดการคีย์แยกตามผู้ให้บริการ LLM แต่ละรายสินะ
 
GN⁺ 2025-07-25
ความคิดเห็นบน Hacker News
  • ฉันไม่คิดว่าการที่ LiteLLM ลงมือทำ provider interface เองแทนที่จะใช้ SDK ทางการจะเป็นปัญหาเสมอไป
    สำหรับ text API ฉันไม่เคยเจอ ปัญหาความเข้ากันได้ ใหญ่อะไร และก็เข้าใจได้ว่าถ้าจะทำมาตรฐานให้ API หลายแบบ ต้องลงมือทำ interface เอง
    ถ้าจะสร้างเราเตอร์เฉพาะทาง ขั้นตอนนี้ก็จำเป็น
    • รู้สึกว่าใน LiteLLM ไม่มีส่วนที่ lite จริง ๆ เลย
      เคยลองใช้เป็นไลบรารีแบบทดลอง แต่สุดท้ายก็ย้ายไปใช้ llm ของ Simon แทน ขอขอบคุณ Simon ไว้ตรงนี้
    • สำหรับ การใช้งานมาตรฐาน อย่าง text completion ทั้งสองแนวทางก็ใช้งานได้ดี
      ความต่างจะชัดขึ้นตรง กรณีขอบเขต เช่น พฤติกรรมของ streaming, การจัดการ timeout, หรือการเพิ่มฟีเจอร์ใหม่
      ฝั่งเราก็ทำ interface ขึ้นมาใหม่เพื่อ normalize API เช่นกัน ดังนั้น การใช้ SDK หรือไม่ ก็เป็นแค่เรื่องว่าจะแบ่งเลเยอร์ตรงไหน
      การเลือกใช้ SDK ส่วนใหญ่เป็นความชอบด้านการดูแลรักษามากกว่า ไม่ใช่เพราะแนวทางของ LiteLLM มีข้อบกพร่องพื้นฐาน
    • SDK ทางการเองก็มี ปัญหาเรื่อง dependency ได้เหมือนกัน
      SDK ของ Together เคยพ่วง dependency ขนาด 60MB อย่าง Apache Arrow มาด้วย และฉันก็ต้องแพตช์เองให้เป็นตัวเลือกแทน
      ถ้ามันบังคับตรึงเวอร์ชัน dependency ก็อาจชนกับโปรเจ็กต์ของฉันได้
      ฉันเลยมองว่าการใช้แค่ OpenAPI/REST ดีกว่าไลบรารีที่ลาก dependency มาจำนวนมาก
    • โดยรวมแล้ว LiteLLM ก็มี ประสบการณ์ใช้งานจริงสะสมอยู่มาก
      แค่ใช้ SDK ทางการก็ไม่ได้แปลว่าจะแก้ ปัญหาความเข้ากันได้ ได้หมด และ any_llm เองสุดท้ายก็ยังต้องทำงานรักษาความเข้ากันได้กับ SDK ทางการอยู่ดี
      เลยพูดได้ยากมากว่าวิธีไหนเหนือกว่าอย่างชัดเจน
    • ส่วนตัวฉันใช้ Litellm เป็น AI gateway
      จากมุมผู้ใช้ ไม่ว่าจะใช้ SDK ทางการในพร็อกซีหรือไม่ ประสบการณ์ใช้งานจริงก็แทบไม่ต่างกัน
      แต่อาจมีข้อดีสำหรับฝั่งนักพัฒนาพร็อกซี
      ตัวอย่างเช่น เมื่อไม่นานมานี้ Litellm มีปัญหากับ การจัดการ Deepseek Reasoning และส่วน reasoning เคยหายไปทั้งใน response แบบ synchronous และ streaming
  • ในบล็อกโพสต์บอกว่า LiteLLM ได้รับความนิยมเพราะ รองรับผู้ให้บริการ LLM ได้หลากหลาย แต่ก็วิจารณ์ว่ามัน “ไม่ได้ใช้ SDK ทางการและเขียนเอง จึงอาจทำให้เกิดปัญหาความเข้ากันได้”
    จากประสบการณ์ของฉัน LiteLLM ทำงานได้ เสถียรมากจริง ๆ
    ผู้ให้บริการมัก แจ้งล่วงหน้า ชัดเจนเวลา API จะมีการเปลี่ยนแปลง และฉันก็ไม่เคยเห็น LiteLLM มีปัญหาเพราะเรื่องนี้
    ข้อเสียเชิงสมมติในแง่ลบเกี่ยวกับ LLM พวกนี้เหมือนจะมีอยู่แค่ในบทความนี้
    เขายังพูดถึง OpenRouter กับ Portkey ในฐานะโซลูชันพร็อกซี/เกตเวย์ แต่จริง ๆ แล้ว OpenRouter ไม่ต้องให้ผู้ใช้ตั้งเซิร์ฟเวอร์เอง แค่เรียก API ไปยัง endpoint ได้เลย
    บทความนี้เข้าใจ OpenRouter ผิดว่าเป็น self-hosted proxy
    และ AISuite เป็นผลิตภัณฑ์ของ Andrew NG แต่บล็อกกลับเขียนว่า “ไม่ได้รับการดูแลรักษามาตั้งแต่เดือนธันวาคม 2024” ทั้งที่จริง ๆ แค่อาจไม่มี release tag และโปรเจ็กต์คอมมูนิตี้เล็ก ๆ หลายตัวก็ไม่ได้ทำ tagging กันสม่ำเสมอ
    ฉันรู้สึกว่าการเอาเรื่องแบบนี้ขึ้นบล็อกโดยไม่ ตรวจสอบข้อเท็จจริง เป็นปัญหา
    ถ้าไม่ใช่แบรนด์ Mozilla ฉันคงนึกว่าเป็นของหลอกหรือมัลแวร์ไปแล้ว
    ชื่อก็คล้าย Anything-LLM มากเกินไปจนชวนสับสนด้วย
  • ฉันตั้งตารอโปรเจ็กต์ any-llm ตัวใหม่นี้
    จนถึงตอนนี้ฉัน ใช้ LiteLLM มาตลอด แต่พอดู implementation ภายในจริง ๆ แล้วพบว่ามัน ซับซ้อนมากและมีปัญหาเยอะ
    ตัวอย่างเช่น ช่วงไม่กี่เดือนที่ผ่านมา Structured Output ของส่วน Ollama พังแบบใช้ไม่ได้เลย และก็ถูกปล่อยทิ้งไว้อย่างนั้น แถมเอกสารก็แทบไม่ได้จัดระเบียบเลย
  • โปรเจ็กต์นี้ดูน่าสนใจเพราะทำออกมาได้ดี
    เหตุผลที่เลือก Python น่าจะเป็นเพราะ SDK ส่วนใหญ่ทำบน Python
    แต่ถ้ามันเป็นรูปแบบที่ พอร์ตข้ามหลายภาษาได้โดยไม่ต้องพึ่ง interpreter ก็คงปฏิวัติวงการมาก
    • นี่คือคำถามหลัก หลายเครื่องมือพยายามแก้ ปัญหาระดับระบบ (การรันโมเดลข้ามภาษา) ด้วย เลเยอร์แอปพลิเคชัน (ไลบรารี Python)
      ถ้าจะทำโซลูชันที่เป็นสากลจริง ๆ ก็จำเป็นต้อง แยก runtime ของโมเดลออกจากภาษาให้เด็ดขาด ซึ่งเป็นปัญหาที่ยากกว่ามาก แต่ก็เป็นก้าวสำคัญ
    • ฝั่ง JS/TS มี Vercel AISDK, ฝั่ง C++ มี ClickHouse ai-sdk-cpp, และฝั่ง Flutter/ReactNative/Kotlin ก็มี Cactus อยู่แล้ว จึงมี SDK ที่ใช้ได้ในหลายภาษาและมีเป้าหมายคล้ายกับโปรเจ็กต์นี้
    • พวกเราไม่ได้ทำ SDK แต่ทำ gateway แบบบริการ ขึ้นมาเอง ดูได้ที่โปรเจ็กต์ Portkey-AI Gateway
  • ฉันสงสัยว่ามันต่างจาก โปรเจ็กต์ llm ของ SimonW อย่างไรในแง่ จุดแตกต่าง
    • โปรเจ็กต์ของ SimonW เน้นรองรับ OpenAI และโมเดลที่เข้ากันได้ เป็นหลัก และถ้าจะใช้โมเดลอย่าง Amazon Bedrock ก็ต้อง deploy *gateway/proxy เพิ่มเติม* เอง
      ส่วนโปรเจ็กต์ฝั่ง Mozilla (รวมถึง LiteLLM) มีจุดแข็งตรงที่ รองรับหลาย interface อยู่แล้ว ทำให้ใช้งานหลายโมเดลได้ทันที
      เชื่อมต่อกับผู้ให้บริการ LLM หลายรายได้เลยโดยไม่ต้องมีเซิร์ฟเวอร์พร็อกซี/เกตเวย์แยกต่างหาก ส่วนการเทียบกับ LiteLLM ฉันยังมีประสบการณ์ไม่พอจึงตอบชัด ๆ ไม่ได้
  • ฉันเองก็กำลังทำโปรเจ็กต์โอเพนซอร์ส abstraction layer สำหรับ LLM บน Python
    ฉันพัฒนามันขึ้นมาเพราะจำเป็นต่อการทำงานวิจัย
    ได้แรงบันดาลใจจากโปรเจ็กต์เดิม ๆ แล้วทำให้รองรับ การใช้งานทั่วไปมากขึ้น
    https://github.com/proxai/proxai
    https://proxai.co/
  • รู้สึกว่าจังหวะมันบังเอิญมากจริง ๆ
    ฉันเองก็เพิ่งปล่อย LLM abstraction layer ที่คล้ายกันไปไม่นานนี้
    ใช้งานง่ายผ่าน pip install และออกแบบโดยเน้น ความเข้ากันได้กับ Langchain เพื่อให้แทนที่ในระบบเดิมได้ง่าย
    แถมยังมี automatic failover ผ่าน virtual provider เมื่อเจอการเกิน Rate Limit โดยอัตโนมัติ
  • ช่วงนี้มีตัวเลือกอย่าง LiteLLM, OpenRouter, Arch, any-llm โผล่มาเรื่อย ๆ ในฐานะเลเยอร์เกตเวย์/พร็อกซีสำหรับ LLM ถึงจุดนี้แล้วอาจถึงเวลาที่พวกเราต้องหาปัญหาใหม่มาแก้ร่วมกัน
    • ฉันคิดว่า LiteLLM ค่อนข้างซับซ้อนอยู่บ้าง ถ้าใช้กับโปรเจ็กต์ส่วนตัวแบบง่าย ๆ ผ่าน Docker container ก็โอเค แต่สำหรับ การใช้งาน production จริง ยังไม่น่าพอใจนัก
    • แม้ผู้ให้บริการโมเดลถึง 80% จะรองรับ OpenAI-compatible endpoint แต่ก็ยังมีโซลูชันหลากหลายเกิดขึ้น
    • อยากแนะนำ Portkey ด้วย เพราะใช้ได้ทั้ง JS และโอเพนซอร์ส
    • พวกเรากำลังนำ model routing ไปใช้กับงานวิจัยเชิงวิชาการและด้าน PDF chatbot อยากฟังความเห็นจากคนอื่น
  • ฉันคิดว่าโซลูชันแบบนี้ควรมี Docker image ด้วย ดูเหมือนจะไม่ได้พูดถึง Docker เลย ซึ่งฉันอยากหลีกเลี่ยงปัญหาเวอร์ชันชนกันของ pip หรือ Python
  • แม้แต่ในสภาพแวดล้อมพัฒนา ฉันก็ยังใช้ Litellm Proxy ผ่าน Docker อยู่ตลอด
    ฟีเจอร์ Usage/Logs ช่วยให้มองเห็นการใช้งาน LLM จริงได้ดี และ ฟีเจอร์ Cache ก็ช่วยลดค่าใช้จ่ายเวลาเทสต์ซ้ำได้มาก
 
egirlasm 2025-07-26

ขอบคุณสำหรับบทความดี ๆ ครับ จังหวะเหมาะเลย เพราะวันนี้ผมกำลังรีแฟกเตอร์เป็นรอบที่ 27 พอดี
ทำด้วย C++ อยู่พักหนึ่ง จากนั้นก็ไป JavaScript แล้วตอนนี้ก็มา Rust อีกแล้ว...