ローカルLLM選定にMagnitudeが選ばれる理由｜Ollamaとの違い

ローカルLLMの導入検討で最初に詰まるのは、インストール手順ではありません。「自分のマシンで実用に足る速度が出るモデルはどれか」という判断です。紹介記事の多くは「まずモデルをpullする」から始まりますが、そのモデル名がどう決まったのかは書かれていないことが少なくありません。

この判断が難しいのには理由があります。GPUのVRAMに収まるかという見積もりに加え、Apple Siliconの統合メモリはOSや他のアプリと同じプールを使うため単純な引き算ができません。量子化のバリアントも複数あり、品質と速度のバランスが取れる組み合わせは一見して分かりません。結果として、数GBのモデルをダウンロードして速度を確かめ、遅ければ削除するという試行の繰り返しになります。

Magnitudeは、この判断そのものを代行しようとするローカルLLM推論エンジンです。マシンの構成をプロファイルし、ダウンロード前に各モデルのトークン生成速度を推定してランク付けし、選んだモデルをそのハードウェア向けにチューニングします。公式サイトのキャッチコピーは「Run the best open models for your machine」で、実行性能そのものよりも「選ぶ」フェーズに重心を置いた設計です。

本記事では、Magnitude 公式サイト・README・公式ドキュメント・リポジトリ構成という公開情報のみに基づき、機能とアーキテクチャ、Ollama・Jan・Lemonadeとの違い、採用判断のチェックポイントを整理します。動作検証やインストールは行っておらず、記述はすべてドキュメントベースです。数値は2026年9月27日時点の公開値です。

ローカルLLM選定でつまずくのは「自分のマシンで何が動くか」

ローカルLLMの実行環境に関する日本語の情報源を横断すると、同じ論点が繰り返し現れます。モデルの重みがVRAMに収まるか、Apple Siliconの統合メモリはどこまでモデルに割り当てられるか、量子化はどのバリアントを選ぶべきか、コンテキスト長を伸ばすとメモリと応答時間はどう変わるか、という4点です。

いずれもパラメータ数だけを見ていては答えが出ません。公式ドキュメントのHardwareページも、パラメータ数ではなく実機の構成を評価してモデルを推奨する（適合判定）という立場を取っています。同ページはメモリと速度のトレードオフとして、モデルサイズと量子化精度がメモリ要求を押し上げること、専用GPU搭載機ではGPUメモリとシステムRAMを互換的に扱えないこと、コンテキストウィンドウを長くするとメモリ需要が増え応答が遅くなることを挙げています。

つまりローカルLLM選定の難所は「実行できるか」ではなく「実行結果が実用的かを事前に見積もれないこと」にあります。

Magnitudeとは：ハードウェア診断から始まるローカルLLM推論エンジン

Magnitudeは、READMEで「あなたがすでに持っているハードウェア向けのオープンソース推論エンジン」と位置づけられています。マシンをプロファイルし、そのマシンに最適なオープンモデルを推奨し、ハードウェアに合わせてチューニングするという3段構えです。対応範囲はApple Silicon・NVIDIA・AMD、そしてGPUを持たないCPUのみのマシンまで含まれます。

READMEのGet startedは、デスクトップアプリをインストールして開く、Discoverで推奨モデルを選んでダウンロードする、Connectionsでエージェントを接続する、という3ステップです。CLIについては「デスクトップアプリにmagnitude CLIが含まれるため別途インストールは不要」と記載されています。

リポジトリの基本情報

公開メタデータは以下の通りです（magnitudedev/magnitude、2026年9月27日時点）。

アーカイブ済みリポジトリやフォーク版では本家との差分を確認する必要がありますが、Magnitudeはいずれにも該当せず、ライセンスもApache-2.0が明示されています。言語構成はTypeScriptが最多で、次にRustが続きます。この構成自体が後述のアーキテクチャを反映しています。

「Magnitude」で検索すると混在する同名プロジェクト

「Magnitude」で日本語検索をすると、2025年に紹介された「AIネイティブなWebアプリテストフレームワーク」としてのMagnitudeの記事も混在します。事実関係を整理すると、現在のmagnitudedev/magnitudeは2026年6月12日に作成された推論エンジンのリポジトリで、同じorgにはmagnitudedev/browser-agent（"Open-source, vision-first browser agent"、2025年3月作成、スター4,131、2026年9月27日時点）が別途公開されています。2025年時点の記事はこちらの系譜にあたります。本記事が扱うのは前者の推論エンジンです。

