Model Manager

mcp-modelmanager

言語モデルツール（Claude、 ChatGPT など）を通じて、独自のローカルモデルマシンを管理します。モデルとそのデータはハードウェア上に保持されます。このソフトウェアによってマシンをインターネットに公開する必要がないように設計されています。

この MCP サーバーは、AI セッションからお客様自身の Ollama／モデルマシンへの制御されたアクセスを提供します。状態の読み取り、モデルの取得と削除、推論サービスで使用するモデルの切り替え、カスタム Ollama バリアントの構築、LoRA トレーニングの実行ができます。モデルはお客様のハードウェア上で動作します。サーバープロセス自体は、単独ではお客様自身のコンピューターまたはローカルネットワークとのみ通信し、パブリックアドレスには一切接続しません。意図的にパブリックアドレスへ接続するのは、モデルを取得する場合です。fetch_model を呼び出すと、モデルマシンは実行時に Hugging Face に接続し、モデルをダウンロードします。これはツールによって明示的にトリガーされる外向きの接続であり、サーバーが裏で、あるいはセットアップ時に一度だけ行うものではありません。 switch_service が Hugging Face に直接接続することはありません。モデルがまだマシン上にない場合は処理を拒否し、先に fetch_model を実行するよう通知します。

保証されることと、保証されないこと。 推論自体はローカルで行われます。管理対象モデルに対するプロンプトとその回答が、クラウドモデルプロバイダーに送信されることはありません。ただし、通常の場合、このサーバーを操作する言語モデル（Claude、ChatGPT など）自体はホスト型サービスです。そのモデルへの指示と、モデルが参照するツールの結果は、ほかの MCP 呼び出しと同じようにプロバイダーを経由します。ここでいう「ローカル」とは、管理対象のマシンとそのデータを指し、入力した内容が何も第三者に届かないという意味ではありません。操作に使用するモデルはそれを踏まえて選ぶか、ローカルモデルで操作してください。

対応オペレーティングシステム： 単純なクエリーパス（トンネル経由での状態とモデルの読み取り）は、クロスプラットフォームで動作します。管理とセットアップ（サービスおよびトレーニングの制御）には、systemd を備えた POSIX システムが必要です（systemd ユーザーユニット、ssh -F /dev/null）。管理操作では Windows はサポートされていません。

このサーバーには、独自のアドレスも、マシンに関するデフォルト値も設定されていません。マシンの場所はお客様が入力します。これらの情報がない場合、サーバーは意図的に起動しません（必須フィールドおよびSETUP.mdを参照してください）。

サーバーでできること、できないこと

できること： 状態（GPU メモリ、ディスク容量、実行中のサービス、コンテナー）の照会、モデルの一覧表示／取得／削除、vLLM 推論サービスで使用するモデルの切り替え（必要メモリの事前見積もり付き）、カスタム Ollama バリアントの構築（固定システムプロンプト、パラメーター、後からアダプターを追加可能）、LoRA トレーニングの開始／追跡／キャンセル。

できないこと、および意図的に行わないこと： マシン上で任意のコマンドを実行すること。自由なリモート制御を行うツールはありません。すべての操作は固定テンプレートで実行され、すべてのパラメーターは事前に許可リストによる検証を受けます（セキュリティモデルを参照）。

クエリー用のブリッジではありません。 モデルに単に質問する場合は、別の読み取り専用 MCP サーバー（たとえば、Ollama へのシンプルな HTTP ブリッジ）を使用します。このサーバーはマシンを管理します。サーバーを分けることで、クエリー呼び出しが誤って管理権限を持つことを防ぎます。

お使いのマシン：3つのケース

モデルマシンの接続方法はさまざまです。3つのケースすべてに対応しており、入力するアドレスだけが異なります。

ケース	Ollama/vLLM の実行場所	MM_VM_HOST に入力する値
a）同じマシン	このサーバーと同じコンピューター	127.0.0.1
b）ローカルネットワーク上	同じ LAN 内の別のコンピューター	LAN アドレス（例：192.168.1.10）
c）トンネル/VPN 経由	VPN/トンネル経由で接続できるリモートコンピューター	お使いの側/VPN 側のアドレス（例：ローカル SSH トンネルの場合は 127.0.0.1、または VPN アドレス）

安全対策：サーバープロセス自身が行う MCP/SSH/HTTP 通信は、お使いのコンピューターまたはローカルネットワークにのみ向かいます。これらの範囲外のアドレス（パブリック IP、外部ホスト名）は MM_VM_HOST として拒否されるため、サーバーが独自にパブリックアドレスへ接続してモデルマシンと通信することはありません。ケース c）の場合、トンネル/VPN はローカルまたはプライベートアドレス範囲で終端し、接続先には遠隔側のパブリックアドレスではなく、そのローカル/プライベートアドレスを入力します。この安全対策はモデルのダウンロードには適用されません。fetch_model はモデルの取得を指示されるたびに、モデルマシン自体から Hugging Face というパブリックアドレスへ接続します（前述の注意事項を参照）。switch_service は、マシン上にないモデルを取得せずに拒否します。fetch_model(source="ollama") は、マシンをもう1つの、同じく意図的なパブリックアドレスに接続します。つまり、マシンの Ollama デーモンに /api/pull 経由でモデルをプルさせます。通常のモデル名の場合は registry.ollama.ai に接続します。hf.co/user/repo のようなプレフィックス付きの名前の場合は、別のレジストリに接続します。

通常の クエリ（状態、バージョン、ロード済みモデル）は、HTTP でサービスのポートに接続して実行します。管理（モデルのプル、サービスの切り替え、トレーニング）は、保護された SSH 制御チャネルを介して実行します。そのため、管理にはマシンへの SSH アクセスが必要です。ケース a）の場合も同様です（この場合は 127.0.0.1 に SSH 接続します）。

インストール

要件：Python 3.11 以降。

uv を使用する場合（推奨）：

uv venv --seed .venv
.venv/bin/pip install -r requirements.txt

--seed により、venv に pip が確実にインストールされます。

Python の組み込み機能を使用する場合（代替手段）：

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt

お使いのシステムで python3 -m venv を実行しても pip のない venv が作成される場合（ensurepip がない場合）は、上記の uv を使用する方法をお使いください。

直接の依存関係は2つだけで、どちらもバージョンが固定されています。MCP SDK（mcp==1.30.0）と HTTP クライアント（httpx==0.28.1）です。この2つのバージョン指定は requirements.txt と pyproject.toml に記載されています。さらに、推移的なパッケージ（anyio、pydantic、starlette、uvicorn、jsonschema、pyjwt を含む）を含めた依存関係ツリー全体が uv.lock で固定されています。CI では uv lock --check を実行してロックファイルが pyproject.toml と一致しているか確認し、その後、テスト用にロックされた依存関係ツリーを正確にインストールするため、ロックファイルにずれがあると CI は失敗します。別途、助言目的の pip-audit ジョブが、main へのプッシュとプルリクエストのたびに、さらに毎週、ロックされた依存関係ツリーに既知の脆弱性がないか確認します。このジョブがプルリクエストをブロックすることはありません。SSH アクセスには、システムの ssh プログラムを使用します。

必須フィールド

サーバーは、設定を環境変数のみから読み込みます。 次の3つは必ず設定してください。設定しないとサーバーは起動しません。

フィールド	意味
MM_VM_HOST	モデルマシンのアドレス（127.0.0.1、LAN IP、またはトンネル／VPN アドレス）
MM_VM_USER	マシン上の SSH ユーザー名（制御チャネル経由の管理にのみ使用）
MM_CONTAINER_ROOT	モデル、アダプター、キャッシュのデータをすべて格納する、モデルマシン上のルートディレクトリ

いずれかが設定されていない場合、不足しているフィールド名を明示するメッセージとともに起動が中止されます。例：

$ PYTHONPATH=src .venv/bin/python -m mcp_modelmanager.server
MM_CONTAINER_ROOT is not set. Enter the root directory on your model machine
under which all model, adapter and cache data live. Without this value the
server does not start. See SETUP.md.

その他のフィールドには妥当なデフォルト値があります（Ollama と vLLM の標準ポート、キーの保存先は自身の ~/.ssh）。必要な場合にのみ設定してください。詳しくは環境変数を参照してください。

