Codex 用ローカル大規模モデル API の使用チュートリアル: Ollama、LM Studio、および vLLM

Codex でローカルの大規模モデルを使用する場合は、OpenAI 互換アドレスをプロジェクト構成に直接接続しないでください。現在、Codex には、より信頼性の高いローカルモデルパス、OSS モード があります。 Ollama または LM Studio をローカルプロバイダーとして選択することをネイティブにサポートします。

最も短いコマンドは次のとおりです。

1

codex --oss --local-provider ollama

または：

1

codex --oss --local-provider lmstudio

vLLM、LiteLLM、またはその他の OpenAI 互換ゲートウェイを自分でデプロイする場合は、openai_base_url の高度な構成を調べることができます。ただし、このパスでは、サービスが Codex で必要な API 動作と完全に互換性がある必要があり、トラブルシューティングのコストが高くなります。組み込み OSS モードと混同しないでください。

まず正しいルートを選択してください

あなたのローカルサービス	推奨接続方法	誰に適しているか
オラマ	`codex --oss --local-provider ollama`	ローカルモデルをできるだけ早く実行したい
LMスタジオ	`codex --oss --local-provider lmstudio`	LM Studio でダウンロードおよび管理されたモデル
vLLM / 自社構築OpenAI対応サービス	ユーザーレベル `openai_base_url`	API の互換性、認証、モデルルーティングを理解している上級ユーザー

一般の個人ユーザーは、最初に Ollama または LM Studio を実行することをお勧めします。 Codex の --oss は、指定されたローカル OSS プロバイダーを使用します。 --local-provider が渡されず、デフォルト値が設定されていない場合、対話型 CLI は選択を求めるプロンプトを表示しますが、codex exec は直接エラーを報告します。

解決策 1: Ollama を使用して Codex に接続する

1. Ollama とモデルが利用可能であることを確認します

まず、Ollama が利用可能かどうかを確認します。

1
2


ollama -v
ollama ls

モデルがない場合は、まずローカルビデオメモリに適したコードまたは一般的なモデルをダウンロードします。次に例を示します。

1

ollama pull qwen3:8b

個別にテストします。

1

ollama run qwen3:8b

モデルを Ollama で実行できない場合は、まずビデオメモリ、ドライバー、モデルのダウンロード、または Ollama サービスの問題を解決します。トラブルシューティングのために Codex に直接アクセスしないでください。

2. 使い捨てローカルモデル

プロジェクトディレクトリで実行します。

1

codex --oss --local-provider ollama

次に、通常どおりタスクを入力します。例:

1

阅读这个仓库的 README，列出本地启动步骤，不要修改文件。

これは現在のセッションにのみ影響します。一時的に通常の Codex に戻したい場合は、--oss なしで起動してください。

3. Ollama をデフォルトのローカルプロバイダーとして設定します

ローカルモデルを頻繁に使用する場合は、ユーザーレベル Codex 構成ファイルに次の内容を追加します。

1

oss_provider = "ollama"

その後、直接実行できます。

1

codex --oss

User-level configuration of Codex is usually located under CODEX_HOME, and the default is ~/.codex/config.toml;一般的な Windows パスは次のとおりです。

1

C:\Users\你的用户名\.codex\config.toml

変更後にコーデックスを再度開きます。複雑な構成がある場合は、config.toml をバックアップしてから、この行のみを追加してください。元のサンドボックス、MCP、スキル、その他の設定を上書きしないでください。

オプション 2: LM Studio を使用して Codex に接続する

LM Studio は、GGUF モデルをダウンロードし、グラフィカルインターフェイスを使用してコンテキストと GPU オフロードを調整したい人に適しています。

1. LM Studioでローカルサービスを開始し、モデルをロードします。

LM Studio の 開発者 ページに入り、サーバーを起動し、チャット/指示モデルがロードされていることを確認します。 LM Studio のローカル API は、デフォルトで次の場所でリッスンします。

1

http://localhost:1234

最初にモデルサービスを確認できます。

1

curl http://localhost:1234/v1/models

ここで返されるのは、LM Studio 側のモデルのステータスです。これは、サービスとモデルの両方の準備ができていることを確認するのに役立ちます。

2. Codex OSS モードで開始します

1

codex --oss --local-provider lmstudio

長期的なデフォルト構成:

1

oss_provider = "lmstudio"

次に、次を使用します。

1

codex --oss

LM Studio のモデルコンテキストの長さ、GPU オフロード、推論パラメータは引き続き LM Studio によって管理されます。 Codex の応答が遅い場合は、まずモデルサイズがビデオメモリを超えていないか、コンテキストの設定が長すぎないか、他のローカル推論サービスが同時に GPU を占有しているかどうかを確認します。

オプション 3: vLLM などの OpenAI 互換 API の高度な接続方法

vLLM、LiteLLM、エンタープライズゲートウェイ、および一部のエージェントは、OpenAI 互換の /v1 インターフェイスを提供します。 Codex の公式構成リファレンスでは、組み込みの openai プロバイダーのベースアドレスをオーバーライドする openai_base_url が提供されています。

概略構成:

1

