RTX 3060 12GB×2、RAM約32GB。この環境で35B級のローカルLLMをOpenCode経由で実際に動かしてみると、「動くか動かないか」よりも「何を任せるか」の設計が結果を大きく左右することが分かりました。ある個人開発の株価予測アプリ実装で得た実測データをもとに、ローカルLLM運用の勘所を整理します。

まず結論：コンテキスト長は大きいほど良いわけではない

OpenCode×Ollamaの組み合わせでは、64K以上のコンテキストが推奨される場面があります。しかし今回の環境（GPU 12GB×2・RAM32GB）で35B級のQ4量子化モデルを動かすと、コンテキストを広げるほどCPUオフロードが増え、探索・レビューの待ち時間が伸びる結果になりました。

「32GB RAMだから32Kは無理」という単純な話ではありません。実際に常駐はしました。ただしCPUオフロードを伴うため、横断的なリポジトリ探索や長いエージェント実行を安定して終えられるとは限らない、というのが実測結果です。コンテキストを絞るなら、プロンプト側で対象ファイルと受け入れテストを短く固定する必要があります。

reasoningEffortを切ると、編集開始が3分55秒→25秒になった

今回使ったのはornith-1.5:35b（35.5B、Q4_K_M、約22GB）です。OpenCode向けの派生プロファイルを作り、まず素の状態で試したところ、初回ロードに約3分55秒かかりました。64Kコンテキストではollama ps上でGPU約79%・CPU約21%という配置でした。

最大の発見は、推論を強くすると、編集より前にトークンを使い切ってしまうことでした。OpenAI互換の経路でreasoningEffort: noneを明示すると、同じ35Bモデルが約25秒で編集開始まで到達するようになりました。

model: ollama/ornith-1.5:35b-opencode
reasoningEffort: none

これは能力が急に上がったわけではなく、内省（思考）出力に消えていたトークン予算を、ツール呼び出し（ファイル編集）に回せるようになったためです。ローカルLLMをOpenCodeのエージェントとして使う際、まず疑うべき調整ポイントの一つだと分かりました。

ただし副作用もあります。素早く編集は始まるものの、初稿には重複クラス・型注釈漏れ・省略されたimportなどが残りました。編集できた＝完成ではありません。テスト結果を見ながら1論点ずつ、対象ファイルだけを再読させる反復が必要でした。

広いタスクは失敗しやすい。渡し方を変えると通った

ローカルLLMに大きな仕事（「〇〇を実装して」のような広い依頼）を任せると失敗しやすい一方、次の5点を必ず渡すようにすると、35B級でも実装ループへ入りやすくなりました。

• 目的：何を満たすための変更か
• 対象ファイル：読んでよい／変更してよいファイル
• 変更禁止範囲：触らない層・API・生成物
• 受け入れ条件：具体的な入出力・境界条件
• 実行テスト：focused pytest・lintツールなど

例えば「walk-forward foldsを実装して」ではなく、対象ファイルを1〜2本に絞り、具体的な数値（分割日数など）とテストの合格条件まで指定する形にしたところ、限定実装ではfocused pytestが通り、lint・型検査も通過しました。

ローカルLLMに大きな仕事を渡すほど、モデルの知識量より「探索・思考・ツール呼び出しの予算配分」が問題になります。対象を狭め、テストを先に置くと、35B級でも実装ループへ入りやすくなります。

モデル比較：このPCでの実装主担当はQwen3-Coder 30Bだった

もう一つ見落としがちな点として、設定ファイルに書いた温度パラメータが、実際にはサーバー側に別の値で渡っていたことがありました。OpenAI互換経路でtemperature=0.7と設定したはずが、Ollamaのサーバーログを確認すると実際には1.0で渡っていたのです。設定ファイルを読むだけでなく、サーバーログでリクエストの実値を確認する必要があります。

「モデル一覧にいる」と「実際に使える」は別だった

OpenCode Goの無料枠モデルの一つを試したところ、モデル一覧には存在し初期応答もありましたが、実装プロンプトを投げると応答が返らないことがありました。

ここで「壊れている」「設定が悪い」と推測せず、最小プロンプトとDEBUGログで確認する手順を踏みました。

opencode run "Reply with exactly: READY" --dir <project> --agent build --model <model-id> --pure --print-logs --log-level DEBUG

ログを見ると、原因は明確でした。週次の利用上限に達していたのです。つまり、モデルリストへの掲載や初期画面での応答は、実際の推論可否・残量を保証しません。

無料モデルを「使えるか」判断する順番は、モデル一覧 → 最小応答 → DEBUGログ → 実装タスクです。評判や一覧の表示だけを根拠に実装計画を組まないほうがよいと分かりました。

30秒で戻ってきても、処理は止まっていない

ターミナルの観測が約30秒で戻ってくることがありますが、OpenCodeやOllamaのプロセスがその瞬間に止まっているとは限りません。区別すべき時間は3種類あります。

HTTP待機を10分程度に伸ばす設定を加えると安定しましたが、これは推論速度を上げるものではありません。実行時間が長いモデルはバックグラウンド実行とログ監視の対象にし、完了判定は「エージェントの自己申告」ではなく、差分・テスト終了コード・成果物の存在で行うのが安全です。

まとめ

• コンテキスト長は環境のVRAM/RAMとのトレードオフ。大きくすれば良いわけではない
• reasoningEffort: noneで、思考に消えるトークン予算を編集作業に回せる（ただし出力の粗さは増える）
• ローカルLLMには「目的・対象ファイル・禁止範囲・受け入れ条件・実行テスト」の5点セットで小さく渡す
• 設定ファイルの値は、サーバーログで実際に渡っている値を確認する
• 無料モデルの利用可否は、一覧表示ではなく最小応答＋DEBUGログで判断する
• 30秒の観測上限とモデルの実行時間は別物。バックグラウンド化とログ確認で区別する

いずれも「動かない」で終わらせず、ログと最小再現で原因を切り分けたことで、35B級ローカルLLMでもOpenCode経由の実装補助として実用範囲に収められました。