「DeepSeek」タグアーカイブ

コンピュータ

RTX 3060 12GB の自宅サーバで 125B の Qwen3.8-Flash-Next を動かす ― メモリ80GBに増設と Strata 導入記

コメントする

はじめに

ローカル AI 用に専用機（DGX Spark や Mac Studio など）を買うかどうか、しばらく迷っていました。 そこへ出てきたのが Strata。総 125B パラメータの MoE モデル Qwen3.8-Flash-Next を、12GB の GPU と 64GB 程度の RAM というゲーミング PC 級の構成で動かせる推論エンジンです。

うちの常時稼働サーバは RTX 3060 12GB を積んでいて、GPU の条件は満たしています。足りないのは RAM だけ。 そこで「専用機は買わず、RAM を足して Flash-Next を動かす」方針に決め、実際にやってみました。

結論から書くと:

  • RAM は 32GB×2 を足して 80GB（DDR4-3000）。種類の違うメモリを混ぜた4枚挿しで少しハマった
  • Strata の IQ3_XXS（3bit 級）で約 62 tok/s
  • 自作の6問テストで、クラウド版 Flash-Next とほぼ同じ品質。手元の Qwen3.6-35B-A3B より明確に上

環境

項目 内容
CPU Ryzen 5 5600X
マザーボード ASRock B550M Steel Legend（DDR4・4スロット・上限 128GB）
GPU RTX 3060 12GB（ドライバ 580）
RAM（前） 8GB×4（32GB）→ Strata には全然足りない
RAM（後） 32GB×2（新規）＋ 8GB×2（既存）＝ 80GB
ストレージ NVMe SSD（モデル置き場に約80GB使用）
OS Ubuntu 24.04

このサーバでは他にも Windows VM（約8GB）や各種常駐サービスが動いているため、「Strata 35〜43GB＋VM＋OS」で 64GB だとギリギリ、という見立てでした。

なぜ Qwen3.8-Flash-Next なのか

Qwen3.8-Flash-Next は Alibaba Qwen チームのオープンウェイト MoE モデルです。

  • 総 125B／1トークンあたり動くのは 6B（512 エキスパート中 10 個）
  • n-gram 埋め込み 51B と MTP（複数トークン予測）を持つ
  • コンテキスト 262K

アクティブが 6B と小さいので計算は軽い一方、エキスパート全体を置いておく場所（RAM）が大量に要る、というタイプのモデルです。

買う前に、クラウド（API 経由）で手元の候補と比べました。題材は手元の小さな Web アプリ（PHP＋素の JS）のコードで、わざと入れたバグの特定3問・実コードのレビュー2問・実装1問（隠しテスト22件）の計6問です。

お題 Flash-Next（クラウド） Qwen3.6-35B-A3B FP8 Qwen3.6-35B-A3B q4（ローカル）
残高を超えて申請できる（abs 抜け） 正解 不正解 不正解
ロック外の読み込みで更新が消える 正解 正解 正解
10〜12月が空になる（substr 位置ずれ） 正解＋追加指摘 正解 正解
ポイント処理のレビュー 良 中 弱
保存クラスのレビュー 良 中 弱
実装（隠しテスト22件） 22/22 2/22（タイポ） 22/22

Qwen3.6 は FP8 でも q4 でも同じ誤診をしていて、差は量子化ではなくモデルの地力でした。これで「Flash-Next を手元で動かす価値はある」と判断しました。

補足: 既定設定の Flash-Next は、自由記述のレビューで思考だけに 24,000 トークンを使い切って本文が空になることがありました。reasoning_effort: medium にすると 30〜50 秒で良い回答が返ります。

メモリ増設 ― 混在4枚挿しの落とし穴

買ったもの

DDR4-3200 の 32GB×2（JEDEC 3200 CL22、XMP なし）。もともと 8GB×4 で4スロットが埋まっていたので、8GB を2枚抜いて 32GB×2 を挿し、残した 8GB×2（Corsair Vengeance RGB Pro、XMP 3200 16-18-18-36 1.35V）と合わせて 80GB にしました。

自動設定だと 2133 に落ちる

構成 速度 帯域（memtest 表示） 結果
32GB×2 のみ（自動） DDR4-3200 CL22 43 GB/s 正常
4枚（自動） DDR4-2133 CL15 28.4 GB/s 種類が混ざると JEDEC 標準の 2133 に落ちる
4枚・手動 3200 ― ― メモリトレーニングに失敗し 2133 に戻される
4枚・手動 3000 DDR4-3000 CL22 38 GB/s 合格
  • 4枚挿し（1チャネル2枚＝2DPC）で、しかも XMP を持つものと持たないものが混在すると、自動では 2133 まで下がります
  • XMP をオンにすると 8GB 用の CL16 が 32GB 側にも掛かって不安定になるので、XMP はオフ
  • 手動で 3200 を指定してもトレーニングで弾かれたので、一段落とした 3000 に