Magnitudeの中核機能：マシン診断・モデル推奨・自動チューニング

Magnitudeの機能は「マシンを測る」「モデルを推す」「選ばれたモデルを詰める」の3つに分けて理解すると見通しが良くなります。

ハードウェアプロファイリングと適合判定

公式ドキュメントのHardwareページは、対応アクセラレータを次のように整理しています。

• Apple Silicon Mac: MetalによるGPUアクセラレーション（統合メモリ）
• Intel Mac: CPUのみ
• Windows / Linux（x64・ARM64）: CPU、NVIDIA CUDA、Vulkan対応GPU
• NVIDIA GPU: 現行のCUDAビルドはAmpere世代以降を対象としており、それより古いCUDA対応カードは自動的にはサポートされません
• AMD GPU: LinuxとWindowsでVulkan経由。ROCmバックエンドは現時点で提供されていません

統合メモリについては、同ページが次のように述べています。

"Apple Silicon shares memory between the CPU and GPU. That gives the GPU access to a larger memory pool than a typical laptop's dedicated graphics memory, but macOS and other apps use the same pool."

（出典: https://docs.magnitude.dev/hardware ）

32GBのMacであれば32GB分のモデルが載るわけではなく、macOSと他のアプリが同じプールを消費するという前提です。診断後に重いアプリを立ち上げれば利用可能なリソースはその分減るため、推奨結果は固定値ではないという性質を押さえておく必要があります。AMDのROCm前提で環境を組んでいる場合やIntel Macを使っている場合は、この時点で期待値の調整が必要になります。

Discoverによるモデル推奨と4つの評価軸

モデル推奨を担うのがDiscoverです。公式ドキュメントのModelsページによると、Discoverは最大5件の推奨を提示し、Balanced / Fastest / Faster / Smarter / Smartestというラベルで速度と知能のトレードオフを調整できます。評価は4つの軸で行われます。

重要なのは、Speedが推定値である点です。推定精度に関する数値は公開ドキュメントには示されておらず、Discoverが具体的にどのモデルを提示するかも記載がありません（カタログ定義に依存します）。この2点は、採用検討時に自分の環境で確かめる必要のある未確認事項として扱うのが妥当です。

同じ推奨はCLIからも参照できます。

magnitude catalog recommendations

（出典: https://docs.magnitude.dev/reference ）

このコマンドは--preference fastest|faster|balanced|smarter|smartestと--limitを受け付けます。ハードウェア情報はmagnitude hardware、カタログはmagnitude catalog list・magnitude catalog show <model-id>で確認できます。

ハードウェア別チューニングとオンデマンドのロード挙動

選んだモデルに対しては、対応モデルであれば投機的デコード（MTP / DFlash / DSpark）とプロンプトキャッシュが自動的に適用されます。どの方式を使うかを利用者が決める必要はありません。

運用上の挙動として押さえたいのは、ダウンロードとロードが別操作である点です。モデルはエージェントからのリクエスト時にロードされ、アイドル時やメモリ逼迫時にアンロードされます。公式ドキュメントも、しばらく使っていなかった後の最初の応答はロード時間の分だけ長くなると明記しています。常にメモリを占有しない代わりに初回応答の待ちを受け入れるというトレードオフです。モデルの保存先は~/.magnitude/modelsで、Settingsから変更できます。

Magnitudeのアーキテクチャ：llama.cppをRust製の推論制御層で束ねる

リポジトリの構成を読むと、Magnitudeが「デスクトップアプリ」という見た目の下に何を積んでいるのかが分かります。ここは採用判断における「独自実装リスクはどこにあるか」に直結します。

モノレポ構成とInference Control Nodeのクレート分割

トップレベルにはcli / desktop / docs / inference / integrations / packages / webなどが並び、bun.lockとturbo.jsonが置かれています。Bun + Turborepoによるモノレポ構成です。

推論の中核はinferenceディレクトリで、ここはInference Control Node（ICN）と呼ばれています。inference/README.mdによると、以下のクレートに分割されています。

適合判定がicn-hardwareという独立したクレートとして切り出されていることは、ハードウェア診断がUIの付加機能ではなく推論制御層の一機能として設計されていることを示しています。DiscoverやCLIの推奨表示は、この層の出力を見せているという読み方ができます。

llama.cppへの依存の固定方法

推論そのものはllama.cppに依存します。ただし直接参照ではなく、自組織のバインディングフォークを経由します。.gitmodulesの実体は次の通りです。

[submodule "inference/native/llama-cpp-rs"]
	path = inference/native/llama-cpp-rs
	url = https://github.com/magnitudedev/llama-cpp-rs.git

