LLM推論エンジンにModular Platformが選ばれる理由

LLM を自社でホスティングしようと調べ始めると、vLLM、SGLang、TensorRT-LLM、llama.cpp と選択肢が次々に並びます。そこに「Modular Platform」「MAX」「Mojo」という名前が加わったとき、これらを同じ表に並べてよいのか判断に迷った方は少なくないはずです。

比較が難しい理由は、各プロジェクトがカバーしているレイヤーの粒度が揃っていないことにあります。あるものは推論サーバーだけを提供し、あるものはカーネル記述言語だけを提供します。それぞれが「速い」「安い」と主張していても、そもそも比較の土俵が同じでなければ、スループットの数字を横に並べても意思決定の材料にはなりません。

そこで本記事では、GitHub リポジトリ modular/modular が どのレイヤーを、どこまで一体で提供しているのか を分解します。そのうえで、推論サービング層の直接競合である vLLM・SGLang、カーネル／コンパイラ層で重なる Triton・TVM との棲み分けを整理し、最後に採用可否を左右するライセンス条件まで確認します。

なお本記事は、公式ドキュメント・公式サイト・リポジトリの公開情報に基づく整理です。ベンチマークの実測や環境構築は行っておらず、性能に関する数値はすべて出典を明示したうえで「誰の主張か」を区別して記載しています。

Modular Platformとは｜MAXとMojoを1リポジトリに束ねたOSS

modular/modular は、Modular 社が開発する AI 開発・デプロイ基盤「Modular Platform」のオープンソース部分を集約したモノレポです。README では、MAX Framework と Mojo Language を含む統合プラットフォームであると定義されています（modular/modular）。

まず基本的なメタデータを押さえておきます。以下は 2026 年 8 月 30 日時点で GitHub API から取得した値です。

このリポジトリはアーカイブ済みではなく、他リポジトリからのフォークでもありません。取得日の前日にコミットが入っている状態であり、現役で開発が続いている本家リポジトリと判断できます。「数年前に更新が止まったプロジェクトを掴んでしまう」というリスクは、この時点では該当しません。

リポジトリが内包する5つのコンポーネント

Modular Platform を理解するうえで最も重要なのは、このリポジトリが単一のツールではなく、AI 推論スタックの複数レイヤーを縦に束ねている点です。README の「About the repo」では、以下のコンポーネントが列挙されています。

コンパイラから推論サーバーまでが同居している構成は、後述する比較セクションで効いてきます。一般的な推論エンジンはこのうち上位 1〜2 レイヤーのみを提供し、その下のカーネルやコンパイラは既存の CUDA / cuDNN / Triton に依存するためです。

モノレポとしての構成上の特徴

リポジトリ直下のファイル一覧を参照すると、MODULE.bazel / bazelw / BUILD.bazel が置かれており、ビルドシステムに Bazel が採用されていることが分かります。巨大なコンパイラ本体とカーネル群、Python 側のパイプラインを 1 リポジトリで扱うための選択と考えられます。

また AGENTS.md / CLAUDE.md / AI_TOOL_POLICY.md といった、AI コーディング支援の利用を前提としたファイルが同居している点も特徴的です。この AI ツールポリシーについては、コントリビューション体制のセクションで改めて取り上げます。

コンパイラ部分の中身も、ディレクトリ構成から輪郭がつかめます。/KGEN/lib 配下には MojoParser / KGENDialect / KGENToLLVM / ExecutionEngine / Interpreter といったディレクトリが並んでおり、パーサーから MLIR 方言、LLVM への変換、実行エンジンまでが公開されていることが確認できます。

MAXの構成｜OpenAI互換の推論サーバーとモデルパイプライン

MAX は、CPU・GPU・ASIC をまたいだ AI サービングとモデリングを担うフレームワークとして位置づけられています（MAX 公式ドキュメント）。ここが、既存の推論エンジンからの移行コストを見積もるうえで最も重要な層になります。

サービング層｜OpenAI互換APIで受ける

MAX の推論サーバーは OpenAI 互換の API を提供します。公式ドキュメントでは DeepSeek、Gemma、Qwen などのモデルが実装済みとして挙げられています。