空の状態からサーバーの起動までの完全な手順（保護された SSH チャネルを含む）は、SETUP.mdに記載されています。GPU のモデルマシン自体（以下の MM_* 変数で指定する、Ollama や vLLM をインストールして到達可能にしたマシン）の構築は、マシン側の作業です。このリポジトリには、オペレーター側のスクリプト（setup/、vm_side/）、ネットワーク隔離のテンプレート（security/）、およびマシン側のガイド（MACHINE.md、SECURITY.md、SETUP-MACHINE.md）も同梱されており、サーバーと同じ場所にあります。マシン側の作業はMACHINE.mdから始めてください。

MCP の登録（プレースホルダーを使った例）

お使いの言語モデルツールにサーバーを登録します。山括弧内のプレースホルダーを値に置き換えてください。サーバーを指定する方法は2通りあり、どちらもサポートされています。

チェックアウトから実行する場合（インストール不要。PYTHONPATH が src/ を指します）：

{
  "mcpServers": {
    "modelmanager": {
      "command": "/path/to/mcp-modelmanager/.venv/bin/python",
      "args": ["-m", "mcp_modelmanager.server"],
      "cwd": "/path/to/mcp-modelmanager",
      "env": {
        "PYTHONPATH": "src",
        "MM_ACCESS": "direct",
        "MM_VM_HOST": "<your-machine-or-127.0.0.1>",
        "MM_VM_USER": "<your-ssh-user>",
        "MM_CONTAINER_ROOT": "/srv/models"
      }
    }
  }
}

pip install . の実行後（コンソールエントリーポイントを使用。cwd／PYTHONPATH は不要）：

{
  "mcpServers": {
    "modelmanager": {
      "command": "/path/to/mcp-modelmanager/.venv/bin/mcp-modelmanager",
      "env": {
        "MM_ACCESS": "direct",
        "MM_VM_HOST": "<your-machine-or-127.0.0.1>",
        "MM_VM_USER": "<your-ssh-user>",
        "MM_CONTAINER_ROOT": "/srv/models"
      }
    }
  }
}

どちらのブロックも、多くの MCP クライアント（Claude Code、Claude Desktop、および mcpServers JSON ブロックを読み込むその他の MCP クライアント）が読み取る標準的な mcpServers JSON 形式に従っています。このブロックをどこに記述するかは、クライアントのドキュメントを参照してください。

MM_ACCESS は direct（指定したアドレスのサービスポートにサーバーが直接接続）または tunnel（127.0.0.1 に接続し、必要に応じて SSH トンネルを構築）です。tunnel がデフォルトです。上記の例では、レベル2のトンネルを使用しないケース a）／b）のセットアップに必要な direct を指定しています。そのため、そのトンネルを設定するまでは MM_ACCESS=direct を明示的に設定してください。

セキュリティモデル：固定操作

任意のコマンドを実行するツールはありません。すべての操作は operations.py に定義された固定テンプレートです。呼び出し側が入力できるのは名前付きプレースホルダーのみで、各値は最初に許可リスト（validation.py）を通過する必要があります。許可されるのは、合意された形式に明示的に一致する値です。除外されるのではなく、許可されます。置換時にはさらに shlex.quote で引用処理されます。これは多層防御の最後の層であり、安全対策そのものではありません。

こちら側では送信前に検証し、モデルマシン上で実行される対向側でも独立して再度検証します。対向側は制御チャネルのキーにバインドされています。そのため、そのキーが盗まれたとしても、アクセスできるのは限定された操作のみです。

さらに、対象は自身のコンピューターまたはローカルネットワーク上のものに限られます。名前は使用のたびに解決して再検証されます（クエリサーバーのようにアドレスを固定することはありません。ホスト名を使う場合は、MM_VM_HOST に IP アドレスを設定することを推奨します）。コード内に認証情報はなく、.env も使用しません。 2つの SSH キーはリポジトリの外部にある自身の ~/.ssh に保存されます。また、.gitignore ではキーパターンも除外されています。

トンネル用のデータチャネルと管理用の制御チャネルからなる、保護された2チャネル構成の設定と検証手順は、SETUP.mdに順を追って記載されています。

