ローカルAI実行がうまくいかない？734の依存パッケージに潜む「見えないキラー」

同じモデル、同じウェイトを使っているのに、ローカルで実行した結果が公式APIとまるで違う。GPUの性能不足でもなければ、モデルが「制限版」にされているわけでもない。最近の調査で、多くの開発者が苦笑いするような事実が明らかになった。ローカルAIデプロイが公式版に劣る原因は、734もの依存パッケージに潜んでいる。各パッケージのバージョン差が、モデルの出力を静かに変えてしまうのだ。つまり、同じモデルを動かしているつもりでも、実際には「同じモデル＋734種類の異なるバージョンの基盤部品」を動かしているのである。

734の部品、どれもがトラブルの種になりうる

この問題を理解するには、AI推論ソフトウェアスタックの全体像を把握する必要がある。

精密機器を想像してほしい。モデルウェイトはコアエンジンだが、エンジンを動かすには燃料系統、電気系統、伝達軸が必要だ。AIデプロイの文脈では、これらがPyTorch、Transformers、Tokenizers、CUDAツールチェーン、各種アクセラレーションライブラリ、そしてそれらが依存するサブ依存パッケージに相当する。幾重にも重なり合い、最終的に734個のPythonパッケージが組み上がる。

これが何を意味するか？734のパッケージそれぞれに独自のバージョン番号があるということだ。パッケージAはパッケージBの≥2.1.0を要求し、パッケージBはパッケージCの<3.0を要求し、パッケージCはパッケージDのあるマイナーバージョンと非互換……これは単に「インストールできるか」の問題ではなく、「インストール後に出力される数値が正しいか」の問題なのである。

別の角度から見れば、これはオープンソースエコシステムにおける古典的な「組み合わせ爆発」だ。734のパッケージがそれぞれ3つの主要バージョンを持つだけで、理論上の組み合わせ数は天文学的な数字になる。公式チームがモデルをリリースする際、彼ら自身が検証した特定のバージョン組み合わせを使用している。一方、あなたがpip installで一括インストールしたものは、まったく異なる組み合わせになっている可能性がある。

実はこの問題は目新しいものではない。Pythonを書いたことのある人なら「依存地獄」を経験したことがあるだろう。プロジェクトAはrequests 2.25を必要とし、プロジェクトBはrequests 2.28を必要とし、一緒にインストールすると競合する。AI推論スタックは、この歴史的なジレンマを100倍に拡大したものと言える。ここでの「競合」はエラーやクラッシュではなく、「正しそうに見えるが実際にはずれている」結果を静かに返してくるのだ。

これこそが最も危険な点である。プログラムがクラッシュすれば修正に向かえるが、数値の微妙なずれは気づけない。ユーザーから「このAI、質問と関係ない答えを返すんだけど」と苦情が来て初めて、長い調査の旅が始まるのである。

ツールは消火活動中、しかし火元は消えていない

コミュニティも手をこまねいているわけではない。

例えばQwen Code（アリババ傘下のQwenチームによるAIコーディング支援ツール）などは、デプロイのハードルを下げようとしている。Qwen Codeは最近、スキルファイル呼び出し機能を導入し、開発者が設定ファイルを通じてツール呼び出しフローを編成できるようにすることで、手動での環境構築の苦痛を軽減しようとしている。また、智譜（Zhipu AI、中国のAIスタートアップ）は2025年8月末にGLMシリーズのモデルウェイトをオープンソース化する際、ローカルデプロイのガイドラインを明確に提供した。

これらは確かに良いことだ。しかし、こうしたツールが解決しているのは「上位レイヤーの呼び出し」の利便性であり、基盤となる依存関係の一貫性という根本問題ではない。たとえるなら、スキルファイル呼び出しは正確なレシピ本を渡すようなものだ。先に塩を入れ、次に砂糖を入れると書いてある。しかし、あなたの塩が粗塩で、砂糖が上白糖だったら？レシピ作成者が使った食材と違えば、最終的な味はやはりずれる。

火元を本当に消すには、推論スタック全体の「バージョン固定」の標準化が必要だ。Dockerコンテナイメージのような「すぐに使える」ソリューションで、734のパッケージのバージョンをすべて凍結・パッケージング・配布するのである。現在コミュニティでもこの取り組みを行っている人たちはいる（各種Dockerfileやconda-lockファイルなど）が、統一された標準にはほど遠い。モデルを変え、GPUを変えるたびに、同じ落とし穴を再び踏むことになるかもしれない。

誰が「わずかな差」のコストを負担するのか？