クイックスタートでは、モデルのサーブは次のコマンドで行うと案内されています。

max serve --model google/gemma-4-31B-it

（出典: MAX クイックスタート）

起動したサーバーへは、OpenAI の Python クライアントからそのまま接続できます。同じくクイックスタートに掲載されているコードは以下のとおりです。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

completion = client.chat.completions.create(
   model="google/gemma-4-31B-it",
   messages=[
       {
         "role": "user",
         "content": "Who won the world series in 2020?"
       },
   ],
)

print(completion.choices[0].message.content)

（出典: MAX クイックスタート）

移行コストの観点で押さえるべきは、base_url の差し替えだけでクライアント側のコードが再利用できるという構造です。vLLM や SGLang も同様に OpenAI 互換エンドポイントを提供しているため、サービング層の乗り換えコストはこの 3 者間で大きな差が付きにくいと言えます。裏を返せば、選定の決め手はサービング API そのものではなく、その下のレイヤーにあることになります。

モデリング層とグラフコンパイラ

MAX のもう一つの顔が、PyTorch ライクな Python API でカスタムパイプラインを組めるモデリング層です。そしてその下には、ベンダー依存なしに複数ハードウェアへ最適化するグラフコンパイラが置かれています。

公式ドキュメントでは、この構成により PyTorch・CUDA・ROCm を必要とせず、結果としてコンテナサイズの削減と起動の高速化につながると説明されています。推論イメージから CUDA ランタイム一式を外せるかどうかは、コールドスタートが課題になるサーバーレス構成や、大量のノードへ配布するワークロードでは無視できない差になります。

公式サイトでは、性能・コスト面について vLLM 比 2 倍の性能、50〜70% のコスト削減、Time to First Token 500ms 未満といった数値が掲げられています（Modular 公式サイト）。ただしこれらはいずれもベンダー自身が公表している主張であり、条件を揃えた第三者検証の結果ではありません。選定にあたっては、自社のモデル・バッチサイズ・ハードウェア構成で検証したうえで判断する必要があります。

Mojoの役割｜MLIRベースでGPUカーネルをハードウェア非依存に書く

Mojo を「Python の代替となる新言語」として捉えると、学習コストの見積もりを誤りやすくなります。Modular Platform の文脈では、Mojo は MAX のカスタムカーネルを記述するための言語 として位置づけられており、アプリケーションコード全体を書き換えることを前提としていません。

Mojo の中核機能として、公式ドキュメントでは fn と struct、所有権（ownership）、SIMD、コンパイル時メタプログラミング、Python 相互運用、GPU プログラミングが挙げられています（Mojo 公式ドキュメント）。構文は Python に寄せられており、最小のプログラムは次のように書きます。

def main():
    print("Temperature Analyzer")

（出典: Mojo クイックスタート）

ハードウェア非依存が成立する理由は、Mojo が MLIR を基盤にしていることにあります。前述のとおり /KGEN/lib には KGENDialect や KGENToLLVM といった MLIR 方言と LLVM 変換のディレクトリが存在し、単一のカーネル記述から NVIDIA・AMD・Apple Silicon・CPU 向けのコードを生成するという設計が、ディレクトリ構成の面からも裏付けられます。

時系列としては、2026 年 8 月 11 日に Mojo がバージョン 1.0 に到達し、コンパイラとツールチェーンを 2026 年中にオープンソース化する方針が表明されています（Publickey「Pythonライクで高速な『Mojo言語』がバージョン1.0に到達、今後はコンパイラをオープンソー…）。標準ライブラリの OSS 化以降、約 200 名のコントリビューターによる 20 万行を超える変更があったとされています。

ソース公開とコントリビューション受付は別物

ここで誤解しやすいポイントがあります。/KGEN にコンパイラのソースが置かれていることと、そこへの変更を外部から受け付けることは別の話です。README には Mojo コンパイラへのコントリビューションはまだ受け付けていない旨が明記されています。