（出典: https://github.com/magnitudedev/magnitude/blob/main/.gitmod… ）

依存の入れ子構造はinference/README.mdに図示されています。

magnitude
└── inference/native/llama-cpp-rs       # our bindings fork
    └── llama-cpp-sys-2/llama.cpp       # exact upstream llama.cpp revision

（出典: https://github.com/magnitudedev/magnitude/blob/main/inferen… ）

同READMEによると、ネイティブ依存はnative-pin.tomlに2つのリビジョンを独立して記録します。llama-cpp-rsの正確なコミットと、そのコミットが埋め込むllama.cppのgitlinkです。バインディングを変更する場合はmagnitudedev/llama-cpp-rs側にコミットしてからポインタを更新する運用で、llama.cpp自体は通常改変しないとされています。

モデルカタログの側にも同じ厳しさが見られます。inference/catalog/README.mdによると、カタログ本体はmodels.jsonで、models.lock.jsonが各カタログIDをHugging Faceの不変コミットにマップします（投機的デコード用のdraftパッケージも別途固定されます）。上流を自前で書き換えず、リビジョンを二重にピン留めし、モデルの実体もコミット単位で固定する方針は、再現性の観点で評価できる材料です。

Claude CodeやClineとの連携とAPI互換性

既存のワークフローに組み込めるかどうかも、採用判断の大きな要素です。

エージェント接続の仕組みと誤解しやすい挙動

公式ドキュメントのIntegrationsは、Pi / OpenCode / Hermes / OpenClaw / Codex / Claude Code / Oh My Pi / Clineの8種への接続を案内しています。手順は、エージェントを公式の方法でインストールし、Connectionsで接続し、接続カードでダウンロード済みモデルを選び、表示されたコマンドをプロジェクトフォルダのターミナルに貼り付ける流れです。

誤解しやすい挙動が2点あります。1つは、同ドキュメントが "Connecting configures the agent; it does not launch it." と明記しているように、接続はエージェントの設定を書くだけで起動まではしない点です。もう1つは、接続状態の「Connected」が「設定が存在し妥当である」という意味であり、推論が動いていることを示すわけではない点です。OpenClawについてはTUI内で/modelの指定が別途必要とされ、ローカルモデル利用中はMagnitude本体を起動し続ける必要もあります。

OpenAI / Anthropic互換エンドポイントとリモート利用

アプリケーションから直接叩く場合はHTTP APIが入口になります。デフォルトのエンドポイントはhttp://127.0.0.1:10100です。

Anthropic互換エンドポイントの公式のリクエスト例は次の通りです。

curl http://127.0.0.1:10100/inference/anthropic/v1/messages \
  -H 'Content-Type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -d '{"model": "MODEL_ID", "max_tokens": 256, "messages": [{"role": "user", "content": "Your prompt"}]}'

（出典: https://docs.magnitude.dev/api/endpoints ）

OpenAI互換のchat completionsも同じ形式で、どちらも"stream": trueでストリーミングに対応します。Anthropic互換のエンドポイントを標準で持つ点は、Claude Code系のツールをローカルモデルに向けたい場合の実務的な差です。OpenAI互換のみを提供する実行環境では、Anthropic系クライアントを繋ぐために変換レイヤを自前で用意することになるためです。

社内の1台を推論サーバとして共有する使い方も想定されています。公式ドキュメントのRemote Serverページによると、~/.magnitude/config.jsonのnetworkオブジェクトにapiKeyとrequireApiKey: trueを設定し、bindにローカルネットワークのIPまたはTailscaleのアドレスを指定します。magnitude serveはデスクトップアプリを開かずフォアグラウンドでサービスを実行するコマンドで、クライアント側はhttp://SERVER_IP:10100/inference/v1に接続します。

Ollama・Jan・Lemonadeとの違い

ローカルLLMの実行環境としてまず候補に挙がるのはOllamaとJanでしょう。ハードウェア最適化という思想が近いLemonadeも含め、公開メタデータとドキュメントから差分を整理します。

4ツールの比較

※ スター数・言語・ライセンス・作成日はいずれも2026年9月27日時点の公開メタデータです。

llama.cppはこの表には含めていません。Magnitudeが内部で依存する下位レイヤであり、横並びの選択肢ではないためです。LM StudioもOSSリポジトリとして公開されていないため比較表からは除いています。

「実行基盤」ではなく「選定支援」に重心がある

READMEのFAQは、OllamaやLM Studioとの違いについて次のように述べています。