操作ティアとオペレーターゲート

すべてのツールには固定の分類があり、コード内の一か所 （TOOL_TIER）で管理されるため、この表とポリシーが食い違うことはありません。

ティア	意味	ツール
READ	状態を確認するだけで、何も変更しません	status、models_present、job_status、list_jobs、list_variants、show_variant、list_adapters、training_status、check_training_env、check_isolation
CONTROL	実行中の状態を元に戻せる形で変更します	fetch_model、create_variant、switch_service、stop_service、start_service、start_training
DESTRUCTIVE	削除またはキャンセルします	remove_model、remove_variant、cancel_training

この分類は認可システムではありません（SECURITY.mdの注記を参照）。コードを編集せずに、このサーバーが実行する操作を絞り込めるようにする、大まかなオペレーター用スイッチです。無効な操作も MCP 上には表示されますが、呼び出されると、マシンにアクセスする前に拒否されます。

変数	デフォルト	効果
MM_MAX_TIER	read	サーバーが実行する最大ティアです。readではREADツールのみ、controlではREADとCONTROL、destructiveではすべてが利用可能になります。
MM_ENABLED_OPERATIONS	空（MM_MAX_TIERの範囲内ですべて）	正確なツール名を指定する、カンマ区切りの許可リストです。MM_MAX_TIERに加えて適用され、このリストが設定されている場合、ツールはMM_MAX_TIERの範囲内にあり、かつここに名前が記載されている場合にのみ実行されます。名前の誤記があると、より多くの操作が暗黙に公開されるのではなく、サーバーは起動時に停止します。

デフォルトは読み取り専用（デフォルトで拒否）です。何も設定しなければ、READツールのみが実行されます。CONTROLおよびDESTRUCTIVE操作を有効にするには、明示的に切り替える必要があります。このゲートは、SSHやVMにアクセスする前に、無効な操作を早い段階で確実に拒否し、ティアと変更方法を示すメッセージを返します。管理操作（fetch_model、switch_service、トレーニングなど）も許可するには、次のようにします。

"env": { "MM_MAX_TIER": "control" }

操作を2つだけ、それ以外は何も公開しない場合は、MM_ENABLED_OPERATIONSがMM_MAX_TIERに加えてさらに範囲を絞ることに注意してください。そのため、ティアは指定した両方のツールを許可している必要があります。ここではswitch_serviceはCONTROLなので、MM_MAX_TIERを少なくともcontrolに引き上げる必要があります。

"env": { "MM_MAX_TIER": "control", "MM_ENABLED_OPERATIONS": "status,switch_service" }

同時実行ガード

マシンにはGPUが1つと推論サービスが1つしかないため、状態変更が同時に2つ行われると、状態に不整合が生じます。GPUの状態を変更する各ツールは、クリティカルセクションを直列化して実行します（設計上、fetch_modelとcancel_trainingは例外です。fetchはバックグラウンドジョブであり、cancelは常に実行できる必要があるためです）。1つの処理が実行中に2つ目の処理が開始されると、キューに入れられるのではなく、直ちに拒否されます。また、GPUを競合する操作（switch_service、remove_model、create_variant、start_training、start_service）は、このサーバーが開始したトレーニングがまだ実行中の場合に拒否されます。このガードはプロセス内で機能し、このサーバー自身の呼び出しの整合性を保ちます。別のセッションから開始されたトレーニングは、マシン側で検出されます（新しいstart_trainingは推論を先に停止します）。ただし、ここでは完全には直列化されません。この境界についてはSECURITY.mdに記載されています。

ツール