技術ギークにとって、依存関係の調整は一種の楽しみ（あるいは修行）かもしれない。しかし中小企業にとっては、これは实实在在的な隠れたコストである。

あるシナリオを想像してほしい。カスタマーサービスボットを手がける小規模会社が、コスト削減のためにオープンソースモデルで商用APIを置き換えることにした。エンジニアが2週間かけてローカルデプロイを完了し、テスト結果も悪くない。しかし本番稼働1週間後、顧客から「ボットが時々的外れな答えを返す」という苦情が来る。調査の結果、本番サーバーのある依存パッケージのバージョンがテスト環境とマイナーバージョン1つだけ異なり、トークン化の挙動が微妙に変わり、長い文章の分割方法が変わってモデルの入力がずれていたことが判明する。

この種のバグは再現が極めて難しく、特定も困難だ。修正自体はrequirements.txtの1行を変えるだけかもしれないが、その1行を見つけるのにシニアエンジニアが3日を費やすことになるかもしれない。

こうした隠れたコストが、オープンソースモデルの商用化への信頼を静かに蝕んでいる。経営者の目には「オープンソースモデルは信頼できない」と映り、エンジニアは「信頼できないのはモデルではなくデプロイ環境だ」と知っている。この認識のズレは、技術的問題そのものよりも危険かもしれない。

対照的な例を挙げよう。大手企業には専門のインフラチームが「ゴールデンイメージ」を管理しており、すべてのモデルデプロイは検証済みの同じコンテナイメージから起動され、依存バージョンは完全に固定されている。一方、小規模チームはベアメタルにpip installし、環境はエンジニアの「勘と経験」頼みだ。同じオープンソースモデルでも、大手企業の手では磐石のように安定し、小規模チームの手ではお手上げ状態になる。率直に言えば、差は技術力ではなく、エンジニアリングインフラへの投資額にある。

エコシステムガバナンスの次のステップ

AIオープンソースエコシステムは、Web開発が10年前に通った道をたどり直している。

10年前、フロントエンド開発者も「自分のマシンでは動くのに、あなたのマシンでは動かない」問題に頭を抱えていた。その後、Node Version Managerが登場し、lockfileが登場し、Dockerが登場し、CI/CDパイプラインが登場した。問題は消えなかったが、許容できる範囲に制御された。

AI推論スタックもおそらく同じ道をたどるだろう。考えられる進化の方向としては、公式が検証済みの「ゴールデン依存組み合わせ」イメージを提供する、パッケージマネージャーが数値計算向けの厳密なバージョン制約を導入する、さらには「AI推論環境の一貫性」に特化した商用サービスが登場する、といったものが挙げられる。こうしたインフラが今後1〜2年で成熟すれば、オープンソースモデルのローカルデプロイ体験は飛躍的に向上するだろう。もし遅れれば、「ローカルデプロイは公式に劣る」という状態が普遍的なペインポイントとして残り続ける。

この問題は新たなニッチ市場を生み出す可能性もある。かつてDockerがコンテナオーケストレーション分野（Kubernetes）を生み出し、CI/CDがGitHub ActionsやGitLab CIを生み出したように、「AI推論環境の一貫性」は次のインフラ系スタートアップの方向性になるかもしれない。「ワンクリックで734の依存を固定し、クロスハードウェアプラットフォームで数値の一貫性を保証する」ツールを作った者が、AIデプロイ分野のDockerになる可能性がある。

今日のポイント

ローカルデプロイのAIが公式に劣る主な原因の一つは、734の依存パッケージのバージョン組み合わせの差であり、モデル自体の問題ではない。
ツールレベルの最適化（スキルファイル呼び出しなど）はハードルを下げているが、基盤の依存一貫性の問題は未だ根本的に解決されていない。
中小企業がオープンソースモデルの導入を評価する際は、「環境一貫性のデバッグコスト」を予算に組み込むべきであり、GPUのコストだけを計算してはならない。
一般の開発者へ：オープンソースモデルを実行する前に、公式推奨のDockerイメージやlockfileを探そう。pip installでの直接インストールは避けよう。

共有しやすい一言まとめ： あなたのAIはバカになったわけではない。734の基盤部品が内部で衝突しているのだ——ローカルデプロイ失敗の真相は依存パッケージに隠されている。

質問： オープンソースモデルをローカルデプロイした際、「公式の結果と合わない」という経験はありますか？最終的にどうやって原因を特定しましたか？コメント欄であなたのトラブルシューティング経験をぜひ共有してください。

概念図

実例図