any-llm 提供了一个统一的接口，简化了不同大语言模型（LLM）提供商的使用。通过单一函数支持所有提供商，开发者只需更改字符串即可切换模型。它具备完整的类型提示，提升IDE支持，并提供清晰的错误信息。any-llm 利用官方SDK，减少维护负担并确保兼容性，同时保持框架无关性，适用于多种项目。无需代理或网关服务器，直接与LLM提供商通信，且持续维护，确保长期支持。

any-llm：统一接口调用不同LLM提供商

核心特点

any-llm 提供了一个简单、统一的接口，方便开发者调用不同的LLM（大型语言模型）提供商。其主要特点包括：

1. 统一接口：只需一个函数即可调用所有提供商，切换模型仅需更改字符串。
2. 开发者友好：提供完整的类型提示，增强IDE支持，并给出清晰、可操作的错误信息。
3. 利用官方SDK：尽可能使用官方提供的SDK，减少维护负担并确保兼容性。
4. 框架无关性：适用于不同项目和用例，不依赖特定框架。
5. 持续维护：any-llm 已在产品 any-agent 中使用，确保其持续更新和支持。
6. 无需代理或网关服务器：直接与LLM提供商通信，无需额外服务。

开发动机

当前LLM提供商的接口生态系统较为分散，存在以下挑战：

• API标准化问题：虽然OpenAI API已成为LLM接口的事实标准，但不同提供商在参数名称、响应格式和功能集上存在差异，导致需要轻量级封装来统一处理这些差异。
• 现有解决方案的局限性：
  • LiteLLM：虽然流行，但重新实现了提供商接口，而非利用官方SDK，可能导致兼容性问题和意外行为修改。
  • AISuite：提供了模块化设计，但缺乏持续维护、全面测试和现代Python类型标准。
  • 框架特定解决方案：一些代理框架依赖LiteLLM或自行实现提供商集成，导致生态系统碎片化。
  • 代理解决方案：如OpenRouter和Portkey，需要托管代理作为代码与LLM提供商之间的接口。

快速入门

要求

• Python 3.11 或更新版本
• 访问所选LLM提供商的API密钥

安装

在安装时，可以指定要使用的提供商，或选择安装所有支持的提供商。

bash pip install 'any-llm-sdk[mistral,ollama]'

确保为所选提供商设置了相应的API密钥环境变量，或在调用时直接使用api_key参数。

bash export MISTRAL_API_KEY="YOUR_KEY_HERE" # 或 OPENAI_API_KEY 等

基本用法

在调用时，provider_id应根据any-llm支持的提供商ID指定，model_id则直接传递给提供商内部。具体可用的模型ID需参考提供商的文档。

any-llm 旨在简化LLM的调用流程，帮助开发者更高效地集成和使用不同提供商的模型。

评论内容主要围绕LLM（大语言模型）代理工具的使用、优缺点以及相关项目的比较展开。以下是总结：

1. 代理工具的优势：

   • 集中管理与扩展性：代理工具可以集中处理观察性、过滤、缓存和全局速率限制，避免在应用代码中分散实现，提升扩展性。
     引用：
     "a proxy means you offload observability, filtering, caching rules, global rate limiters to a specialized piece of software"
     "You can bounce a single proxy server neatly vs. updating a fleet of your application server"
   • 成本与效率：缓存功能有助于降低重复测试的成本，日志功能则提供了LLM使用的可见性。
     引用：
     "The Caching functionality greatly helps in reducing costs for repetitive testing"
     "the Usage and Logs feature greatly helps in providing visibility into LLM usage"

2. LiteLLM的争议：

   • 兼容性与实现方式：LiteLLM重新实现提供者接口而非使用官方SDK，可能导致兼容性问题，但也有人认为这是为了标准化API的必要之举。
     引用：
     "it reimplements provider interfaces rather than leveraging official SDKs, which can lead to compatibility issues"
     "you -want- to reimplement interfaces because you have to normalize api's"
   • 开发质量与文档问题：LiteLLM的开发迭代较快，但存在代码混乱、文档不完善等问题。
     引用：
     "it’s honestly a huge mess once you peek under the hood"
     "Docs are a hot mess, etc."

3. 其他项目的比较与需求：

   • 语言与跨平台支持：部分用户希望有跨语言的解决方案，而非仅限于Python。
     引用：
     "Why Python? Probably because most of the SDKs are python, but something that could be ported across languages would have been really amazing"
     "Anything like this, but in TypeScript?"
   • 负载均衡与队列管理：有用户提出对Ollama服务器的负载均衡和队列管理的需求。
     引用：
     "I’d like a load balancing reverse proxy that supports queuing requests to multiple Ollama servers"

4. 新项目的发布与竞争：

   • 类似项目的涌现：多个用户分享了他们开发的类似LLM抽象层项目，强调兼容性、自动回退等功能。
     引用：
     "I shipped a similar abstraction for llms a bit over a week ago"
     "I focused on making it Langchain compatible so you could drop it in as a replacement"

5. 对Mozilla-AI的质疑：

   • 品牌借用：有用户质疑Mozilla-AI项目是否借用了Mozilla的品牌声誉。
     引用：
     "Seems like reputation parasitism"