any-llm - Giao diện duy nhất cho nhiều nhà cung cấp LLM

 (github.com/mozilla-ai)
7 điểm bởi xguru 2025-07-25 | 3 bình luận | Chia sẻ qua WhatsApp
  • Thư viện Python do nhóm Mozilla AI tạo ra, cho phép sử dụng hơn 20 nhà cung cấp LLM bằng một hàm duy nhất
    • Khi thay đổi giữa các mô hình như OpenAI, Anthropic, Google, Mistral, AWS Bedrock, chỉ cần đổi provider_id/model_id
  • Ưu tiên sử dụng SDK chính thức của nhà cung cấp để giảm thiểu vấn đề tương thích; không cần cài riêng máy chủ proxy/gateway nên có thể dùng ngay sau khi cài bằng pip
  • Thân thiện với nhà phát triển với gợi ý kiểu đầy đủ trong IDE, xử lý ngoại lệ trực quan, ngoại lệ tùy chỉnh, tài liệu và hướng dẫn nhanh
  • Với router gọn nhẹ, thư viện không phụ thuộc framework và không cần máy chủ proxy/gateway riêng (chỉ cần API Key là dùng ngay)
  • Giải quyết các vấn đề của những giải pháp hiện có và đang được bảo trì tích cực: đã được dùng trong sản phẩm thực tế như any-agent của Mozilla
    • LiteLLM: tự triển khai thay vì dùng SDK chính thức → có lo ngại về tương thích/lỗi
    • AISuite: cấu trúc mô-đun nhưng còn thiếu sót về quản lý và typing
    • Phụ thuộc framework: lại tiếp tục bị phân mảnh theo từng dự án
    • Chỉ dành cho proxy: cần máy chủ riêng, làm tăng độ phức tạp

Tài liệu liên quan

Bài viết liên quan

3 bình luận

 
kaydash 2025-07-26

Chắc sẽ phải quản lý key theo từng nhà cung cấp LLM.
 
GN⁺ 2025-07-25
Ý kiến trên Hacker News
  • Tôi không nhất thiết cho rằng việc LiteLLM tự triển khai giao diện nhà cung cấp thay vì dùng SDK chính thức là một vấn đề
    Với API văn bản, tôi chưa gặp vấn đề tương thích lớn nào, và tôi hiểu rằng nếu muốn chuẩn hóa nhiều API khác nhau thì phải tự triển khai giao diện riêng
    Điều này là bắt buộc nếu muốn tạo một router cụ thể
    • Tôi có cảm giác LiteLLM thực ra chẳng có phần nào thực sự nhẹ (lite)
      Tôi đã thử dùng như một thư viện, nhưng cuối cùng chuyển sang llm của Simon. Xin cảm ơn Simon
    • Với các cách dùng tiêu chuẩn như text completion thì cả hai cách đều hoạt động tốt
      Sự khác biệt lộ rõ hơn ở các điều kiện biên như hành vi streaming, xử lý timeout hay bổ sung tính năng mới
      Bên tôi cũng tự dựng lại giao diện để chuẩn hóa API, nên việc có dùng SDK hay không chỉ là khác nhau ở chỗ chia layer như thế nào
      Việc chọn SDK chủ yếu là vì ưu tiên bảo trì, chứ không phải do cách tiếp cận của LiteLLM có khuyết điểm cốt lõi nào
    • Ngay cả SDK chính thức cũng đôi khi có vấn đề phụ thuộc
      SDK của Together từng kéo theo phụ thuộc Apache Arrow nặng tới 60MB, và chúng tôi đã phải tự vá để biến nó thành tùy chọn
      Nếu nó cố định cứng phiên bản phụ thuộc thì có thể xung đột với dự án của tôi
      Tôi nghĩ chỉ dùng OpenAPI/REST còn tốt hơn là dùng một thư viện kéo theo quá nhiều phụ thuộc
    • Nhìn chung LiteLLM cũng đã tích lũy khá nhiều kinh nghiệm thực chiến
      Chỉ dùng SDK chính thức cũng không thể giải quyết mọi vấn đề tương thích, và any_llm rốt cuộc vẫn phải trực tiếp duy trì tương thích với SDK chính thức
      Khó mà nói rõ ràng cách nào vượt trội hơn
    • Cá nhân tôi đang dùng Litellm như một AI gateway
      Từ góc nhìn người dùng, proxy có dùng SDK chính thức hay không không tạo khác biệt trong sử dụng thực tế
      Với người phát triển proxy thì có thể có lợi ích
      Ví dụ gần đây Litellm từng gặp vấn đề khi xử lý Deepseek Reasoning, và phần reasoning đã từng bị thiếu trong cả phản hồi đồng bộ lẫn streaming
  • Bài blog nói LiteLLM nổi tiếng vì hỗ trợ nhiều nhà cung cấp LLM, nhưng thực tế lại chỉ trích rằng “nó không dùng SDK chính thức mà tự triển khai nên có thể gây ra vấn đề tương thích”
    Theo trải nghiệm của tôi thì LiteLLM hoạt động thực sự rất vững
    Các nhà cung cấp thường thông báo trước rất rõ khi có thay đổi API, và LiteLLM chưa từng gặp rắc rối vì chuyện đó
    Những nhược điểm giả định mang tính tiêu cực quanh LLM chỉ xuất hiện trong bài viết này
    Bài còn nhắc tới OpenRouter và Portkey như giải pháp proxy/gateway, nhưng thực tế OpenRouter không yêu cầu người dùng tự dựng server mà chỉ cần gọi API trực tiếp tới endpoint là được
    Bài này đã hiểu nhầm OpenRouter thành một proxy tự host
    Ngoài ra, AISuite là sản phẩm do Andrew NG tạo ra, nhưng blog lại viết rằng nó “không còn được bảo trì từ sau tháng 12/2024”, trong khi thực tế chỉ là không có release tag; các dự án cộng đồng nhỏ đôi khi vốn không hay gắn tag
    Tôi thấy việc đăng lên blog mà không kiểm chứng sự thật ở những chỗ như vậy là có vấn đề
    Nếu không mang thương hiệu Mozilla thì có lẽ tôi đã tưởng đó là lừa đảo hoặc mã độc
    Cái tên này cũng quá giống Anything-LLM nên càng dễ gây nhầm lẫn
  • Tôi khá kỳ vọng vào dự án any-llm mới này
    Đến giờ tôi vẫn dùng LiteLLM, nhưng nhìn vào triển khai bên trong thì nó rất phức tạp và có nhiều vấn đề
    Ví dụ, trong vài tháng gần đây Structured Output của mục Ollama đã bị hỏng hoàn toàn mà vẫn bị bỏ mặc, còn tài liệu thì hoàn toàn chưa được sắp xếp lại
  • Dự án trông khá hay nên tôi thấy hứng thú
    Chắc họ chọn Python vì phần lớn SDK đều xoay quanh Python
    Nhưng tôi nghĩ nếu nó ở dạng có thể chuyển sang nhiều ngôn ngữ mà không cần interpreter thì sẽ thực sự mang tính cách mạng
    • Đây là câu hỏi cốt lõi. Nhiều công cụ đang cố giải quyết vấn đề ở cấp hệ thống (chạy model xuyên ngôn ngữ) ở layer ứng dụng (thư viện Python)
      Muốn tạo ra một giải pháp thực sự phổ quát thì cần tách hoàn toàn runtime của model khỏi ngôn ngữ, và đó là bài toán khó hơn nhiều nhưng cũng là một bước tiến lớn
    • Với JS/TS thì đã có Vercel AISDK, với C++ có ai-sdk-cpp của ClickHouse, với Flutter/ReactNative/Kotlin có Cactus; tức là đã có SDK dùng được ở nhiều ngôn ngữ. Mục tiêu khá giống dự án này
    • Chúng tôi không làm SDK mà tự xây một gateway dạng dịch vụ. Tham khảo: dự án Portkey-AI Gateway
  • Tôi tò mò không biết nó có điểm khác biệt gì so với dự án llm của SimonW
    • Dự án của SimonW chủ yếu hỗ trợ OpenAI và các model tương thích, nên ví dụ nếu muốn dùng model như Amazon Bedrock thì bạn phải tự triển khai *gateway/proxy bổ sung*
      Dự án phía Mozilla (bao gồm cả LiteLLM) có thế mạnh là đã hỗ trợ sẵn nhiều giao diện nên có thể dùng nhiều model ngay lập tức
      Có thể kết nối trực tiếp với nhiều LLM Provider mà không cần server proxy/gateway riêng. Còn so với LiteLLM thì tôi chưa có đủ trải nghiệm để nói rõ
  • Tôi cũng đang làm một dự án mã nguồn mở layer trừu tượng hóa LLM cho Python
    Tôi phát triển nó vì cần cho công việc nghiên cứu của mình
    Tôi lấy ý tưởng từ các dự án sẵn có rồi làm nó cho mục đích tổng quát hơn
    https://github.com/proxai/proxai
    https://proxai.co/
  • Tôi thấy thời điểm này thật kỳ lạ
    Gần đây tôi cũng vừa phát hành một layer trừu tượng hóa LLM tương tự
    Có thể dùng dễ dàng qua pip install, và tôi tập trung vào khả năng tương thích với Langchain để dễ thay thế trong hệ thống hiện có
    Ngoài ra còn hỗ trợ tự động failover qua nhà cung cấp ảo khi vượt quá Rate Limit
  • Gần đây đang xuất hiện nhiều lựa chọn cho layer gateway/proxy LLM như LiteLLM, OpenRouter, Arch, any-llm. Đến mức này rồi có lẽ tất cả chúng ta nên đi tìm một vấn đề mới để giải quyết
    • Tôi nghĩ LiteLLM hơi phức tạp. Dùng nhanh trong dự án cá nhân bằng container Docker thì có thể ổn, nhưng để dùng production thực tế thì tôi không thật sự hài lòng
    • Dù 80% nhà cung cấp model hỗ trợ endpoint tương thích OpenAI, vẫn có đủ loại giải pháp khác nhau xuất hiện
    • Tôi cũng muốn giới thiệu Portkey. Có thể dùng bằng JS và mã nguồn mở
    • Chúng tôi đang áp dụng model routing cho nghiên cứu học thuật và chatbot PDF. Rất muốn nghe ý kiến
  • Tôi nghĩ các giải pháp kiểu này rất cần Docker image. Hình như họ không nhắc đến Docker, và tôi muốn tránh xung đột giữa pip hay phiên bản Python
  • Tôi vẫn đang dùng Litellm Proxy bằng Docker ngay cả trong môi trường phát triển
    Tính năng Usage/Logs giúp trực quan hóa mức sử dụng LLM thực tế, còn tính năng Cache cũng rất hữu ích để giảm chi phí khi test lặp lại nhiều lần
 
egirlasm 2025-07-26

Cảm ơn bài viết hay. Đúng lúc hôm nay tôi đang refactor lần thứ 27 đây.
Ban đầu làm bằng C++, rồi sang javascript, giờ lại đến rust...