最終的な BIOS 設定

ASRock の OC Tweaker → DRAM Configuration で手動設定:

  • DRAM Frequency: DDR4-3000（FCLK 1500MHz で 1:1）
  • タイミング: 22-22-22-52
  • DRAM Voltage: 1.35V
  • XMP: 無効
  • その他: Auto

CMOS クリアや BIOS 更新をすると消えるので、手で入れ直す必要があります（メモしておくのが大事）。

memtest86+ で確認

memtest86+ v7.00 を約5時間。1パス完走＋2パス目 94% まで Errors 0 で合格としました。 80GB・3000 は 64GB・3200 に比べて帯域が約12%落ちますが、容量優先です。memtest の所要時間も容量÷帯域に比例してだいたい 1.4 倍になります。

3200 に再挑戦するなら、VDDCR SOC 1.10V → DRAM 1.40V → ProcODT 調整 → Gear Down 有効 … の順に詰めていく予定です（今は 3000 で安定運用優先）。

起動後は 78GiB と認識され、4枚とも 3000MT/s で動作。VM や常駐サービスも問題なく立ち上がりました。

Strata の導入

Strata は GitHub で公開されているオープンソースの推論エンジンです。モデルを GPU・RAM・SSD の3層に分けて置くのが特徴で、

  • GPU: よく使う部分と、アクセス頻度の高いエキスパート
  • RAM: 全エキスパート（CPU も並列で計算）
  • SSD: 大きなルックアップテーブル（n-gram 埋め込み）

という分担になっています。さらに MTP による投機的デコードで 1.6〜1.8 倍速くしています。

事前チェック

git clone https://github.com/Niko1221/Strata
cd Strata
./setup.sh --check

RTX 3060 12GB・RAM 78GB・AVX2・PCIe 4.0 x16 を認識し、IQ3_XXS は「約60GB 必要・収まる」判定でした。

インストール

./setup.sh --yes --family qwen --model IQ3_XXS --port 8081 --no-start
  • 量子化は IQ3_XXS（Q2_0 / IQ2_XS より遅いが品質重視）
  • うちでは 8080 を別サービス（Open WebUI）が使っているので 8081 に変更
  • ダウンロードは本体 47GB＋29GB、MTP 約5GB
  • この環境向けの配布済みエンジンが無く、CUDA 13.0 で自動コンパイル（約15分） が走りました

起動と実測

cd Strata && ./run-iq3_xxs.sh

OpenAI 互換 API が http://127.0.0.1:8081/v1 に立ちます（127.0.0.1 のみで待ち受け）。

項目 値
読み込み時間 約1分（エキスパート 40GiB を RAM、約5GiB を GPU キャッシュ）
生成速度 約 62 tok/s（手元の Qwen3.6 q4 は約45）
RAM 使用 56〜57GB（残り約21GB）
GPU 使用 11.4GB / 12GB

64GB だと他の常駐分と合わせてかなり厳しかったはずで、80GB にしておいてよかったところです。

品質は落ちたのか ― 同じ6問で比較

3bit 級まで量子化しているので劣化が心配でしたが、同じ6問（reasoning_effort: medium）を解かせた結果がこちら。

# お題 Flash-Next クラウド Flash-Next ローカル IQ3_XXS Qwen3.6 FP8 Qwen3.6 q4
1 abs 抜け 正解 正解（68秒） 不正解 不正解
2 ロック外の読み込み 正解 正解（40秒） 正解 正解
3 10〜12月が空 正解＋追加指摘 正解（54秒） 正解 正解
4 ポイント処理レビュー 良 良（123秒） 中 弱
5 保存クラスレビュー 良 良（117秒） 中 弱
6 実装 22件 22/22 22/22（27秒） 2/22 22/22
  • クラウド版との差は見当たりませんでした。Qwen3.6 に対する優位（原因の見極め・レビューの正確さ）もそのまま
  • レビューでは的外れな指摘も少し混ざりましたが、「問題ではない点」をきちんと切り分けるなど、全体としては良い内容
  • 1問あたり 30秒〜2分

ついでに、普段使っているクラウドモデルとも比べました。