OSS の健全性を「Issue や PR がどれだけ活発か」で評価する場合、この区別を押さえておかないと判定を誤ります。標準ライブラリやカーネル、モデルアーキテクチャは外部から改善できる一方、コンパイラ本体の改善は Modular 社の内部リソースに依存する、という構造で評価するのが実態に近い見方です。

ドキュメントがAI支援を前提に整備されている

細かい点ですが、Mojo のドキュメントは URL 末尾に .md を付けると Markdown 版が取得でき、全体インデックスとして /llms.txt が用意されています。コーディングエージェントにドキュメントを読ませながら実装を進める運用を想定している場合、この整備状況は地味に効いてきます。日本語の解説記事が少ない技術ほど、一次情報を機械可読な形で取得できることの価値は大きくなります。

vLLM・SGLangとの違い｜LLM推論エンジンとして比較する

ここからが本題です。LLM 推論エンジンとして Modular Platform を評価する場合、直接の比較対象になるのは MAX のサービング層と競合する vLLM・SGLang です。

4リポジトリの実測メタデータ

以下は 2026 年 8 月 30 日時点で GitHub API から取得した値です。

差が出るのは「エコシステム規模」と「縦の一貫性」

この表から読み取れる構造上の差分は、次の 2 点に集約されます。

1 つ目はエコシステム規模です。 vLLM は Stars で見ると Modular Platform の約 3 倍にあたり、対応モデルの追従速度、実運用のノウハウ、トラブルシューティング情報の蓄積量で先行しています。日本語情報の量にも同じ傾向があります。社内に GPU サービングの専任者を置けない体制では、この差は運用工数として跳ね返ってきます。

2 つ目は縦の一貫性です。 vLLM と SGLang はサービング層に閉じており、その下のカーネルは既存の GPU エコシステムに依存します。対して Modular Platform は、カーネル記述言語（Mojo）とグラフコンパイラを自前で持ち、それを 1 リポジトリで縦断しています。この構造が価値になるのは、NVIDIA 以外のアクセラレータへ同一コードベースで展開したい場合や、カーネル層まで踏み込んで自前最適化する余地を持ちたい場合です。

つまり選定は「エコシステム規模を取るか、ハードウェア移植性と最適化の自由度を取るか」というトレードオフとして整理できます。ここが曖昧なまま性能ベンチマークの数字だけを比較しても、結論は出ません。

現時点でvLLM・SGLangを選ぶべきワークロード

公平を期すため、弱点・制約も挙げておきます。オープンソース推論エンジンを比較した第三者記事では、MAX について次の 4 点が指摘されています（Fish Audio「Open-source LLM inference engines compared: SGLa…）。

• 対応モデルアーキテクチャの幅が vLLM・SGLang より狭く、最新・ニッチなモデルでは選択肢が限られます
• 本番環境での実戦投入実績が vLLM より浅く、コミュニティ実装のモデルも少ないとされています
• 性能がハードウェア世代によってばらつきがあり、すべてのハードウェアで最速とは限りません
• 分散 prefill/decode、KV キャッシュ対応ルーティング、マルチモデルオーケストレーション、混在 GPU 群のオートスケールは Modular Cloud 側の提供であり、OSS の Community Edition には含まれません

いずれも第三者記事による指摘であり、リリースの更新によって状況が変わる可能性があります。

これとは別に、公式ドキュメントが明示している制約として LoRA アダプタの適用条件があります（MAX 公式ドキュメント「Using LoRA adapters」）。複数アダプタの同時管理そのものは --max-num-loras で同時管理数を指定でき、対応しています。制約があるのは適用範囲のほうで、対応ベースモデルは Llama 3 系のみ、対応する射影は q_proj / k_proj / v_proj / o_proj に限られます。加えて、既定で有効な prefix caching とは併用できず、--no-enable-prefix-caching による明示的な無効化が必要です。

以上を踏まえると、最新・ニッチなモデルアーキテクチャへの追随速度を最優先する場合、Llama 3 系以外のベースモデルで LoRA アダプタを運用する予定がある場合、prefix caching と LoRA を併用したい場合、あるいは分散 prefill/decode や KV キャッシュ対応ルーティングまで OSS の自ホストだけで賄いたい場合は、現時点では vLLM や SGLang を選ぶ判断のほうが合理的な場面が多くなります。