openai_base_url = "http://127.0.0.1:8000/v1"

サービスが LAN ホスト上にある場合:

1

openai_base_url = "http://192.168.1.20:8000/v1"

この道路には注意すべき境界線が 4 つあります。

**ユーザーレベル ~/.codex/config.toml でのみ書き込まれます。 ** Codex は、リポジトリがマシンのモデルプロバイダーを密かに変更するのを防ぐために、プロジェクト .codex/config.toml の openai_base_url、model_provider、および model_providers を無視します。
サービスは「/v1/chat/completions」だけあれば十分ではありません。 Codex 固有のワークフローには、モデル、ストリーミング応答、ツール呼び出し、またはその他の互換性のある動作が必要な場合があります。
認証はゲートウェイによって決定されます。ゲートウェイにベアラートークンが必要な場合は、ゲートウェイと Codex の現在の認証構成に従って正しく設定する必要があります。トークンをウェアハウスファイルに書き込まないでください。
これは、Codex にリストされている OSS の公式のローカルプロバイダーではありません。例外が発生した場合は、まず Ollama または LM Studio を使用して Codex OSS モードを確認し、次にゲートウェイの互換性を確認します。

vLLM サービスは、最初に個別に検証できます。

1

curl http://127.0.0.1:8000/v1/models

コマンドがモデルの安定したリストを返した後にのみ、コーデックスのユーザーレベル openai_base_url のチェックが継続されます。

モデルの選び方

ローカルモデルが「使用できる」かどうかと、「公式 Codex モデルと同じくらい信頼できる」かどうかは別のことです。コードエージェントは通常、長いコンテキスト、安定したツール呼び出し、強力なコード理解、および十分に速い生成速度を必要とします。

選択するときは、少なくとも次の点に注目してください。

ビデオメモリがモデルの重みと共通のコンテキストに対応できるかどうか。
モデルが命令/チャットモデルであるか、特殊なコードモデルであるか。
ファイルの変更、テスト、コマンド実行の要件に安定して準拠できるかどうか。
必要なツール呼び出しまたは JSON 出力をサポートしているかどうか。
長いタスクの下では、軌道から逸れたり、制約を忘れたり、不完全な修正が生じたりしやすくなりますか?

ローカル 7B/8B モデルは、ウェアハウスの参照、単純なスクリプト、ドキュメントの編成、およびローカルの変更に適しています。複数ファイルのリファクタリング、複雑なテスト修復、および長期にわたるエージェントタスクには、より高度なモデルとハードウェア要件が必要です。ローカル API に接続できるからといって、それがリスクの高い自動変更に適しているとは考えないでください。

安全に始める方法

ローカルモデルを使用して Codex を初めて実行する場合は、最初に権限を制限することをお勧めします。

1

codex --oss --local-provider ollama --sandbox read-only

まずモデルに読み取り専用タスクを完了させます。

1

分析当前仓库的目录结构，指出启动命令和测试命令。不要修改文件。

モデルがウェアハウスを理解し、出力が安定していることを確認したら、徐々にワークスペースの書き込みとテストの実行を許可します。確認ステップを保存するために、サンドボックスなしモードまたは承認スキップモードを直接有効にしないでください。

よくある質問

1. `codex exec --oss` はエラーを直接報告します

通常、ローカルプロバイダーは指定されません。使用：

1

codex exec --oss --local-provider ollama "只分析当前仓库，不修改文件"

または、ユーザーレベルの構成で oss_provider を設定します。

2. Codex が Ollama または LM Studio に接続できない

まずサービスを個別に確認します。

1
2


ollama ls
curl http://localhost:1234/v1/models

次に、サービスが開始されているかどうか、モデルがロードされているかどうか、ローカルポートがファイアウォールや他のプロセスの影響を受けているかどうかを確認します。

3. ローカルモデルは常にコードを中断する

まずタスクを減らします。分析用に読み取り専用にし、ファイルを 1 つだけ変更し、実行する前に最初に計画を示します。また、Git ブランチまたはコミットポイントを使用して、元に戻せる状態を保存します。モデルの能力が不十分な場合、プロンプトワードの複雑さを増やしても、通常は根本的な問題を解決できません。

4. 構成は書き込まれますが、有効になりません。

プロジェクト .codex/config.toml が誤って書き込まれていないか確認してください。プロバイダー関連のキーはユーザーレベルの ~/.codex/config.toml で書き込む必要があります。変更後にCodexを再起動してください。

要約する

ローカルの大規模モデルを Codex で使用できるようにするには、優先順位を次のようにする必要があります。

1
2
3
4
5


Ollama / LM Studio 跑通模型
-> codex --oss --local-provider ollama|lmstudio
-> 只读任务验证
-> 设置 oss_provider 作为默认
-> 再考虑 vLLM 等 OpenAI 兼容网关

ほとんどのユーザーにとって、--oss は最も短く、最も制御しやすいエントリです。 openai_base_url は、互換性のあるゲートウェイと運用およびメンテナンス要件がすでにある高度なシナリオに適していますが、最初にユーザーレベルで構成し、インターフェイスの互換性を確認する必要があります。

参照: