LiteLLM เผชิญกับคำวิจารณ์ที่เพิ่มขึ้น ขณะที่ Python Library ใหม่ any-llm เกิดขึ้นเป็นทางเลือก

ระบบนิเวศ Python สำหรับการจัดการผู้ให้บริการโมเดลภาษาหลายรายกำลังเข้าสู่ช่วงที่ร้อนแรงด้วยการเปิดตัว any-llm ซึ่งเป็น library ใหม่ที่วางตำแหน่งตัวเองเป็นทางเลือกที่สะอาดกว่า LiteLLM ที่ใช้กันอย่างแพร่หลาย การเปิดตัวนี้ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนเกี่ยวกับแนวทางที่ดีที่สุดสำหรับการจัดการผู้ให้บริการโมเดล AI ต่างๆ ในสภาพแวดล้อมการใช้งานจริง

คุณสมบัติหลักของ any-llm :

• อินเทอร์เฟซแบบรวมศูนย์สำหรับผู้ให้บริการ LLM หลายราย
• รองรับ type hints แบบเต็มรูปแบบสำหรับการสนับสนุน IDE
• ใช้ SDK อย่างเป็นทางการของผู้ให้บริการเมื่อมีให้ใช้งาน
• การออกแบบที่ไม่ขึ้นกับเฟรมเวิร์กใดเฟรมเวิร์กหนึ่ง
• ไม่จำเป็นต้องใช้เซิร์ฟเวอร์พร็อกซี
• ต้องการ Python 3.11 ขึ้นไป
• การติดตั้ง: pip install 'any-llm-sdk[mistral,ollama]'

LiteLLM ถูกวิจารณ์เรื่องคุณภาพโค้ดและปัญหาการบำรุงรักษา

นักพัฒนาในชุมชนได้แสดงความกังวลอย่างจริงจังเกี่ยวกับสถาปัตยกรรมภายในและความน่าเชื่อถือของ LiteLLM ผู้ใช้หลายรายรายงานว่าพบฟีเจอร์ที่เสีย โดยเฉพาะกับ structured outputs สำหรับ Ollama ที่ไม่สามารถใช้งานได้เป็นเวลาหลายเดือน คำวิจารณ์ขยายไปไกลกว่าการทำงานไปถึงการจัดระเบียบโค้ด โดยนักพัฒนาชี้ไปที่รูปแบบการออกแบบที่มีปัญหา รวมถึงไฟล์ utility ขนาดใหญ่กว่า 7,000 บรรทัดที่ทำให้การบำรุงรักษาเป็นเรื่องยาก

ข้อร้องเรียนไม่ได้เป็นเพียงเรื่องโครงสร้างโค้ดเท่านั้น ผู้ใช้อธิบาย LiteLLM ว่าเป็นความยุ่งเหยิงมหาศาลเมื่อคุณมองเข้าไปใต้ฝากระโปรง และอ้างถึงปัญหาเกี่ยวกับคุณภาพเอกสารและแนวทางการพัฒนาแบบทีละขั้นที่ไม่ให้ความสำคัญกับความเสถียร การประเมินที่รุนแรงเป็นพิเศษครั้งหนึ่งเรียกมันว่า โค้ดที่แย่ที่สุดที่ฉันเคยอ่านในชีวิต ซึ่งเน้นย้ำถึงความหงุดหงิดที่เพิ่มขึ้นในชุมชนนักพัฒนา

ความแตกแยกทางปรัชญาเทคนิค: การรวม SDK เทียบกับการสร้าง API ใหม่

การถกเถียงทางเทคนิคหลักมุ่งเน้นไปที่สองแนวทางที่แตกต่างกันสำหรับการรวมผู้ให้บริการ LiteLLM สร้างอินเทอร์เฟซของผู้ให้บริการใหม่ตั้งแต่เริ่มต้นเพื่อสร้าง API ที่เป็นหนึ่งเดียว ในขณะที่ any-llm ใช้ประโยชน์จาก SDK อย่างเป็นทางการของผู้ให้บริการทุกที่ที่เป็นไปได้ ความแตกต่างพื้นฐานนี้มีผลกระทบในทางปฏิบัติต่อความเข้ากันได้และการบำรุงรักษา

