この記事でやりたいこと（30B級をローカルで回す / 開発支援がメイン）

• 30B級（30〜34B）モデルを「まずは試せる」コストで動かす
• WindowsネイティブOllama＋Arc（Vulkan）で安定運用する
• VS CodeのContinueで、チャット/レビュー/補完に活用する

※30B級はモデル/量子化/コンテキスト長で必要VRAMが変わります。 本記事では推測ですが「4bit量子化＋状況によりCPUオフロード」前提で現実的な線を狙います。

ローカルLLMのメリットとデメリット（クラウドLLMと何が違う？）

メリット

• データを外に出しにくい（プライバシー/コンプライアンス面で有利）
  プロンプトや社内ドキュメントをクラウドに送らず、手元/社内ネットワーク内で処理しやすい。
• 低遅延で安定しやすい
  ネットワーク往復（RTT）や回線混雑の影響を受けにくく、体感が安定しやすい。
• オフライン/障害耐性
  回線断やサービス障害があっても、モデルがローカルにあれば動作継続しやすい。
• 使い方次第でコスト最適化
  利用頻度が高い・入力が重い場合、従量課金より「固定資産（GPU）」の方が納得感が出ることがある。

デメリット

• 初期投資が重い（GPU/電源/冷却/筐体）
  30B級を狙うと特にVRAMが効くため、ハードウェア費用がネックになりやすい。

  Intel Arc Pro B60導入に伴いPCの電源ユニットの電源容量が350Wだった為、余裕のある電源容量が850WのMAG A850GL PCIE5を購入し交換しました。（なるべく低コストでの導入をめざしましたがIntel Arc Pro B60（約11万9千円）と電源ユニット（約1万3千円）合計約13万円程かかっています）

• 運用負荷が発生する（更新/監視/障害対応）
  ドライバ更新、モデル更新、ログ監視、バックアップなど「持ち続けるコスト」が乗る。
• スケールしにくい
  同時利用者が増えたら、その分ハード追加が必要になりやすい（クラウドほど伸縮しない）。
• セキュリティ/安全対策を自分で背負う
  公開範囲（LAN公開など）やパッチ適用、アクセス制御を怠るとリスクが増える可能性もあります。

この記事の立ち位置（開発支援が目的の場合）

本記事では「ローカルLLMで気にする事無く、レビュー/補完等を手元で回したい」という目的を優先し、 ローカルLLM＋Ollama＋Continueの構成を採用しています。（クラウドLLMも今後も使用する予定ではいます）

GPUの選定

RTX 5090/5080/4090も検討したものの、入手難や価格高騰もあり断念し、 評判は微妙ですがIntel Arc Pro B60を購入する事にしました。Intel Arc Pro B60であれば12万程度で入手可能です。

Intel Arc Pro B60は、Intelのワークステーション向け「Arc Pro」系GPUの1つで、**VRAM 24GB（GDDR6）**を積んだ“プロ用途・安定運用寄り”のディスクリートGPUです。特に AI推論（ローカルLLMなど）や制作/設計系ソフトでの利用を想定し、ISV認証を意識したワークステーション向けドライバーが用意される、という位置づけです。

当初案（ミニPC/既存サーバー/外出ノート）＋eGPU（外付けGPU）で構成の見送り理由

• ミニPC：ミニPC自体がそれなりの価格となってしまい思ったよりトータルコストが上がりがちで見送り
• 既存サーバー（Tx1310[xeon cpu e3-1225 v6 3.30GHz メモリ　16G]）：外付けGPU未対応で見送り
• 外出時に使用してるノートPC　CF-QV1　Core i5 1135G7(Tiger Lake)/2.4GHz/4コア メモリ 8GB： USB4/TB eGPU経由だとReBARが効かない事例がコミュニティで報告されており見送り

コミュニティ報告（公式ではない）ですが、「不確実性のある経路」は避けるのが無難、という判断です。

最終構成：メイン開発機にArc Pro B60を“LLM専用”で搭載

マシンスペック

• CPU: Core i7-8700
• マザボ: Z390-A PRO
• メモリ: 96GB
• GPU: Intel Arc Pro B60（LLM専用）
• ディスプレイ表示: iGPU[CPU内蔵GPU]（UHD Graphics 630）

BIOS：Above 4G Decoding＋Re-Size BAR

Arc系で重要になりがちなため、BIOSでAbove 4G DecodingとRe-Size BARを有効化。
また、通常表示はiGPU、Intel Arc Pro B60はLLM専用になるようBIOS側でiGPU優先にしています。

WindowsネイティブOllamaで実装（仮想化と衝突させない）

メイン開発機ではVMware/VirtualBoxを使っているため、WSL2/Hyper-V周りの相性を避けて WindowsネイティブのOllamaで運用する事にしました。 Ollamaは環境変数で待受やGPU選択ができます。

Ollama＋Vulkan設定（GPU番号の確認〜環境変数）

1) VulkanでArc Pro B60を認識しているか確認

vulkaninfo --summary

ここでArc Pro B60を確認し、GPU番号（ID）を控えます。

2) 環境変数（例）

OllamaはOLLAMA_HOSTで待受アドレスを設定できます（LANから使うなら重要）。 Vulkan GPU選択はGGML_VK_VISIBLE_DEVICESが公式に案内されています。