# お題 Flash-Next ローカル DeepSeek-V4.1-Flash（クラウド） Gemma-4-31B（クラウド）
1 abs 抜け 正解 正解 △（説明が誤り）
2 ロック外の読み込み 正解 正解 正解
3 10〜12月が空 正解 正解 不正解
4 ポイント処理レビュー 良 良 弱
5 保存クラスレビュー 良 時間切れ（504） 時間切れ（504）
6 実装 22件 22/22 22/22 22/22
1問の時間 27〜123秒 72〜300秒 90〜300秒

質では ローカル Flash-Next ≧ DeepSeek-V4.1-Flash > Gemma-4-31B。DeepSeek との差は小さく、効いてくるのは「速さ（2〜3倍）」と「長い回答でもタイムアウトしない」点でした。

常駐させるための工夫 ― GPU の譲り合い

このサーバでは Strata 以外にも GPU を使うもの（画像生成の ComfyUI、Ollama のローカルモデル）が動きます。Strata はモデルを載せると GPU を 11.4GB 占有するので、そのままだと取り合いになり、最悪 OOM killer が走ります。

そこで「先に使っている方が優先」というルールにしました。

  • strata.service（systemd user）は受付だけ常駐（RSS 約210MB、GPU ほぼ 0）。リクエストが来たらモデルを読み込み（lazy load）、10分使われなければ下ろす
  • 読み込み前に小さなチェックスクリプト（strata-gpu-guard）を実行
    • ComfyUI が実際に生成中、または Ollama がモデルを載せている → 読み込まず 503（Retry-After 15）
    • ComfyUI が起動しているだけ（キューが空・GPU 使用 1GB 以下）→ ComfyUI を止めてから読み込む
    • GPU の空きが 11000MiB 未満 → 503
  • ComfyUI 側には drop-in で、起動前に Strata へ POST /unload?wait=300 を投げる設定を追加（回答中なら終わるまで待ってから下ろす）
    • 待ち時間が systemd 既定の 90 秒を超えるので TimeoutStartSec=360 も必要でした

最初は systemd の Conflicts= で「後から呼ばれた方が勝つ」排他にしていましたが、生成途中で相手を落としてしまうので、上の形に作り直しました。

つまずいたところ

エージェントから使ったら 32K では足りなかった

AI エージェント（Hermes Agent）から Strata を使おうとしたら「Something went wrong」で停止。 原因は、エージェント側が文脈長 64K 未満のモデルを受け付けない仕様だったこと。Strata は VRAM 12GB だと既定で 32K でした。

設定ファイルの --max-context を 65536 にして解決。GPU 上のエキスパートキャッシュが 5.36→4.88GiB に減りますが、速度への影響は体感ではほぼありません。

設定を変えても古い会話は前のモデルのまま

エージェントの既定モデルを Strata に変えても、既存の会話は会話ごとに保存されたモデル設定で動き続けます。新しい会話を始めると切り替わります。 さらに、要約などの裏方処理が自動で Ollama に流れていて、Ollama がモデルを載せる → 上のチェックで Strata が 503 → 自分で自分を締め出す、という状態になっていました。裏方処理の接続先も Strata に揃えて解消しました。

まとめ

  • 専用機を買わなくても、RAM を足すだけで 125B MoE が実用速度で動く時代になった。RTX 3060 12GB＋DDR4 80GB で約62 tok/s
  • 3bit 級（IQ3_XXS）でも、6問のテストではクラウド版とほぼ同等の品質
  • ボトルネックは GPU ではなく RAM 容量。DDR4 の混在4枚挿しは自動だと 2133 まで落ちるので、手動設定と memtest は必須
  • 常時稼働機で使うなら、GPU を使う他のサービスとの「譲り合い」の設計が要る

運用としては、定期ジョブ中心のメインエージェントは安定性重視でクラウド API のまま、速さが欲しい対話やコード作業は Strata、という使い分けにしています。 RTX 5060 Ti の追加は、速度が足りなくなったときか画像生成を本格化するときに改めて考えるつもりです。

参考

コンピュータ

OpenClaudeを使ってみた

コメントする

はじめに

OpenClawの導入とは別の話として、最近「Claude Code Proのトークン不足を補う方法」を探していました。

Claude Code Proは優秀ですが、トークンが足りない。かといって全てをローカルLLMに任せるのも限界がある。そこで注目したのが、OpenClaudeというアプローチでした。

OpenClaudeのコンセプト

OpenClaudeはClaude Codeのリソースをそのまま利用できる設計になっています。Claude Codeが持っているリソースをOpenClaw側からも使えるようにするもので、シームレスに作業を引き継げる可能性があるということです。

