AIアプリ向けの周辺コードは、便利になるほど太りやすい。ルーティング、proxy、cache、課金計測、各社SDKの差分吸収まで抱え込むと、使いたい人には少し重い。GitHubに公開された kennethwolters/litelm は、その「重さ」を削ること自体を目的にしたプロジェクトだ。元記事は、LiteLLMの機能をかなり絞り込み、どこを残し、どこを捨てたのかをはっきり示している。単なる軽量化の話ではなく、LLM周辺ツールに何を求めるかを問い直す内容でもある。
litelm は、名前の通り LiteLLM に似たAPIを持ちながら、機能をかなり削った実装として紹介されている。説明文では「litellm without the bloat」とあり、LiteLLMの routing と translation を中心に、約2,900行、依存関係は openai と httpx の2つだけだと強調している。LiteLLM側は、複数プロバイダへのLLMルーティングやメッセージ形式の変換を担う一方で、proxy server、cache、cost tracking なども抱えていて、元記事はその規模を「100k+ LOC」と表現している。そこで litelm は、そのうちの call path、つまり model routing、message translation、streaming、tool use、embeddings だけを抜き出した、と説明している。
インストール方法もかなりシンプルだ。基本は pip install litelm で、openai + httpx だけが入る。Anthropic を使うなら litelm[anthropic]、Bedrock なら litelm[bedrock]、全部入りは litelm[all] という構成になっている。使い方も LiteLLM に寄せてあり、litelm.completion("openai/gpt-4o", messages=[...]) のように呼び出す。ストリーミングなら stream=True を付けるし、埋め込みは embedding() を使う。非同期版として acompletion、aembedding、aresponses、atext_completion も用意されている。
興味深いのは、APIの互換性をかなり意識している点だ。元記事では「same function names, same arguments, same response types」と書かれていて、すでに LiteLLM を使っているなら import を litelm に置き換えるだけ、という発想になっている。対応プロバイダも広く、OpenAI、Anthropic、Groq、Mistral、xAI、OpenRouter、Azure、Bedrock、Cloudflare、Together、Fireworks、DeepSeek、Perplexity、DeepInfra、Gemini、Cohere、Ollama、vLLM、LM Studio など、provider/model-name 形式で19のproviderにルーティングできるとしている。OpenAI互換のendpointなら api_base でつなげることもできる。
一方で、切り落としたものも明快だ。LiteLLMにある Router、proxy server、caching、budgeting、cost tracking、token counting、image gen、audio、OCR、fine-tuning、agents、guardrails、scheduler などは入っていない。エラーハンドリングは ContextWindowExceededError、RateLimitError、AuthenticationError のような例外にまとめられる。tool calling の例もあり、function calling を経由して tool_calls を読む流れが示されている。さらに、local server にもつなげる例として vLLM、Ollama、LM Studio が挙がっている。
このリポジトリは透明性も前面に出している。litelm は human-directed, AI-assisted software で、コードの多くは Claude Code と Claude Opus 4.6/4.7 を使って書かれたと明記されている。2026-05-14 以降のコードは Pi 経由で GPT-5.5 を使って書かれたとも説明している。ただし互換性の主張は AI が書いたという事実ではなく、test と maintainer review に基づくとしている。さらに、2026-09-11 の maintainer attestation として、LiteLLM の routing/formatting 変更を 649eb2d から 9a715df2 までレビューし、360の core-path commits を精査したうえで、互換性の穴を test-first で埋めたと記している。ローカルの scoped tests は262件が通り55件がスキップ、45の provider live tests と10の DSPy smoke tests も通過したという。Status には Alpha とあり、262 own tests passing、さらに DSPy の drop-in が7つの実行経路で検証済みとされる。
このリポジトリを見てまず感じるのは、LiteLLMそのものへの批判というより、「ツールはどこまで抱えるべきか」という設計思想の対立だと思う。LLMアプリを作る側にとって、routing と format translation だけ欲しい場面は確かにある。実運用では proxy、cache、cost tracking が役立つことも多いが、最初から全部が載ったライブラリを入れると、依存が増え、挙動の把握も難しくなる。litelm はその不安に真正面から応えていて、必要な人にはかなり魅力的だ。
ただ、軽いことはそのまま正義ではない。ここで捨てられている機能は、使う人にとっては「なくてもいい飾り」ではなく、運用の安全装置でもある。特に token counting や cost tracking、budgeting は、LLM利用が社内で広がるほど無視しづらい。だから litelm は、万能な後継ではなく、「自分で周辺機能を別に持つ前提の人向け」だと見るのが自然だと思う。軽量化の代わりに、運用の責任は呼び出し側へ戻ってくる。
openai と httpx だけで始められる、というのは数字以上に効く。PythonのAI系ライブラリは、便利なラッパーほど依存が雪だるま式に増えがちで、結局「何がどこで動いているのか」が見えにくくなる。litelm のように薄い層へ寄せると、障害時の切り分けがしやすいし、vendor lock-in への警戒も少し和らぐ。少なくとも、どの provider にも同じ入口で投げたいだけなら、こういう割り切りは合理的だ。
一方で、薄い層に価値があるのは、下流でちゃんとテストを持てるチームに限られる面もあると思う。元記事がやたらと tests を強調しているのは偶然ではない。262件の own tests、45件の live provider tests、10件の DSPy smoke tests、さらに upstream の contract tests まで並べているのは、「薄いから軽いです」では済ませず、互換性の担保を証拠として示したいからだろう。軽量なライブラリほど、テストが品質そのものになる。
もうひとつ面白いのは、開発の透明性をかなり前に出している点だ。AI-assisted software であることを隠さず、どの区間をどのツールで書いたかまで書くのは、珍しいというより意識的な態度に見える。AI利用そのものより、「AIが書いたから信用できない」とは単純に言えないよう、互換性の根拠をテストとレビューに置いているのが重要だと思う。実際、ユーザーが知りたいのは生成手段より、動くかどうかだからだ。
この書き方は、今後のOSSの見せ方を少し変えるかもしれない。AIを使うこと自体はもう珍しくないが、開発者が気にしているのは、どこまでを機械化し、どこから人間が責任を持ったかだ。litelm はその境目をかなり率直に書いている。だからこそ、単なる「LiteLLMの軽量版」よりも、AI時代のOSSで何を開示すべきかを示すサンプルとして読める。機能の削減と、説明の過不足のなさ。その両方が、このプロジェクトの性格をよく表していると思う。
参考: GitHub - kennethwolters/litelm: litellm without the bloat