ツール	目的
status	稼働状況：サービス、モデル、GPU メモリ、ディスク容量、コンテナ
models_present	マシン上のモデル一覧。Ollama と Hugging Face に分けて表示します
fetch_model	モデルを取得し、ID をすぐに返します
job_status	バックグラウンドジョブの進行状況
list_jobs	ここおよびマシン上で確認できるジョブ
remove_model	モデルを削除します。確認文を文字どおり指定した場合に限ります
create_variant	カスタム Ollama バリアントを構築します：ベースモデル、システムプロンプト、パラメーター
list_variants	既存のバリアント、その由来、設定内容
show_variant	両方のソースから、バリアントに実際に含まれる内容を表示します
remove_variant	バリアントを削除します。確認文を文字どおり指定した場合に限ります
switch_service	推定とクロスチェックを行い、vLLM を別のモデルに切り替えます
stop_service, start_service	サービスを停止して再起動します
check_training_env	LoRA 環境が存在し、インポート可能か確認します
start_training	バックグラウンドで LoRA を実行します。先に推論を停止し、その旨を通知します
training_status	ステップ、損失、残り時間の推定
cancel_training	実行を終了します。確認が必要です
list_adapters	学習済みアダプターとベースモデル
check_isolation	トンネルは動作し、LAN からは接続できないことを、実際の動作で両方確認します

GPU が 1 基のマシンにおける制約

• 大規模モデルを一度に 1 つだけ実行できます。 switch_service は事前に、 重み、キー・バリューキャッシュ、基本負荷を合わせて割り当てメモリに収まるか 計算し、実行を試みるのではなく、収まらない場合は拒否します。名前からの 大まかな目安ではなく、実際のファイルサイズとモデルの config.json を使って 計算します。両方が見つからない場合に限り概算し、その場合は不確実であることを 明示します。
• switch_service が起動できるのは、既知のコンテナイメージとマウントできる 既知のパスだけです。 作成（または再作成）するコンテナは、限定された イメージ許可リスト（設定済みの vLLM イメージ MM_VLLM_IMAGE。既定値は vllm/vllm-openai。さらに ollama/ollama。タグまたはダイジェストを付けることも できます。ミラーリングされた vLLM イメージは MM_VLLM_IMAGE で設定しない限り 拒否されます）に照らして検証され、すべてのバインドマウントのホスト側は 設定済みデータルートのいずれかの配下にある必要があります。詳しい説明は SECURITY.md を参照してください。
• 推論とトレーニングで GPU を共有することはありません。 推論を停止する確認が 設定されていない限り、start_training は拒否し、停止対象を明示します。数値の ハイパーパラメーター（エポック数、ランク、アルファ、学習率、最大長、バッチサイズ、 勾配累積）にはそれぞれ固定範囲があり、両側でチェックされます。ここでは実行内容を 書き込む前に、さらにマシン側ではトレーニングライブラリに値を渡す前に、独立して 再チェックします。
• マシンに GPU が常に搭載されているとは限りません。 到達できない場合、サーバーは エラーではなく、説明付きで独自の状態として報告します。GPU を共有する別のマシンが MM_VM2_HOST で既知の場合、状態は gpu_probably_on_second_machine になり、 そうでなければ単に machine_unreachable になります。
• 切り替えが失敗しても通知されないことが、最も危険な障害モードです。 切り替えの たびに /health と /v1/models を確認し、サービスが実際に応答し、目的のモデルを 提供しているか検証します。結果は必ずレポートに含まれます。

カスタム Ollama バリアント

Ollama では、Modelfile を使って、固定のシステムプロンプト、独自のパラメーター、 後から学習したアダプターを備えるモデルを派生させることができます。派生モデルは 独自のモデル名で表示され、ほかのモデルと同じように指定できます。これが特化型 エージェントを作る方法であり、同時にトレーニング結果を運用に反映する方法です。

create_variant(
    name          = "handyman:v1",
    base_model    = "qwen3:4b",
    system_prompt = "You are a terse expert assistant ...",
    parameters    = {"num_ctx": 8192, "temperature": 0.2})

注意が必要な箇所：自由記述がディレクティブファイルに入り込む場合

システムプロンプトは、ユーザーが内容を決められる文章です。しかし、Ollama がディレクティブのリストとして読み込むファイルに書き込まれます。検証せずに渡せば、シェル経由ではなく、その一段上の Modelfile 自体で保護を丸ごと迂回されてしまいます。4 つの対策が連携します。

