any-llm - 多様なLLMプロバイダー向けの単一インターフェース

 (github.com/mozilla-ai)
7 ポイント 投稿者 xguru 2025-07-25 | 3件のコメント | WhatsAppで共有
  • Mozilla AIチームが開発した、20以上のLLMプロバイダーを1つの関数で利用できるPythonライブラリ
    • OpenAI、Anthropic、Google、Mistral、AWS Bedrock などのモデルを切り替える際は provider_id/model_id だけを変更すればよい
  • 公式プロバイダーSDKを優先的に活用して互換性の問題を最小限に抑え、プロキシ/ゲートウェイサーバーを別途インストールする必要がなく、pipでインストール後すぐに使用できる
  • 開発者フレンドリーな設計で、完全なIDE型ヒント、直感的な例外処理、カスタム例外、ドキュメントとクイックガイドを提供
  • 軽量ルーターによりフレームワーク非依存で、別途プロキシ/ゲートウェイサーバー不要（API Keyがあればすぐに使える）
  • 既存ソリューションの問題を解決し、アクティブにメンテナンスが進められている：Mozilla の any-agent など実際の製品で利用中
    • LiteLLM: 公式SDKではなく独自実装 → 互換性やバグの懸念がある
    • AISuite: モジュラー構造だが管理や型付けが不十分
    • フレームワーク依存型: プロジェクトごとに再び断片化する
    • プロキシ専用: 別途サーバーが必要で、複雑さが増す

関連ドキュメント

関連記事

3件のコメント

 
kaydash 2025-07-26

LLMプロバイダーごとにキーを管理しないといけないはず。
 