Triton・TVMとの違い｜カーネル層とコンパイラ層での重なり

サービング層以外にも、Modular Platform と目的が重なるプロジェクトがあります。すでに Triton や TVM を使っているチームにとっては、こちらの比較のほうが実感に近いはずです。

Triton との関係は、Mojo と目的が部分的に重なります。どちらも GPU カーネルを高水準な構文で記述し、ハードウェア向けコードを生成する点は共通です。違いは守備範囲で、Triton は Python 埋め込み DSL として「カーネル記述言語 + コンパイラ」に閉じており、推論サーバーやモデルパイプラインは持ちません。また Mojo は独立した言語として設計されているのに対し、Triton は Python プログラム内に埋め込む DSL であり、設計思想が異なります。すでに Triton でカーネルを書き、サービングは vLLM に任せるという分業が回っているなら、そこに Mojo を持ち込む積極的な理由は小さくなります。

TVM との関係は、複数ハードウェアへ最適化して配布するという狙いが MAX のグラフコンパイラと重なります。ただし TVM は汎用 ML コンパイラであり、LLM サービングや OpenAI 互換 API を主眼としていません。エッジデバイスを含む幅広いターゲットへモデルを配布したいのであれば TVM、LLM 推論サーバーとして一体で動かしたいのであれば MAX、という切り分けになります。

いずれの場合も、乗り換えを検討する価値があるのは「カーネル層とサービング層を別々のツールで管理しているコストが運用上の負担になっているか」が判断の起点になります。単に新しいから、という理由で層をまとめても、得られるのは学習コストだけになりかねません。

ライセンスと商用利用条件｜Apache-2.0とCommunity Licenseの2層構造

技術評価を終えた後に法務レビューで止まる、というのは最も避けたい展開です。Modular Platform のライセンスは 2 層構造になっており、この点を理解しないまま進めると後戻りが発生します。

GitHub API の表示が「NOASSERTION」である理由

まず注意点として、GitHub API で modular/modular のライセンス情報を取得すると、SPDX 識別子は NOASSERTION が返ります。これはライセンスが未設定という意味ではありません。

リポジトリ直下の LICENSE ファイルの冒頭には、このリポジトリが Apache License v2.0 with LLVM Exceptions の下でライセンスされる旨が明記されています。LICENSE が複数のライセンス条文を束ねた複合ファイルになっているため、GitHub 側の自動判定が単一の SPDX 識別子を確定できず NOASSERTION となっている、という構造です。ライセンススキャンツールの出力をそのまま法務に回すと「ライセンス不明」と判定されかねないため、LICENSE ファイルの実体を確認したうえで報告するのが確実です。

2層に分かれる適用範囲

README の License 節では、リポジトリと貢献が Apache License v2.0 with LLVM Exceptions である一方、MAX の利用と配布は別建ての Modular Community License に従うと記載されています。加えて、Hugging Face 等から取得するサードパーティモデルのライセンス確認は利用者の責任である旨も明記されています。

商用利用で確認すべき論点

Community License の条文で、商用利用の判断に関わる論点は次のとおりです。

• CPU および NVIDIA GPU 上での商用本番利用は無償であるという点は、一貫して示されています。
• NVIDIA 以外のアクセラレータについては注意が必要です。 2025 年 4 月の公式ブログ「A New, Simpler License for MAX and Mojo」では、その他のアクセラレータは一定台数までを無償枠とし、超過分はエンタープライズ版が必要と説明されていました。一方で 2026 年 8 月 30 日時点の公式ライセンスページの記載を参照すると、ハードウェア種別による台数上限については当時の説明との差異が見られます。条文は改定され得るため、採用判断の際は必ず公式ライセンスページで最新条文を確認してください。
• MAX をホスト型・マネージド型の AI 学習／推論サービスとして第三者に商用提供する場合は、トレードマーク表示などの追加要件があります。自社プロダクトの内部で推論を回す場合と、推論そのものを商品として外部に提供する場合とで、条件が変わる点に注意が必要です。
• 再配布はオブジェクトコード形式で可能とされる一方、ソース形式での再配布は許可されていません。改変版を配布する場合は、Modular Community License に基づく旨と改変者を示す帰属表示が求められます。
• MAX を再実装・代替するソフトウェアを生成する目的での AI 学習データ利用は禁止されています。MAX を理解したり、その上でアプリケーションを構築したりする目的での AI ツール利用は許可されています。