1. Modelfile は転送せず、マシン上で組み立てます。 制御チャネルを通るのは、ベースモデル、パラメーター名と数値のオブジェクト、アダプターのパス、システムプロンプトだけです。完成した Modelfile を送信することはできません。
2. 許可するディレクティブは固定リストに限定します。 テンプレートが生成できるのは FROM、PARAMETER、ADAPTER、SYSTEM だけで、それ以外は生成できません。FROM が受け取るのは Ollama のモデル名のみで、パスは受け取らず、実際のインベントリと照合して検証します。
3. 自由記述は Base64 で送信します。 Base64 の文字セットからは、転送中にシェル構文や改行が生じることはありません。デコードはマシン上でのみ行い、そのままファイルに書き込みます。
4. 自由記述の文字セットに二重引用符は含まれません。 複数行の Modelfile 値は二重引用符 3 つで終わります。この文字が文字セットにないため、テキストが自身のブロックを終わらせてディレクティブになることはありません。引用符には、タイポグラフィック引用符とアポストロフィを使用できます。

両側で検証します。validation.py はこちらでもマシン上でも実行されるためです。こちらの検証を通過して制御チャネルに直接送られた細工済みのリクエストも、ラッパー側で拒否されます。

調整可能なパラメーター

Ollama が認識するすべてのパラメーターではなく、実際に使う価値のあるものを対応付けています。いずれも、マシンに値が届く前に範囲を検証します。

パラメーター	型	範囲	効果
num_ctx	整数	256 to 131072	モデルが一度に把握できるテキスト量
temperature	数値	0.0 to 2.0	ランダム性。0 は最も再現性の高い回答を意味します
top_p	数値	0.0 to 1.0	確率質量による核サンプリング
top_k	整数	1 to 200	件数による核サンプリング
min_p	数値	0.0 to 1.0	最も確率の高いトークンを基準とした下限
repeat_penalty	数値	0.5 to 2.0	繰り返しを抑制します。1.0 は無効を意味します
repeat_last_n	整数	-1 to 4096	抑制の対象とする遡り範囲。-1 は num_ctx を意味します
num_predict	整数	-2 to 32768	回答の長さ。-1 は無制限、-2 はコンテキストがいっぱいになるまでを意味します
seed	整数	0 to 2147483647	回答の再現性を確保する固定シード

アダプター：準備済みですが未稼働

adapter パラメーターは構築され、検証もされていますが、参照状態では訓練済みアダプターがないため、パスは一度も実行されていません。用意されているのは、アダプターのパスの許可リスト、コンテナーから見たパスへの変換、テンプレート内の ADAPTER 行、表示ツールでの読み取りです。最初の実際のアダプターで確定する必要がある事項（Safetensors と GGUF の形式、コンテナー内の保存場所、ベースモデルおよび量子化との適合性）は、未解決の項目としてコード内の該当箇所に記されています。確認が済むまでは、adapter は空のままにしてください。

セルフテスト

.venv/bin/python selftest.py          # without the machine, HTTP is mocked
.venv/bin/python selftest.py --live   # additionally against the real machine

ほとんどのグループはマシンなしで実行できます。マシンが必要なのは、任意の --live グループ M だけです。一部のチェックで実行するオペレーター側のセットアップスクリプト（setup/、vm_side/）は、サーバーと並んでこのリポジトリに含まれています。そのため、これらのスクリプトがそろっていれば、セルフテストではこのマシン上で追加のチェックも実行でき、モデル用マシンは必要ありません。サーバーコードのグループに加えて、ラッパーの実際の実行（グループ D）、セットアップスクリプト自体（グループ J）、分離（グループ K）、オペレーターのポリシー、同時実行ガード、分離ヘルパー（グループ N）を検証します。攻撃テスト一式に対する許可リスト、カタログと置換、リクエスト形式、スタブサーバーに対するサービス側、手作業で確認した値に対するメモリ推定、接続レイヤー、マシン出力の解析、および各バリアントもすべて実行して検証します。サーバーディレクトリだけを実行し、サーバーと並んでいる setup/ および vm_side/ スクリプトを取り除いた場合でも、セルフテストはサーバーコードのグループに合格し、グループ D、J、K、および I と N のうちオペレーター専用の部分は、失敗としてカウントされず、メッセージを表示して問題なくスキップされます。どちらの場合もモデル用マシンは必要ありません。必要なのは任意の --live グループ M だけです。このグループは、接続可能でセットアップ済みのマシンに対して実行され、どちらの場合にも追加できる任意のグループです。（チェック数は実行時にランナーが表示する数です。チェックの追加に伴って増えるため、固定値としてここでは記載せず、保証もしません。）