検討していた内容はこんな感じ：

  • Claude Code Proのトークン不足を補うためにOpenClawを活用
  • OpenClaudeでDeepSeek-v4-flash、v4-pro、kim-k2.6などを使い分け
  • 最適なコーディング環境を整える

具体的には、OpenRouter経由で複数のモデルを切り替えながら、コーディングタスクごとに最適なモデルを使うという戦略でした。

OpenRouter経由でのモデル切り替え

OpenClawはOpenRouterを直接サポートしています。設定はシンプル：

{
  "model": {
    "primary": "openrouter/deepseek/deepseek-v3.2",
    "fallbacks": [
      "openrouter/deepseek/deepseek-v4-flash",
      "openrouter/google/gemini-2.5-pro"
    ]
  }
}

切り替えもDiscordから：

/model openrouter/deepseek/deepseek-v4-flash

OpenClaudeを使ってみたが……

期待していたのは、「modelコマンドで気軽にモデルを変更できる」というところでした。

が、使ってみるとそう簡単にはいかないことがわかりました。

/model コマンドでモデルを切り替えると、~/.claude/settings.json にモデル設定が永続保存されてしまいます。PowerShellから素の claude を起動した瞬間にDeepSeekになってる。意図した元のAnthropicモデルに戻すのが大変でした。

alias cc-deep='claude --model deepseek/deepseek-v4-flash'
alias cc-pro='claude --model anthropic/claude-pro'
alias cc-kimi='claude --model kimi-k2.6'

エイリアス経由で凌ぐことになりましたが、それでも settings.json に model キーが書き込まれていたら手動で削除する必要がありました。

しかも本家のClaude Codeでも同じようにLLMを切り替えられる

もっと気づいておくべき点了——本家のClaude Code自体が既にLLMの切り替えに対応しているんです。

OpenClaude経由で頑張らなくても、Claude Code上で /model コマンドかエイリアスで十分モデルを切り替えられます。OpenClaudeを挟む意味がそもそもないことに気づきました。

結果：メリットを感じなかった

正直に言うと、OpenClaudeのメリットを実感できませんでした。

  1. 切り替えの摩擦が大きい — /model コマンドが設定を破壊する、エイリアスの管理が面倒
  2. レート制限が安定しない — OpenRouterの共有エンドポイントの429エラーが頻発
  3. 本家と変わらない — Claude Codeだけで十分モデルは切り替えられる
  4. Ollama + Qwen3.6で十分 — ローカルモデルの進化が予想より速く、複雑なタスクでも128Kコンテキストがあれば対応可能

OpenClaude経由のモデル切り替えは断念しました。

OpenRouterのレート制限問題

あともう一つ、OpenRouter経由でdeepseek-v4-flashを使った際に問題があったのが、レート制限です：

429 Provider returned error: deepseek/deepseek-v4-flash is temporarily rate-limited upstream.
Please retry shortly, or add your own key to accumulate your rate limits.

これがDiscordへの重複メッセージ送信を引き起こしました。同一のrunIdが429を返し、リトライのたびにDiscordへ再送信していたのが原因でした。

fallbackループが重なり、stuck sessionも発生しました。

最終的に、プライマリモデルを deepseek-v3.2 に変更し、v4-flashをfallbackに降格することで落ち着きました。

今の運用

現在の運用はシンプルになりました：

用途 モデル 場所
日常会話・軽量タスク Ollama Qwen3.6-35b-a3b ローカル（無料）
複雑な問題解決 OpenRouter DeepSeek v3.2 クラウド（数円）
コーディング特化 Claude Code（Anthropic） クラウド（Pro）

OpenClaude経由のモデル切り替えは断念しましたが、これはこれで良かったと思っています。

まとめ

LLMの使い分け戦略を探求したのは良い経験でした。得られた教訓：

  • 切り替えコストを見積もれ — 設定の破壊力、管理の手間を軽視してはいけない
  • 共有レート制限は信用するな — 無料または共有のエンドポイントに依存しない
  • ローカルモデルの進化は凄い — Qwen3.6-35b-a3bで思ったより高い品質が得られる
  • 既存ツールは思いのほか強力 — OpenClaudeのような回り道をせずとも、本家Claude Codeで十分

OpenClawのマルチモデル戦略はまだ途中ですが、「適材適所」というキーワードは揺るぎません。次はサブエージェントを挟んだ自動モデル選択に挑戦してみたいですね。

この記事は、OpenClaw + Ollama Qwen3.6-35b-a3b によって作成され、人間が微調整しました。失敗も記録に残すのがエンジニアの誠実さ。

コンピュータ

やっぱりローカルLLMでOpenClawは厳しい！

1件のコメント

はじめに