エディションごとの違いと商用サポートの範囲については、Modular の価格ページに一覧があります。オープンソース版の MAX と Mojo 自体は無償で提供され、マネージドのエンドポイントサービスが有償という区分です。

開発の活発さとコントリビューション体制

メンテナンス状況の健全性は、採用判断の 3 つ目の軸です。

開発の活発さについては、最終更新が 2026 年 8 月 29 日、Forks が 3,125 という実測値が一つの指標になります。前述のとおりアーカイブ済みでもフォークでもなく、本家として継続開発されている状態です。

コントリビューションの受付範囲は、README で以下のように整理されています。

AIツールポリシーが明文化されている

このリポジトリで特徴的なのが、AI 支援によるコントリビューションに関するポリシーが明文化されている点です（AI Tool Use Policy / Contribution Guide）。骨子は次のとおりです。

• AI 支援で作成した変更には Assisted-by: のコミットトレーラーやPR 説明でラベルを付ける
• PR は小さく保つ（AI はコード生成のコストを下げるが、レビューのコストは下げないため）
• PR の説明文は人間自身が書く
• Human-in-the-loop を必須とし、人間のレビューを経ない完全な AI 自動化は現時点では認めない
• 既存のコーディング標準は AI 支援による貢献にも同様に適用される

このポリシーは living document として今後改訂される旨も明記されています。OSS を採用する際、コードの品質管理がどう担保されているかは重要な判断材料です。AI 生成コードの流入をどう扱うかを明文化しているプロジェクトはまだ多くないため、レビュー体制の健全性を測る材料として評価できる部分です。同時に、コントリビューションを検討する側にとっては、事前に期待値が分かるという利点もあります。

採用判断のチェックリスト｜向くケース・向かないケース

ここまでの整理を、判断に使える形にまとめます。以下は「採用すべき／すべきでない」の結論ではなく、自社の要件と突き合わせるためのチェックリストとして使ってください。

右列に該当する項目が多い場合は、現時点では vLLM や SGLang を採用し、Modular Platform は継続ウォッチの対象に留めるという判断が現実的です。逆に左列、特にハードウェア移植性とカーネル層の最適化に該当項目が集中するなら、PoC を組んで自社ワークロードで検証する価値があります。

まとめ｜Modular Platformを評価するときに見る順番

Modular Platform を評価する際は、次の順番で見ていくと判断が早くなります。

1. レイヤー構成を確認する — コンパイラ（/KGEN）、Mojo 標準ライブラリ、MAX カーネル、推論サーバー、モデルパイプラインを 1 リポジトリで縦断していることが最大の構造的特徴です
2. 直接競合との差分を見る — サービング層では vLLM・SGLang と競合します。エコシステム規模では vLLM が先行し、ハードウェア移植性と最適化の自由度では Modular Platform に分があります
3. ライセンス条件を確認する — リポジトリのコードは Apache License v2.0 with LLVM Exceptions、MAX の利用・配布は Modular Community License という 2 層構造です。GitHub API の NOASSERTION 表示に惑わされないようにします
4. コミュニティ体制を見る — 開発は継続しており、コントリビューションの受付範囲と AI ツールポリシーが README とポリシー文書で明示されています

次に読むべき一次情報は、リポジトリの README、MAX 公式ドキュメント、Mojo 公式ドキュメント、そして Modular Community License の 4 点です。特にライセンス条文は改定される可能性があるため、判断のタイミングで最新版を確認することをおすすめします。

LLM 推論基盤の選定や、既存システムへの生成 AI 組み込みについて検討されている場合は、お問い合わせフォームからご相談いただけます。要件が固まる前の技術選定の段階からご相談を承っています。