OLLAMA_VULKAN=1 # Vulkanを使用

GGML_VK_VISIBLE_DEVICES=0　# Vulkan GPU選択（例：0番を使う）



# LAN公開する場合（固定のIPではなく0.0.0.0も可能です）

OLLAMA_HOST=192.168.1.10:11434

動作確認は、OllamaのUIやCLIで推論が返ること、そしてタスクマネージャーやログでGPUが使われていることを確認します。（server.logにusing device Vulkan0 (Intel(R) Arc(TM) Pro B60 Graphics)と出力されますので使用されているGPUを確認できます）

VS CodeのContinueで開発に使う（導入目的の本丸）

ContinueはVS Code内で使えるAIアシスタントで、ローカルのOllamaに接続して チャット相談・コードレビュー・修正提案などをやりやすくしてくれます。 Continue公式でも、Ollamaを使ったローカルAI開発ガイドが用意されています。

1) Continueを入れる

1. VS Codeの拡張機能から「Continue」をインストール
2. Continueサイドバーを開いて、設定（Local Config）を開く

Continueのローカル設定はconfig.yamlで管理され、Windowsだと %USERPROFILE%\.continue\config.yamlに保存されます（公式）。

2) Continueのconfig.yamlでOllamaに接続する

Ollamaが同一PCで動いているなら、基本はlocalhostでOK。 もし「メイン機（Ollamaサーバー）をLANに公開して、別PCのVS Codeから叩く」なら apiBaseにサーバーのIPを入れます（Continue公式の例）。

name: My Local Config

version: 0.0.1

schema: v1



models:

  - name: "Local 30B (Ollama)"

    provider: ollama

    model: 使用するモデル

    # リモートOllamaの場合のみ指定

    # apiBase: http://192.168.1.10:11434

※モデルの取得はContinue公式ガイドでもollama pull推奨です（ollama runではなく）。

3)Continueの「roles」とは？（chat/autocomplete/embed/rerank/edit/apply/summarize）

Continueのrolesは、ざっくり言うと 「このモデルをContinueのどの機能で使うか」を指定するスイッチです。 1つのモデルを全部に使ってもいいし、用途ごとにモデルを分けてもOK（例：チャットは高精度、補完は軽量高速）。

• chat：チャット/エージェントでの対話用。 設計相談、実装方針、コードの読み解き、Q&Aなど「会話ベース」の中心。
• autocomplete：Tab補完（インライン補完）用。 1〜数行の続きや、コメントからの実装など「低レイテンシが欲しい」用途。
• edit：選択範囲の編集（インライン編集）用。 「この関数を例外処理込みで直して」「この部分だけ別実装に」など、範囲指定の書き換え。
• apply：差分（patch/diff）を“適用”する編集用。 続けて複数ファイルを編集したり、提案された変更を取り込む流れで使われます（編集系の一部として動くイメージ）。
• embed：埋め込み（embeddings）生成用。 コードベース検索や@codebase的な「関連箇所を探して文脈に入れる」ためのベクトル化で使う役。
• rerank：検索結果の並べ替え（rerank）用。 いったん拾った候補（ファイル断片や文書）を「質問により近い順」に並べ替えて精度を上げる役。
• summarize：要約用…の想定だが、 公式ドキュメントでは「現時点ではsummarize roleは使われていない」とされています。 そのため指定しても効かない/影響が薄い可能性があります。

rolesの設定例（まずは開発支援の王道：chat/edit/apply/autocomplete）

最小構成なら、まずは「chat＋edit＋apply」あたりが実用的。 さらに快適さを狙うなら「autocomplete」も同じモデルに付けるか、軽量モデルを別で割り当てます。

models:

  - name: "Local 30B (Ollama)"

    provider: ollama

    model: deepseek-r1:32b

    roles:

      - chat

      - edit

      - apply

      - autocomplete

用途別にモデルを分ける例（コスパ/体感速度を上げたい人向け）

models:

  - name: "Chat/Edit (高精度)"

    provider: ollama

    model: deepseek-r1:32b

    roles: [chat, edit, apply]



  - name: "Autocomplete (軽量高速)"

    provider: ollama

    model: qwen2.5-coder:7b

    roles: [autocomplete]

※rolesで指定できる値やデフォルト、summarizeの注意点はContinue公式のconfig.yaml Referenceに記載があります。
※config.yamlでプロンプト含め細かく設定できます詳細は公式ページhttps://docs.continue.dev/referenceを参照ください
※config.yamlはもう少し個人的にカスタマイズしていますがchat、edit、applyは30bモデル、Autocompleteは7bモデルを使用する形で使い始めましたが結構快適に使用できています。もう少し使い込んでconfig.yamlの微調整が終了すればおすすめのconfig.yaml設定例も記載できたらと思っています。

4) 使いどころ（開発支援の定番）

• 実装方針の相談（設計のたたき台）
• 既存コードのレビュー（可読性/潜在バグ/命名）
• ユニットテスト生成（境界値/例外系を増やす）
• リファクタ（関数分割/責務整理/ログ整理）

5) つながらない時のチェック

• OllamaがLAN待受しているか（OLLAMA_HOST）
• FWで11434を塞いでいないか
• Continue側のapiBaseが正しいか（http/ポート/末尾）
• モデル名・タグ（例：deepseek-r1:32b）が一致しているか