以前、ここぞと言うときに課金！OpenRouterでDeepSeek V3.2を使ってみたでは普段使いをローカルLLM、ここぞと言うときにDeepSeek-v3.2でやってみましたが、無理です(笑)

やっぱり、OpenClawで使うこと前提だと、話の文脈を理解し、必要な情報を集め、必要なコードを書く。ができないと始まらない。

そんなわけで、無償利用は完全に諦めて、DeepSeek-v3.2をプライマリモデルとして運用し、gemini-1.5-flashとローカルのGemma4-e2bをフェールオーバー（バックアップ） とする構成に変更しました。

現在のOpenClawモデル構成

プライマリモデル（メイン）

  • DeepSeek-v3.2 via OpenRouter
  • 使用コマンド: /model openrouter/deepseek/deepseek-v3.2
  • 用途: 日常のすべてのタスク
  • 成功率: 約95%のタスクで問題なく完了

フェールオーバー1（API系バックアップ）

  • Gemini via Google AI Studio
  • 使用コマンド: /model google/gemini-1.5-flash または /model google/gemini-1.5-pro
  • 用途: OpenRouterの障害時、または特定のタスク（マルチモーダル推論）

フェールオーバー2（ローカルバックアップ）

  • Ollama + Gemma4-e2b または Qwen2.5:32b
  • 使用コマンド: /model ollama/gemma4-e2b-agent または /model ollama/qwen2.5:32b
  • 用途: インターネット接続問題時、極端なコスト制約時

設定方法

OpenClaw設定例

# 環境変数設定
export OPENROUTER_API_KEY="sk-or-..."
export GOOGLE_AI_STUDIO_API_KEY="your-gemini-key"
export OLLAMA_HOST="http://localhost:11434"

# OpenClawのモデルプリファレンス設定
# ~/.openclaw/config.yaml または環境変数
export OPENCLAW_DEFAULT_MODEL="openrouter/deepseek/deepseek-v3.2"
export OPENCLAW_FALLBACK_MODELS="google/gemini-1.5-flash,ollama/gemma4-e2b-agent"

Discord/Telegramからの切り替え

通常使用:
/model openrouter/deepseek/deepseek-v3.2

画像解析が必要な場合:
/model google/gemini-1.5-flash

インターネット接続悪い時:
/model ollama/gemma4-e2b-agent

コスト実績

この構成でここ一週間ガリガリ使ってみた結果：

  • DeepSeek-v3.2: 約44Mトークン使用 → 約$8.26（約1321円）
  • Gemini flash: 約290Kトークン使用 → 約$0.01（約1.6円）
  • Ollama: 電気代のみ

$8/週 *4 = $32/月くらいですかね。Claude Code Proより多く処理できるのは間違いないですが、やっぱりClaude Code 4.6 Sonnetの方がだいぶ賢いですねぇ～。お金を気にしないならMax入るのがベストです。

OpenRouter費用

各モデルの得意分野

DeepSeek-v3.2が最強な分野

  1. コード生成＆デバッグ: 実際のプロダクションコード品質
  2. 長文分析: 128Kトークンで長いドキュメントを一気に
  3. 論理的推論: 複雑な条件分岐の理解
  4. 日本語の自然さ: 日本語での会話が非常に自然

Geminiに任せる分野

  1. 画像解析: スクリーンショットからの情報抽出
  2. マルチモーダルタスク: 画像＋テキストの複合理解
  3. クリエイティブ: アイデア生成、ストーリーテリング

Ollamaに任せる分野

  1. プライベートデータ: APIに送信したくない情報
  2. オフライン作業: インターネット接続がない環境
  3. 実験的タスク: 新しいモデル機能のテスト

今後の展望

現在の構成は非常に安定していますが、さらに最適化する方向として：

  1. 動的モデル選択: タスク内容に応じて自動で最適モデル選択
  2. コスト予測: タスク実行前にコストを見積もり
  3. モデル混合: 複数モデルの回答を比較・統合

まとめ

「DeepSeek-v3.2をメイン、GeminiとOllamaをフェールオーバー」という構成は、以下のメリットを実現します：

✅ コスパ最適化: 月5000円程度で高性能AI
✅ 可用性向上: いずれかのサービスがダウンしても運用継続
✅ 柔軟性: タスクに最適なモデルを選択可能
✅ プライバシー: 機密データはローカルモデルで処理

でもまぁ、やっぱりClaude Codeの方が賢い！

*記事作成者: この記事はOpenClaw + DeepSeek-v3.2 が作成したものを私は適宜修正しています。DeekSeek-v3.2は結構、話をふかす傾向がありますね(笑)