--live は MM_VM_HOST／MM_VM_USER／MM_CONTAINER_ROOT を読み込みません。独自の別個の変数を使用し、決して到達できないアドレス（TEST-NET、RFC 5737）をデフォルトとするため、追加設定なしで --live を実行しても、誤って合格となるのではなく、何も表示せずにスキップされます。

名前	デフォルト値	意味
MM_LIVE_HOST	192.0.2.10	グループ M がプローブするマシンのアドレス
MM_LIVE_PORT_VLLM	8000	そのマシン上の vLLM ポート
MM_LIVE_PORT_OLLAMA	11434	そのマシン上の Ollama ポート

--live が実際に接続可能なマシンを参照するよう、3 つすべてを設定してください。そうしないと、通常のサーバー利用に向けて MM_VM_HOST を正しく設定していても、「VM に接続できません。ライブグループをスキップします。エラーではありません。」と表示されます。

環境変数

必須のフィールドには 必須 と記載されています。デフォルト値はありません。

Name	Default	Meaning
MM_VM_HOST	required	モデルマシンのアドレス（127.0.0.1、LAN IP、またはトンネル／VPN のアドレス）
MM_VM_USER	required	マシン上の SSH ユーザー
MM_ACCESS	tunnel	tunnel（SSH トンネル経由で 127.0.0.1 に接続）または direct（アドレスに直接接続）
MM_MAX_TIER	read	サーバーが公開する操作ティアの上限：read、control、destructive（操作ティアを参照）
MM_ENABLED_OPERATIONS	empty	任意の、ツール名を正確に指定したカンマ区切りの許可リストです。設定すると、指定したものだけが実行されます。入力ミスがあると起動に失敗します
MM_VM2_HOST	empty	任意：GPU を共有する 2 台目のマシンです。到達不能の原因を判定するために使います。マシンが 1 台だけの場合は空のままにしてください
MM_KEY_DIR	~/.ssh/modelmanager	2 つの SSH キーの保存場所（リポジトリの外部）
MM_KEY_DATA	${MM_KEY_DIR}/datachannel	データチャネルの秘密鍵
MM_KEY_CONTROL	${MM_KEY_DIR}/controlchannel	制御チャネルの秘密鍵
MM_KNOWN_HOSTS	${MM_KEY_DIR}/known_hosts	モデルマシンのホスト鍵を固定するファイル
MM_FROM	required (only while building the level-2 allowlist)	2 つのキーで許可する送信元アドレス（複数指定する場合はカンマ区切り）
MM_FROM_NET_ALLOWED	no	yes に設定すると、警告を表示したうえで、MM_FROM にネットワーク全体を許可できます（レベル 2 の許可リストの構築時のみ）
MM_REMOTE_PORT_VLLM	8000	マシン上の vLLM ポート（vLLM の標準ポート）
MM_REMOTE_PORT_OLLAMA	11434	マシン上の Ollama ポート（Ollama の標準ポート）
MM_LOCAL_PORT_VLLM	8000	トンネル経由で vLLM に接続するためのローカルポート
MM_LOCAL_PORT_OLLAMA	11434	トンネル経由で Ollama に接続するためのローカルポート
MM_CONTAINER_VLLM	vllm	vLLM Docker コンテナの名前
MM_CONTAINER_OLLAMA	ollama	Ollama Docker コンテナの名前
MM_VLLM_IMAGE	vllm/vllm-openai	再作成許可リストが受け付ける vLLM イメージです。ミラーまたは名前を変更したイメージを使う場合は、ここに設定してください。そうしないと拒否されます
MM_MIN_DISK_GB	15	Ollama のプルで必要なディスク容量の下限
MM_CONTAINER_ROOT	required, no default	すべてのモデル、アダプター、キャッシュデータを格納する、マシン上のルートディレクトリです。設定されていない場合、サーバーは起動しません
MM_VM_ROOT	${MM_CONTAINER_ROOT}/manager	マシン上にあるこのツール独自の作業ルート（ジョブフォルダーはその下に作成されます）
MM_VM_DATA_ROOT	${MM_CONTAINER_ROOT}	トレーニングデータセットのパスがその配下にある必要があるルート（data_path_check、df の使用状況レポート）
MM_VM_ADAPTER	${MM_CONTAINER_ROOT}/adapter	完了した LoRA トレーニング実行のアダプター保存先
MM_LORA_PYTHON	${MM_CONTAINER_ROOT}/lora-venv/bin/python	マシン上の LoRA トレーニング環境のインタープリター
MM_VM_OLLAMA_STORE	${MM_CONTAINER_ROOT}/ollama	マシン上の Ollama データフォルダー（コンテナにマウントされます。下の表を参照）
MM_IN_CONTAINER_STORE	/root/.ollama	Ollama コンテナ内から見た同じフォルダーのパス
MM_VM_HF_CACHE	${MM_CONTAINER_ROOT}/hf	マシン上の Hugging Face 重みキャッシュのルート
MM_GPU_TOTAL_GB	12.0	想定 GPU メモリ容量（GB）。nvidia-smi の実測値の取得に失敗した場合のみ使用されます
MM_AUDIT (machine-side, not set here)	${MM_VM_ROOT}/audit.jsonl	モデルマシン自体にある監査ログのパスです。マシン側のラッパーがそこで読み取ります。デフォルトは install.sh が作成する audit.jsonl です。このサーバーは読み取りません
MM_ENFORCE_ROOT_OWNED (machine-side, not set here)	unset	1 に設定すると、install.sh によって有効化されていないチェックアウトコピーでも、マシン側ラッパーの lib/ に対する root 所有ガードを強制します。ガードを有効にすることだけが可能で、無効にはできないため、環境変数でインストール済みコピーの保護を弱めることはできません。セルフテストで使用します。このサーバーは読み取りません
MM_STATE_DIR	$XDG_STATE_HOME/mcp-modelmanager (or ~/.local/state/mcp-modelmanager)	このサーバー側でローカルのジョブ状態（fetch_model／start_training のジョブファイル）を保存する場所
ローカルトンネルのポートは、リモートポートと同じ既知の値にデフォルト設定されています。ローカルで既に使用されている場合は調整してください。

