トークンを搾り取れ！ ～ローカルLLM の構築と用途について

注意 • 本資料は、クラウド大手の値上げによって「LLMが使えなくな る」という最悪のシナリオを防ぐための、極めて重要な研究 テーマに関する技術資料である。 • 念のため断っておくが、著者が「CPU使用率100%の状態に快感を覚える」とか「ファンの轟音を聞いて安心したい」といった個人的な嗜好で実施しているわけではない。 • あくまでも事業永続のための真面目な研究活動であることを、 ここに強調しておく。

なぜ、こうなってしまったのか …

我々はボーナスタイムにいた • https://www.businessinsider.jp/article/2606-amazon-raises-ai-cloud-prices-memory-chip-costssoar/ • https://www.sbbit.jp/article/cont1/178158 • https://blog.cloudnative.co.jp/articles/cheap-ai-era-will-not-last-long/?utm_source=chatgpt.com

• https://www.businessinsider.jp/article/2606-amazon-raises-ai-cloud-prices-memory-chip-costs-
• https://www.sbbit.jp/article/cont1/178158
• https://blog.cloudnative.co.jp/articles/cheap-ai-era-will-not-last-long/?utm_source=chatgpt.com

全社をあげてAI活用を推 進していた。 もしかして、使い慣れた ころに値上げされてお金 だけむしり取られるので は?

そこのお困りの方! 実はとっておきの 魔法があります。 退役したPCをたたき起 こしてLLMマシーンに して 壊れる まで酷使 しましょう!

こうして… ローカルLLM構築が始 まってしまった…

使われない大容量メモリPCがあった

なぜか? LLMの1トークンずつの生成は メモリ帯域律速になりやすい！! ※特にbatch sizeが小さい場合。Prefillや大規模batchでは計算律速になることもある。 **律速（りっそく）** 複数の反応や工程の中で、全体の進む速さを決める最も遅い段階の こと。この段階を「律速段階」と呼ぶ。仕事や製造工程でいう「ボ トルネック」と同じような考え方。

文章はどうやって生成される？ LLMは「次に続く1トークン」を予測し、追加して、また予測する。 1 … これまでのトークン列を入力 今日は 天気が 入力中の文脈 ポイント 2 次の1トークンを予測 いい 3 追加して、また予測 今日は 確率が高い候補を1つ選ぶ 天気が いい 新しい文脈として次へ 生成は一気に文章全体を作るのではなく、 「次の1トークン」を出す処理を何度も繰り返す。 入力 → 次の1トークンを予測 → 追加 → また次を予測 …

1トークン生成のたびに何をする？ 各層を順番に通り、重みやKVキャッシュを読み出しながら行列演算を行う。 メモリ LLM（モデル） ▦ 重みパラメータ ▦ KVキャッシュ 層3 ▦ いい 層2 ▦ 次の1トークン ▦ 途中の計算結果 モデルや過去文脈の 情報を読み出す 層1 ▦ …多数の層 各層で 行列演算 1トークンを出すたびに、モデルの内部をほぼ一周するイメージ 重みパラメータ + KVキャッシュ + 中間結果を読み出しながら、層ごとに行列演算

理解してほしいこと トークンを生成するためには大量パラメー タを読み込む必要がある。 例として計算してみると [例] Qwen/Qwen3.6-35B-A3B-FP8の1トーク ン生成では約3〜4GB/token程度 つまり、 高速に読み出しができるところにデータを置けるかが重要になっている!

どこにパラメータ(モデル)を置くか!? SSDは「保管場所」。 推論中に繰り返し読む作業場所はRAMまたはVRAMが基本 SSD / HDD 保存する場所 RAM CPU推論の作業場 所 VRAM GPU推論の高速作 業場 容量は大きいが 推論中の読み出し元には不向 き 大容量にしやすい 遅いが大きなモデルを回せる 帯域が広い 収まるほど高速になりやすい CPU / GPU 計算する場所 容量の確保 大きい 小さめ 帯域の広さ 小さめ 大きい

モデルのサイズは? https://huggingface.co/Qwen/Qwen3.6-35B-A3B-FP8/tree/main

