本文へスキップ
実績一覧へ
ツール稼働中

ローカルSLMコーディングアシスタント

Qwen 2.5、Llama 3.3、Mistral Smallをラップトップ上だけで動かすオフラインのVS Codeコパイロット。API費用もインターネット接続も必要ない。

20252.5か月
HumanEval pass@1で85%毎秒120トークンメモリ使用量8GB未満
ローカルSLMコーディングアシスタント

担当領域

プロダクト全体を構築。モデル比較の仕組み、VS Code拡張、Tauriによるデスクトップ版、性能ベンチマークの一式を作った。

期間

2.5か月

2025

技術スタック

OllamaPyTorchQwen 2.5Llama 3.3MistralTauriWebGPUVS Code LSP

ステータス

稼働中
概要

Qwen 2.5、Llama 3.3、Mistral Smallをラップトップ上だけで動かすオフラインのVS Codeコパイロット。API費用もインターネット接続も必要ない。

解決すべき課題

開発チームはAIコーディングツールを使うとき、プライバシーと能力のあいだで選択を迫られる。クラウド型のコパイロットは自社コードを外部サーバーへ送るため、医療・金融・防衛の案件ではコンプライアンス要件に反する。一方で大規模なチームでは月$500以上のAPI費用がかかり、AI支援の導入そのものが割に合わなくなる。

アプローチ

有力な小規模言語モデル3つ(Qwen 2.5、Llama 3.3、Mistral Small)を、Ollama経由で開発者のラップトップ上だけで動かすオフラインのコーディング支援を構築した。各モデルをリアルタイムに計測し、速度が要る補完はQwen、複雑な推論はLlama、メモリが限られる環境ではMistralへと自動で振り分ける。API費用はゼロで、コードがマシンの外に出ることもない。

主な機能
1

複数モデルの比較エンジン

Qwen 2.5(72B)、Llama 3.3(70B)、Mistral Small(24B)を速度、精度、メモリ使用量の観点でリアルタイムに計測し、タスクごとに最適なモデルへ自動で振り分ける。

2

VS Codeとの深い統合

LSPベースの拡張として、インライン補完、コードの説明、リファクタリングの提案、ユニットテストの生成をエディタ内で提供する。文脈を切り替える必要がない。

3

PRの自動作成

不具合のあるコードを選び、直したい内容を伝えるだけで、コードを書き換え、テストを生成し、PRまで作る。VS Codeから離れる必要はない。

4

プライバシー優先の構成

推論はすべてOllama上でローカルに動き、CUDAやAVX2で最適化される。ネットワーク通信、テレメトリ、APIキーはいずれも不要で、コードが開発者のマシンを出ることはない。

技術選定

このプロジェクトを形づくった技術選定と、それぞれを選んだ理由。

Ollama 0.3.8

AI・ML

モデルの管理とホットスワップができるため、llama.cppを直接使うのではなくOllamaを選んだ。Qwen、Llama、Mistralの切り替えが、手動でロードする場合の30秒以上に対して2秒未満で済む。

Tauri

フロントエンド

デスクトップ版の外殻にはElectronではなくTauriを選んだ。バイナリが10分の1(8MBと80MB)で、WebView2でネイティブに描画できる。LLMと同時に動く開発者向けツールでは、メモリの1MBが重要になる。

WebGPU

インフラ

CUDAのない環境向けのフォールバックとしてWebGPU推論を実装した。CUDAより40%遅いものの、Ollamaの標準のCUDA経路が対応しないAMDやIntelのGPUでも加速できる。

VS Code LSP

フロントエンド

VS Code独自の拡張APIではなくLanguage Server Protocolの上に作った。LSP互換にしておけば、Cursor、Neovim、その他のLSP対応エディタでも手を加えずに動く。

アーキテクチャ

複数モデルの振り分けとLSP経由のVS Code連携を核にした、ローカル完結型の構成。

01

入力

VS Code拡張がLSPを通じてコードの文脈とユーザーの指示を取得

02

モデルの選択

タスク分類器が複雑さ、速度、空きメモリから最適なモデルへ振り分け

03

推論

Ollamaが選ばれたモデル(Qwen / Llama / Mistral)をCUDAまたはWebGPUで実行

04

後処理

ASTで検証し、生成されたコードが構文的に正しいことを確認してから提示

05

出力

結果をVS Codeへ返す。インライン補完、差分表示、PR作成のいずれかの形で反映

技術的な壁と学び

開発中にぶつかった難所と、どう乗り越えたか。

技術課題1

モデル間のメモリ管理

問題

70BのモデルをVS Codeとブラウザと同時に動かすと24GB以上のメモリを消費し、16GBのマシンではスワップが暴れて、標準的なハードウェアでは実用に耐えなかった。

解決策

空きメモリに応じて量子化を自動で選ぶようにした。空き容量を検出し、16GBならQ4_K_M(4bit)、32GBならQ5_K_M、64GB以上ならQ8を読み込む。長い文脈に備えてKVキャッシュの積極的な刈り込みも入れた。

結果

16GBのMacBookでも、モデルのメモリ使用量8GB未満で快適に動く。量子化による性能低下はHumanEvalで3%にとどまった。

技術課題2

補完のレイテンシ

問題

モデルのコールドスタートとトークナイズの負荷で、当初の補完は800ms以上かかっていた。200〜300msで返るクラウド型のコパイロットに比べて、明らかに鈍く感じられた。

解決策

小さなドラフトモデル(Mistral 7B)を常時走らせて有力な補完を先に生成し、大きいモデルが1回のforward passで検証する投機的デコーディングを実装した。ドラフトのトークンは60〜70%が採用される。

結果

補完レイテンシの中央値は800msから280msへ下がった。ブラインドテストでは「GitHub Copilotと同じくらい速い」という評価を得た。

NEXT

LumoraTechと、次のシステムをつくりませんか。

エンジニアリングの質を重視するチームや創業者のために、こうした本番システムを構築しています。東京のチームが日本語と英語の両方で対応します。