MM_CONTAINER_ROOT は必須で、組み込みのデフォルト値はありません（このツールが前提にできるデフォルトのマシンレイアウトがないためです）。この変数が設定されていないと、サーバーは起動時に終了します。上記の 6 つの MM_VM_*／MM_LORA_PYTHON 変数は、デフォルトでこの値から導出されます。また、MM_IN_CONTAINER_STORE と同様に個別に上書きできます。そのため、ディレクトリレイアウトが異なるマシンにも、コードを変更せず、設定だけで対応できます。VM パスの各値は、起動時に厳格な許可リストに照らして検証されます（絶対パスであること、使用できる文字は英数字、ドット、ハイフン、アンダースコア、スラッシュのみであること、..、スペース、シェル文字を含まないこと）。不正な値があると、信頼されることなくサーバーが直ちに停止します。さらに、MM_VM_DATA_ROOT と MM_VM_OLLAMA_STORE は、後でツール呼び出しに渡されるすべてのパス（トレーニングデータセットのパスやアダプターパスなど）の許可リストのルートになります。そのため、実際に設定されている内容との整合性が保たれます。

上記のルートから導出される、バリアントに必要なマシン上の場所（operations.py 内で設定され、個別には設定できません）。セットアップで以下のパスが作成されます。

マシン上	コンテナ内	用途
MM_VM_OLLAMA_STORE（デフォルト ${MM_CONTAINER_ROOT}/ollama）	MM_IN_CONTAINER_STORE（デフォルト /root/.ollama）	Ollama のデータフォルダー。マウントされます
<MM_VM_OLLAMA_STORE>/variants/<name>/Modelfile	<MM_IN_CONTAINER_STORE>/variants/...	組み立てられた Modelfile
<MM_VM_OLLAMA_STORE>/adapter	<MM_IN_CONTAINER_STORE>/adapter	アダプターの保存場所

ライセンス

MIT。詳しくは LICENSE をご覧ください。