"They run whatever model you pick. Magnitude helps you pick. It estimates how every model and quant will perform on your machine before you download, then tunes the one you choose for your exact hardware, from context size to speculative decoding."

（出典: https://github.com/magnitudedev/magnitude ）

これは開発側の主張であり、検証済みの事実として読むべきものではありません。ただし内容自体は、適合判定を独立クレートとして切り出しているリポジトリ構成や、ダウンロード前の速度推定・5段階の推奨ラベルという機能設計と一貫しています。

実務的に重要なのは、この差が排他的ではない点です。Ollamaは「pullするモデル名が決まっている」前提で最短距離を通るツールであり、モデル選定の支援は含まれません。逆にMagnitudeでモデルの当たりを付け、運用は社内で標準化済みのOllamaに寄せるという組み合わせも成立します。ローカルLLM選定で比較すべきなのはツールの優劣ではなく、「いま解けていないのは選定の問題か、実行の問題か」という切り分けです。

Magnitudeの採用を判断するチェックポイント

向いているケース

• 手元のマシンで動くモデルの当たりを付けたい場合: ダウンロードして試す試行回数を減らせる可能性があります。これが本ツールの中核価値です
• Claude CodeやClineをローカルモデルに向けたい場合: Anthropic互換エンドポイントを標準で持ち、8ハーネスへの接続設定が用意されています
• 社内ネットワークで1台の推論サーバを共有したい場合: magnitude serveとAPIキー必須化・bind設定というリモート運用の導線が公式に案内されています
• 完全オフライン要件がある場合: モデル・プロンプト・ファイルがマシン内に留まる設計で、トークン課金もAPIキーも不要とされています

慎重に判断すべきケースとメンテナンス状況の見方

• AMDのROCm前提で環境を整えている場合: 現時点でROCmバックエンドは提供されておらず、AMD GPUはVulkan経由です
• Intel Macで運用したい場合: CPUのみの動作となり、GPUアクセラレーションは期待できません
• 本番サービスのSLAを前提とした推論基盤: アイドル時のアンロードにより初回応答に待ちが発生する挙動は、レイテンシ要件が厳しい用途では設計上の考慮事項になります
• 特定モデルを指名して固定運用したい場合: 選定支援という中核価値が効きません。実行基盤としての安定性を優先するなら他の選択肢が候補になります

メンテナンス状況の判断材料も中立的に並べておきます。リポジトリは2026年6月12日作成で、最終更新は2026年9月26日と直近まで活発です。一方でCLIのリリースは0.1.x系にとどまり、コントリビューターは2名を中心とした構成で、オープンなissueは23件です。スター数5,170・フォーク375は関心を集めていることを示しますが、Ollama（181,775）やJan（44,659）のような運用実績の蓄積とは規模が異なります。ライセンスはApache-2.0で、アーカイブされておらずフォークでもないため、将来的に自前でパッチを当てる選択肢は残ります。

まとめ

Magnitudeの差別化は、推論の実行性能そのものではなく、モデル選定という意思決定を支援する点にあります。ハードウェアの適合判定を推論制御層の独立したクレートとして持ち、ダウンロード前に速度・知能指数・メモリ・量子化の4軸でモデルをランク付けし、選ばれたモデルに投機的デコードとプロンプトキャッシュを自動適用する流れが、その具体的な形です。

一方でリポジトリは2026年6月作成・CLIは0.1.x系という若さであり、ROCm非対応やIntel MacのCPU限定といった前提条件もあります。ローカルLLM選定の段階でMagnitudeを評価し、実行基盤としては既存のツールも併せて検討するという切り分けが、現時点では無理のない判断です。

次のステップとしては、公式ドキュメントのHardwareページとModelsページを、自分のマシン構成（GPUの世代、メモリ容量、OS）に当てはめながら読むのが最短です。対応アクセラレータの条件に自分の環境が入っているかを確認できれば、検討を進めるかどうかの判断はその時点でつきます。

関連情報

ローカルLLMの検証環境の構築や、社内向けAI基盤の設計・開発をご検討中の場合は、お問い合わせフォーム からご相談いただけます。要件の整理段階からのご相談も承っています。

参考リンク

• magnitudedev/magnitude（GitHub リポジトリ・README）
• Magnitude 公式サイト
• 公式ドキュメント Hardware
• 公式ドキュメント Models
• 公式ドキュメント API Endpoints
• 公式ドキュメント CLI Reference
• 公式ドキュメント Integrations Overview
• inference/README.md（Inference Control Node の構成）