GN⁺ 2025-07-25
Hacker Newsのコメント
  • LiteLLMが公式SDKではなくプロバイダーインターフェースを直接実装しているからといって、それが必ずしも問題だとは思わない
    テキストAPIでは大きな互換性の問題を経験したことはなく、さまざまなAPIを標準化するには独自にインターフェースを実装する必要があるのは理解できる
    特定のルーターを作るにはこのプロセスが不可欠だ
    • LiteLLMには実際のところ**軽量(lite)**な部分がないように感じる
      試しにライブラリとして使ってみたが、最終的にはSimonのllmに移行した。Simonに感謝したい
    • テキスト補完のような標準的な用途では、どちらの方式もうまく動く
      ストリーミングの挙動やタイムアウト処理、新機能の導入といった境界条件で違いがより表れやすい
      こちらでもAPI正規化のためにインターフェースを作り直しているが、SDKを使うかどうかはどこでレイヤーを分けるかの違いにすぎない
      SDKを採用するのは主に保守性の好みの問題であり、LiteLLMのアプローチに根本的な欠陥があるからではない
    • 公式SDKでも依存関係の問題が起きることがある
      TogetherのSDKにはApache Arrowという60MBの依存が含まれていたことがあり、これを自分でパッチしてオプション化した
      依存バージョンを強制的に固定されると、自分のプロジェクトと衝突する可能性がある
      多くの依存関係を引き込むライブラリより、OpenAPI/RESTだけを使う方がよいと思っている
    • LiteLLMも全体としてかなり実戦経験を積んでいる
      公式SDKを使うだけですべての互換性問題が解決するわけではなく、any_llmも結局は公式SDKとの直接的な互換性維持作業が必要になる
      どちらの方式がより優れているかを明確に言うのは難しい
    • 個人的にはLiteLLMをAIゲートウェイとして使っている
      ユーザーの立場では、プロキシが公式SDKを使っているかどうかで実運用上の違いはない
      ただし、プロキシ開発者には利点があるかもしれない
      たとえば最近、LiteLLMではDeepseek Reasoningの処理で問題があり、同期/ストリーミング応答の両方でreasoning部分が欠落していたことがあった
  • ブログ記事では、LiteLLMは多様なLLMプロバイダーのサポートで人気だと言及しつつ、実際には「公式SDKを使わずに独自実装しているため互換性問題を起こしうる」と批判している
    私の経験では、LiteLLMは実際には非常に堅牢に動作する
    プロバイダーはAPI変更がある場合、事前告知をきちんとしてくれるし、LiteLLMが原因で問題になったことはない
    LLMに関する否定的な仮想上の欠点は、この文章でしか見かけない
    プロキシ/ゲートウェイソリューションとしてOpenRouterやPortkeyの話もしていたが、実際にはOpenRouterはユーザーが自分でサーバーを立てる必要がなく、エンドポイントに直接APIコールするだけでよい
    この記事ではOpenRouterをセルフホスト型プロキシと誤認している
    さらにAISuiteはAndrew NGが作った製品だが、ブログは「2024年12月以降メンテナンスされていない」と書いていたものの、実際にはリリースタグがないだけで、小規模なコミュニティープロジェクトではタグ付けをあまりしないこともある
    こうした点をファクトチェックせずにブログに載せるのは問題だと感じた
    Mozillaブランドでなければ、詐欺やマルウェアだと誤解したかもしれない
    名前もAnything-LLMとあまりに似ていて混乱する
  • 新しいany-llmプロジェクトには期待している
    これまでLiteLLMを使ってきたが、実際の内部実装を見ると非常に複雑で問題が多かった
    例を挙げると、ここ数か月のあいだOllama項目のStructured Outputが完全に壊れたまま放置されていたし、ドキュメントもまったく整理されていなかった
  • プロジェクトは格好よく見えて興味深い
    Pythonを選んだ理由は、おそらく大半のSDKがPythonベースだからだろう
    ただ、インタープリターなしで複数言語に移植できる形だったなら、本当に革新的だったと思う
    • これが核心的な問いだ。多くのツールはシステムレベルの問題（クロス言語のモデル実行）をアプリケーションレイヤー（Pythonライブラリ）で解決しようとしている
      本当に普遍的なソリューションを作るには、モデルのランタイムと言語を完全に分離する必要があり、それははるかに難しい問題だが大きな前進でもある
    • JS/TS向けにはVercel AISDKがあり、C++向けにはClickHouse ai-sdk-cpp、Flutter/ReactNative/Kotlin向けにはCactusなど、すでに複数言語で使えるSDKが存在している。このプロジェクトと目的は似ている
    • 私たちはSDKではなく、サービス型ゲートウェイを自作した。参考: Portkey-AI Gatewayプロジェクト
  • 既存のSimonWのllmプロジェクトとどういう差別化ポイントがあるのか気になる
    • SimonWのプロジェクトはOpenAIおよび互換モデルのサポートが中心で、たとえばAmazon Bedrockのようなモデルを使うには**追加のゲートウェイ/プロキシ** を自分でデプロイする必要がある
      Mozilla側のプロジェクト（LiteLLMを含む）はすでに多様なインターフェースをサポートしているため、すぐに複数のモデルを使える点が強みだ
      別途プロキシ/ゲートウェイサーバーなしで、そのまま複数のLLM Providerに接続できる。LiteLLMとの比較については経験不足でよく分からない
  • 私もPython向けのLLM抽象化レイヤーのオープンソースプロジェクトを作っている
    研究職で必要になって開発し始めた
    既存プロジェクトから着想を得て、より汎用的な用途向けに作った
    https://github.com/proxai/proxai
    https://proxai.co/
  • 本当にタイミングが面白いと感じる
    私も最近、似たような**LLM抽象化レイヤー** を公開した
    pip installで簡単に使えて、Langchain互換性を重視しているので既存システムにも容易に差し替えられる
    さらに、Rate Limit超過時には仮想プロバイダー経由の自動フェイルオーバーも可能だ
  • 最近はLLMゲートウェイ/プロキシレイヤーとしてLiteLLM、OpenRouter、Arch、any-llmなどさまざまな選択肢が出てきている。ここまで来ると、みんなで新しい問題を探すべきなのかもしれない
    • LiteLLMは少し複雑すぎると思う。個人プロジェクトでDockerコンテナとして簡単に使うには悪くないが、本番運用では満足していない
    • モデルプロバイダーの80%がOpenAI互換エンドポイントをサポートしているにもかかわらず、さまざまなソリューションが登場している
    • Portkeyも紹介したい。JSかつオープンソースで活用できる
    • 私たちはモデルルーティングを学術研究やPDFチャットボット分野に適用している。意見を聞きたい
  • こうしたソリューションにはDockerイメージが必須だと思う。Dockerへの言及がなかった気がするが、pipやPythonバージョンの衝突を避けたいからだ
  • 私は開発環境でもLiteLLM ProxyをDockerで継続的に使っている
    Usage/Logs機能で実際のLLM使用量を可視化できるし、Cache機能によって繰り返しテスト時のコスト削減にも大いに役立っている
 
egirlasm 2025-07-26

良い文章をありがとうございます。ちょうど今日、27回目のリファクタリングをしていたところなんですよね。
C++でやっていて、javascriptでやって、今度はまた rust で…