V100 12×32GBクラスタのアップデート／法務文書作成のローカルAI

V100サーバーの件について弁護士からのアップデートです。みなさんのうち何人かが、粉塵が落ち着いた後に私が実際に何を動かすことになったのかを聞いていたので、ここに載せます。相変わらず弁護士です。相変わらずClaude Code経由で全体を回しています。まだ何をしているのか完全には自信がありませんが、少なくとも今は動きます。前回「動いていない」ことを思えば、私はそれだけでも十分でした。

まず、ハードウェアが計画に追いつきました。最後の2台のV100が導入されたので、私が約束していた「最終形」が本当に実現しました。Threadripper Pro上に、12台のV100-SXM2 32GBです。GPUはボードAが{4,5,8,9}、ボードBが{6,7,10,11}。NVLinkペアが{0,1}で、{2,3}は混在ペアで片方が16GBです。別のNVLinkボードにまたがってモデルを分割するとスループットが急落します（ボード間のホップはNVLinkではなくPCIe/NUMAです）なので、すべてのモデルを1つのボードの中に閉じ込めています。これは高い授業料を払って学びました。

それと、ええ、2台目の筐体も作ってしまいました。EPYC 7302P、512GB RAM、4x RTX 3090 + 2x V100-PCIeです。中年の危機は予定通りです。

より大きな変更点は、ローカルモデルについてvLLMをやめたことです。vLLMが悪いからではありません。私が実際に欲しいのはMoEのGGUFで、Volta上のvLLMはそれに対して行き詰まりだからです（FP8/AWQ/MarlinはいずれもSM75+が必要、GPTQカーネルは7.0で壊れています）。そこで全部をllama.cppに移しました（メインライン。最近のビルドで、Gemmaのチャットパーサのバグがようやく直っており、長いプロンプトがぐちゃぐちゃにされていたのが直りました）。

ここからが、最初の投稿が示唆していたのと真逆のポイントです。V100では、密な（dense）モデルは罠です。有効な速度を得られるのはMoEだけ。ざっくりしたデコード数 — Q8 GGUF、Q4 KVキャッシュ、flash-attnは有効、4枚構成のボードを1つ、実際の法務の下書きプロンプトに対して（文脈が数千トークンで、「hello」のような5トークンではありません）：

モデル	タイプ	tok/s（デコード）
Gemma-4-26B-A4B	MoE	約113
Qwen3.6-35B-A3B	MoE	約82
Qwen3.5-122B-A10B	MoE	約50
任意のdense 27-32B	dense	約20-28（私の40トークン下限を下回るので割に合わない）
dense 約128B	dense	約9（無理）

つまり、122B/10Bの推論モデルはV100を4枚使うと約50 tok/sで動きます。しかも、前回の投稿でvLLM上でdense 32Bが出せていたより速いです。そして長いコンテキストでもそれを維持します（Gemmaは崩れないまま25kトークン超まで押せました。denseモデルは詰まりました）。これで全てが再定義されました。私は大きなdenseウェイトを追いかけるのをやめ、システムをMoE中心に組み直しました。

実際に動かしているもの（あなたが求めていた構成）:
これはチャットに対して1つのモデルが答えるのではありません。複数のローカルモデルに法務タスクをルーティングするオーケストレータで、それぞれが自分専用のボードに固定されているため、GPUを巡って争いません。最も重い処理（宣誓供述書やモーションの丸ごと対応、取材（インテーク）から文書化まで）を走らせると、2台の筐体にまたがって合計16枚のGPUが点灯します：

- 仕事の主力となる下書き — ボードA {4,5,8,9} 上のQwen3.6-35B-A3B
- 重い推論 + 高いステークスの下書き — ボードB {6,7,10,11} 上のQwen3.5-122B-A10B
- {0,1}ペア上の小さな「そもそも根拠があるかどうか」のゲートモデル
- 私の下書きを攻撃することが唯一の役目であるアドバーサリアルなレビュア — {2,3}ペア上
- 2台目の筐体の3090上でOllama経由のGemma-4-26B（財務/抽出）と、小さなQwen（ルータ）

順番のパイプラインなので全員が同時に殴りに行くわけではありませんが、16枚すべてが常駐状態（resident）です。軽い作業はずっと少ない計算資源で済みます。編集とBatesスタンプ用のエクジビット統合は純粋にCPUで、GPUは使いません（PyMuPDF + Tesseract）。単純な要約は主にGemmaとルータに当たるだけです。

正直な部分（このサブが前回も私を正直にさせてくれたので）：
- ローカルモデルは引用や日付を幻覚として作ります。自信満々に。そこで、弁論の草案に含まれるあらゆる引用、日付、Bates番号を実際の一次資料と突き合わせて検証し、根拠づけできないものは止めるように、アドバーサリアルなレビュアに加えて、検証器を作らねばなりませんでした。ローカルでの下書きは二相性です。時には「捏造はしない」と正しく拒否する一方で、時には全く新しい、日付付きの年表を作っておいて、同じ息で「自分が発明したものは何もない」と断言します。そのゲートと私なしでは、最終文書に触れさせません。
- 私が見つけた一番バカなバグ：私自身のパイプラインが約79%汚染（poison）されていました。証拠バンドルを組み立てる処理が、クライアントの証拠としてではなく、自分自身の過去の出力を掬い上げていたためです。つまり、モデルは以前に自分が書いた雑な内容に対して「根拠づけ」してしまっていました。ある時点では、Bates番号としてRTX 3060を引用していました。まあ、当然ですよね。それを、ビルダーが自分の尻尾を食べるのをやめるよう修正し、削除して洗い流しました。RAG/エージェント系のパイプラインを動かしているなら、ぜひ自分のコンテキストウィンドウに「実際に何が入っているのか」を文字通り見に行ってください。私のは鏡の間（hall of mirrors）で、私は気づいていませんでした。
- さらに、ローカル専用で動かすよう指示したときに、静かにクラウドモデルへフォールバックしてしまうのも拒否するようにしました。ローカルでそのステップができないなら、裏でAnthropicに電話して誤魔化すのではなく、「できない」と名前付きで言います。

それでも、最初の投稿で私が欲しかったのと同じもの — 私のように書いて、退屈なフォーム記入や定型パターンを処理できるモデル — が欲しいです。かなり近づきました。今のシステムは私の編集を「修正データ」として取り込みます。これは本物の微調整セットの始まりです。まだQLoRAのトリガは引いていません。同じ疑問が残っているので、そして本当に助言が欲しいので質問します：
- このハードウェアでのQLoRA（V100、bf16なし、FA2なし）について。35B-A3BのMoEベースを掴みに行くべきですか？ それとも、実際に学習して運用できるdenseの約14Bを微調整し、重いサービングのためにMoEは温存した方が賢いですか？
- VoltaでMoEを提供している人で、llama.cppより速いものを見つけた人はいますか — ik_llamaとか、ほかには？ そしてQ4より良い長コンテキストのKVストーリーはありますか？
- 私は愚かにも、すべてを35Bで回せるのに、50 tok/sで122B-A10Bを置いておいていますか？

私が何を間違っているのか教えてください。