• https://huggingface.co/Qwen/Qwen3.6-35B-A3B-FP8/tree/main

パラメータを全てメモリに乗せられる! 64G モデル全体を確実にメモリに乗せることを考えると、64Gというのは非常に頼もしい。

そんな凄い環 境だとどの程 度の速度が出 るのか?

どれくらいの速度で動くの? おおよそ2～5 token/sec

遅くて..... 使えない じゃん.....

用途を考える ✕ 対話型コーディング支援 (Real-time) ✓ 非同期型バックグラウンド処理 (Async/Batch) 用途 人間とのリアルタイムなチャット 自動テスト生成、ドキュメント下書き、コード修 正 求められる要件 瞬時のレスポンス（高速GPU必須） 完了までの時間は問わない（バックグラウンド実 行） 処理が遅く、実務のテンポを削ぐため「不適格」 夜間や休日に稼働させるため 「実用の可能性あり」 実用性

時間がかかっても よいタスクならば 使い道がある!

自動テスト生成に使う • 長期間推進されているプロジェクトのUT作成に使用する事にし た。 • 対象はAngularプロジェクト。Jasmine + Karmaがテスト環境 となる。 Agentループを作成して自動的にテストを作らせる

Agent Loop 以下のようなループを作成してテストの自動生成を回した。 Shell OpenCode llama.cpp Qwen3.6 Model Angular 対象ファイルを指定 Agent / 実行制御 ローカル推論 35B total / 3B active Q4_K_M GGUF コード / test ポイント OpenCodeが操作を判断し、llama.cppがQwenを推論。Agent / 推論 / モデルを分離したローカル構成。

登場人物 Agentの実体は「制御」「推論」「モデル」「テスト実行」を組み合わせたもの。 Shell OpenCode ORCHESTRATOR AGENT 対象ファイルを列挙し、OpenCodeを順番に起動。 ファイル単位のループと終了コード管理を担当。 Qwen3.6-35B-A3B MODEL 35B総パラメータ / 約3B activeのMoE。 Agentic codingを主用途の1つとして公開。今回はQ4_K_M GGUF。 オープンソースのAI coding agent。 `opencode run`で非対話実行でき、read / edit / bash等で コードを操作。 llama.cpp INFERENCE ローカルLLM推論を担うC/C++実装。 GGUFを読み込み、OpenAI互換HTTP serverとして提供可能。 Jasmine Karma TEST FRAMEWORK TEST RUNNER JavaScriptのテストフレームワーク。 describe / it / expect でテスト仕様と期待値を記述する。 Jasmine等のテストをブラウザで実行するランナー。 Angularでは `ng test` から起動して結果を確認できる。 Angular = 今回のターゲット：対象 .ts を解析 → *.spec.ts を生成 → Jasmine / Karma で検証

結果 • 1日2〜3コンポーネント用のUT生成 • 12日間連続実行で30コンポーネント分のUT生成 • テストケースでいうと2000ケース程度 爆速ではない。 手で書いていく程度 の速度は出ている。

しかし… 生成されたファイルはエラー が出てコンパイルが通らない ….

やはり 使えない じゃん.....

役割分担で対応する ローカルLLMですべてを完結させようとしない。下書きはローカルLLMに任せてClaudeに仕上げを してもらう。

電気代 ローカルLLMといえども電気代はかかる。 60Wを24時間 × 30日、常時60W消費すると仮定する。 計算すると、 • • • 消費電力：60W = 0.06kW 稼働時間：24時間 × 30日 = 720時間 消費電力量：0.06 × 720 = 43.2kWh/月 電気料金を仮に 31円/kWh とすると、 43.2kWh × 31円 = 約1,339円/月 なので、目安は月1,300～1,400円程度。

まとめ [今回の実験結果] • 1日2〜3コンポーネント用のUT生成 • テストケースでいうと4000ケース程度/月 → 生産性は新人の人間と同じくらい • 電気代 : 1300円〜1400円/月 退役PCを「24時間働ける低速な下書き生成ワーカー」に変え、 クラウドの高性能LLMを「レビュー・デバッグ担当」として必要なときだけ 使うと、AI処理の単価を大幅に下げられる可能性がある