ผู้สนับสนุนแนวทาง SDK โต้แย้งว่ามันลดภาระการบำรุงรักษาและรับประกันความเข้ากันได้ที่ดีกว่า เนื่องจากผู้ให้บริการบำรุงรักษา SDK ของตัวเองได้อย่างน่าเชื่อถือมากกว่าที่บุคคลที่สามสามารถสร้าง API ของพวกเขาใหม่ได้ พวกเขายังได้รับฟีเจอร์ที่ผู้ให้บริการนำมาใช้ เช่น การลองใหม่และการจัดการการรับรองความถูกต้องโดยไม่เสียค่าใช้จ่าย อย่างไรก็ตาม นักวิจารณ์ชี้ให้เห็นว่าการใช้ SDK อย่างเป็นทางการสามารถนำมาซึ่งการบวมของ dependency และความขัดแย้งของเวอร์ชัน โดย SDK บางตัวรวมถึง dependency ขนาดใหญ่ที่ไม่จำเป็น เช่น Apache Arrow

การเปรียบเทียบด้านเทคนิคระหว่าง LiteLLM กับ any-llm:

ความกังวลเรื่องความพร้อมสำหรับการใช้งานจริงขับเคลื่อนการค้นหาทางเลือก

การอภิปรายเผยให้เห็นความกังวลอย่างมากเกี่ยวกับการใช้ LiteLLM ในสภาพแวดล้อมการใช้งานจริง แม้ว่านักพัฒนาหลายคนจะพบว่ามันยอมรับได้สำหรับการพัฒนาและโปรเจ็กต์ส่วนตัว แต่สมาชิกชุมชนหลายคนแนะนำอย่างชัดเจนไม่ให้ใช้งานในการผลิตเนื่องจากปัญหาความน่าเชื่อถือและการปรับเปลี่ยนพฤติกรรมที่คาดเดาไม่ได้

LiteLLM ได้รับการทดสอบในสนามรบมากพอสมควรในจุดนี้ แสดงถึงค่ายหนึ่ง ในขณะที่คนอื่นๆ โต้แย้งว่าการได้รับการทดสอบในสนามรบไม่ได้ชดเชยปัญหาสถาปัตยกรรมพื้นฐาน

ช่องว่างความพร้อมสำหรับการใช้งานจริงนี้ได้สร้างความต้องการทางเลือกที่เชื่อถือได้มากกว่า โดย any-llm วางตำแหน่งตัวเองเป็นโซลูชันที่ได้รับการสนับสนุนจากการใช้งานจริงของ Mozilla.ai ซึ่งบ่งบอกถึงความเสถียรระดับองค์กรและความมุ่งมั่นในการบำรุงรักษาอย่างต่อเนื่อง

ตลาดที่แออัดสะท้อนถึงความต้องการที่เพิ่มขึ้นสำหรับการสรุป LLM

การเกิดขึ้นของ any-llm เพิ่มเข้าไปในสนามเครื่องมือสรุป LLM ที่แออัดมากขึ้น รวมถึง OpenRouter, Portkey และโซลูชันเฉพาะภาษาต่างๆ การแพร่กระจายนี้สะท้อนถึงความท้าทายที่แท้จริงที่นักพัฒนาเผชิญในการจัดการผู้ให้บริการ AI หลายรายในขณะที่ภูมิทัศน์ยังคงแตกแยกแม้ว่าผู้ให้บริการหลายรายจะเสนอ endpoint ที่เข้ากันได้กับ OpenAI

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

การอภิปรายของชุมชนบ่งบอกว่าแม้ว่า LiteLLM จะเป็นผู้บุกเบิกในพื้นที่นี้และยังคงใช้กันอย่างแพร่หลาย แต่ความไม่พอใจที่เพิ่มขึ้นเกี่ยวกับคุณภาพการนำไปใช้กำลังสร้างโอกาสให้กับทางเลือกใหม่ที่ออกแบบอย่างระมัดระวังมากกว่า เช่น any-llm ในการได้รับความนิยมในหมู่นักพัฒนาที่ให้ความสำคัญกับคุณภาพโค้ดและความน่าเชื่อถือในการใช้งานจริง

อ้างอิง: any-llm