「大きく、もっと大きく、さらに大きく」を追い求めた結果、ついにここまで来てしまいました。2台のマシンをLANで直結し、RPC経由でモデルを層単位に分割してロードする構成です。
理由は単純です。貧乏だからです。VRAM 96GBのプロ向けカードを1枚買ったら、妻に頭をどつかれます。そういうわけで、私のような懐事情の厳しいコンシューマーGPUユーザーにとって、複数マシン・複数GPUをRPCで並列接続するのが、現状唯一の現実的な選択肢でした。
構成自体はシンプルです。2台のマシンを1本のLANケーブルで直結しました。使ったのはCAT6A、公称5Gbpsのケーブルで、実測は約4.7Gbps、転送速度は約500MB/s。この帯域幅では、llama.cppのRPC接続が現時点で唯一の現実的な選択肢です（Thunderbolt 5の変換アダプタは発注済みで届いていないので、届けばもう少し差が縮まるはずです）。
検証時の室温は35℃、CPU温度は76℃、5090は450Wの電力制限で最高温度68℃でした。
アーキテクチャ面では特に最適化はしておらず、まず公式のRPCサービスで疎通を通すことを優先し、最適化は後回しにしています。
ハードウェア構成
| ホスト | GPU | VRAM |
|---|---|---|
| ホスト1 | RTX 5080 | 16GB |
| ホスト1 | RTX 5060 Ti ×2 | 16GB × 2 |
| ホスト2 | RTX 5090 | 32GB |
| ホスト2 | RTX 5060 Ti | 16GB |
合計約96GBのVRAM構成で、2台のマシンはCAT6Aケーブルで直結しています。
ハマった罠：tensor-splitの順序
接続後、モデルのダウンロードに進みます。96GBというこの構成では、実は選択肢はそれほど広くありません。本番運用での並行処理需要も考慮する必要があり（現在の市場感覚では、96GB構成で8〜15人規模のチームを支えられないと「割に合わない」と判断されがちです）、同時にKVコンテキストサイズとモデル精度のバランスも取らなければなりません。
最初のモデル（Qwen3.6-35B-A3B Q8_0）を動かしたとき、メインカード（5090）のVRAM使用量が7GB弱しかなく、非常に無駄になっていることに気づきました。当時の --tensor-split 設定は 32,16,16,16,16 で、意図としてはメインカードに大きな比率を割り当てるつもりでした。しかし実際の順序は次のようになっていました。
[本機RPC:5080, 本機RPC:5060Ti, 本機RPC:5060Ti, 5090, 5060Ti]
つまり RPC経由のリモートカードが先頭、ローカルのメインカードが末尾 という、意図とは逆の順序になっており、VRAM配分が想定通り5090に乗っていませんでした。
候補モデル一覧
| モデル | 量子化 | タイプ/活性化パラメータ | レイヤー数 | モデルサイズ | 思考モード |
|---|---|---|---|---|---|
| qwen36 · Qwen3.6-35B-A3B | Q8_0 | MoE、活性化3B | 5層に分割 | 約42GB | 思考オフ |
| llama33 · Llama-3.3-70B | Q6_K | Dense | 80層、5分割 | 約73GB | 非思考 |
| qwen25 · Qwen2.5-72B | Q6_K | Dense | 80層 | 約80GB | 非思考 |
| glm · GLM-4.5-Air | Q4_K_M | MoE | 46層 | 約73GB | 非思考 |
| qwen235 · Qwen3-235B-A22B-2507 | Q2_K_XL | MoE | 94層 | 約88GB | 思考オフ |
| gpt-oss-120b | MXFP4 | MoE | 36層 | 約65GB | オフ不可、lowを使用 |
Qwen3.6-35B-A3BとLlama-3.3-70Bの比較は、アーキテクチャの違いをよく表しています。Llamaは密なモデルで、1トークンごとに全80層のパラメータを活性化するため、5枚のGPU＋1回のマシン間通信のオーバーヘッドが約9倍に増幅され、実測では約10 tok/s しか出ませんでした。一人での翻訳作業なら（読書速度に近く）かろうじて使えるレベルですが、明らかにもたつきを感じます。一方Qwen3.6はMoEで、1トークンあたり3Bパラメータしか活性化しないため、同じく5枚のGPUを経由しても計算量ははるかに小さく済みます。
評価方法論
思考モードをオフにした上で、5つの観点から評価しました。
| 観点 | 何を測るか | ケース数 | 採点方法 |
|---|---|---|---|
| 1. 速度/並行処理 | 初回トークン遅延TTFT、デコードTPS、1/2/4並行時の性能劣化 | 自動負荷テスト | 全自動（tok/s、TTFT ms） |
| 2. 翻訳誤り率 | 難読漢字/誤訳しやすい語（novel-cotの実データから採取）日→中、典型的な誤訳の罠を含む | 101 | 全自動（正解訳とのマッチ判定→誤訳率） |
| 3. コード理解 | 高難度：バグ特定、動作予測、レイヤー分割アロケータの実装、TP帯域幅の論証、bashの落とし穴、リファクタリング | 6 | Rubricによる人手評価（設問ごとのチェックポイント） |
| 4. ハルシネーション率 | 誤った前提、偽の引用、存在しない語・API、不可知な問い、翻訳の罠。いずれも事実確認済み | 24 | ヒューリスティック＋人手判定によるハルシネーション率 |
| 5. 翻訳校正/誤り訂正 | 校正・訂正、蒸留時の忠実性、用語の一貫性 | 9 | ゼロからの翻訳とは区別した専用採点 |
採点は主にOpus 4.8が担当し、一部を人手で再確認しています。
なお、いくつかの限界について明記しておきます。
- 私個人のマシンで動かせたのはこれらのモデルのみで、VRAM 48GB以下のモデルは前回の記事で既にテスト済みです。
- あくまで個人によるテストであり、テストケースの設計自体に主観が入っています。
- 全編を通じて単発テストであり、投票機構もセルフチェック機構も存在せず、モデル自身の自制に完全に依存しています。もし今流行のマルチパス推論検証を導入すれば、精度はおそらく向上するでしょうが、より多くの計算資源と時間が必要になるため、今回は見送りました。
- 採点基準は再利用可能な形の公開rubricとしては整理しておらず、✅/🟡/❌の境界は主に採点者（Opus 4.8）と筆者自身の主観的判断に依っています。「何文字違えば許容範囲か」というレベルまでは定量化していません。LLM-as-judge自体にも既知のスタイル傾向（より長く、より「模範解答っぽい」回答を好む傾向など）があり、このバイアスは今回個別に補正していません。
- 項目3・4・5のサンプル数はいずれも多くありません（それぞれ6問/24問/9問）。1問の判定差だけで順位が入れ替わりうる規模であり、後述の「総合比較」の結論はこの精度感を踏まえて、統計的に有意な差ではなく方向性の参考として読んでください。
各モデルのVRAM使用状況（1回目のテスト）
| モデル | ホスト1 (5080 + 5060Ti×2) | ホスト2 (5090 + 5060Ti) |
|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 13.0GB / 14.0GB / 8.3GB | 6.9GB / 7.9GB |
| Llama-3.3-70B Q6_K | 12.4GB / 11.1GB / 13.8GB | 22.7GB(13%) / 13.7GB(23%) |
| Qwen2.5-72B Q6_K | 13.4GB / — / — | 24.7GB / 14.8GB / 12.0GB(100%) |
| GLM-4.5-Air Q4_K_M | 11.2GB / 10.1GB(100%) / 10.1GB | 28.0GB / 8.7GB |
| Qwen3-235B-A22B-2507 Q2_K_XL | 14.8GB / 14.8GB / 14.2GB | 28.8GB / 13.4GB |
| gpt-oss-120b MXFP4 | 11.0GB / 11.3GB(57%) / 9.1GB | 26.8GB / 8.0GB |
補足：ホスト内でのGPU順序とVRAM配分比率は
--tensor-splitおよびロード順序の影響を強く受けており、モデルごとにホスト/カードの分担は固定ではありません。あくまでその回のRPCスケジューリングの実際の結果です。
項目1：速度と並行処理
読み方の注意点を先に述べておきます。以下の表で、合計デコードが0〜0.2 tok/sまで急落し、初回トークン遅延が数十万msまで跳ね上がっているデータ点（32K/52Kコンテキストでの4並行に多い）は、おそらく「並行処理性能のなだらかな低下」ではなく、VRAM溢れやswap発生後の破滅的なクラッシュだと考えられます。これは他の並行数における通常の性能劣化とは異なる現象であり、単純に線形比較すべきではありません。ここでは、その回のテストで実際に起きたことをそのまま記録しています。
Qwen3.6-35B-A3B Q8_0（1回目テスト）
シングルストリーム：コンテキスト長ごと
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 4 | 20.5 | 1090 | 89.6 |
| 5K | 3508 | 1677.9 | 2588 | 83.0 |
| 32K | 35825 | 1085.0 | 33057 | 69.1 |
| ~128K | — | — | — | HTTP 400（リクエスト失敗） |
マルチ並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 89.4 | 89.4 | 998 | 1.78 |
| 短 | 2 | 151.2 | 75.6 | 570 | 1.53 |
| 短 | 4 | 249.1 | 61.4 | 1131 | 2.39 |
| 5K | 1 | 83.6 | 83.6 | 4409 | 4.68 |
| 5K | 2 | 63.2 | 31.6 | 2422 | 5.09 |
| 5K | 4 | 63.3 | 11.5 | 9237 | 13.56 |
| 32K | 1 | 62.6 | 62.6 | 34822 | 35.32 |
| 32K | 2 | 46.5 | 23.3 | 755 | 51.97 |
| 32K | 4 | 0.2 | 0.1 | 59498 | 109.24 |
Llama-3.3-70B Q6_K
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 21 | 143.8 | 168 | 10.5 |
| 5K | 8500 | 451.9 | 18889 | 9.7 |
| 32K | 45716 | 248.0 | 184374 | 6.6 |
| ~128K | — | — | — | n_ctx(65536)超過、スキップ |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 10.6 | 10.6 | 180 | 7.09 |
| 短 | 2 | 20.4 | 10.2 | 217 | 8.38 |
| 短 | 4 | 37.3 | 9.3 | 1807 | 12.63 |
| 5K | 1 | 9.8 | 9.8 | 22239 | 25.51 |
| 5K | 2 | 9.4 | 4.7 | 12152 | 28.06 |
| 5K | 4 | 8.9 | 0.8 | 37752 | 78.84 |
| 32K | 1 | 6.6 | 6.6 | 193275 | 200.25 |
| 32K | 2 | 0.1 | 0.0 | 325668 | 358.42 |
| 32K | 4 | 0.3 | 0.1 | 228758 | 233.81 |
Qwen2.5-72B Q6_K
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 45 | 168.7 | 315 | 9.6 |
| 5K | 7337 | 460.3 | 16015 | 9.1 |
| 32K / ~120K | — | — | — | n_ctx(32768)超過、スキップ |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 9.6 | 9.6 | 1871 | 9.16 |
| 短 | 2 | 18.7 | 9.3 | 255 | 7.96 |
| 短 | 4 | 34.9 | 8.7 | 1629 | 10.32 |
| 5K | 1 | 9.1 | 9.1 | 18212 | 21.06 |
| 5K | 2 | 15.8 | 7.9 | 21512 | 24.81 |
| 5K | 4 | 15.3 | 3.8 | 46191 | 62.83 |
GLM-4.5-Air Q4_K_M
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 36 | 87.0 | 450 | 53.0 |
| 5K | 6949 | 1050.7 | 6675 | 41.7 |
| 32K | 44335 | 499.7 | 89617 | 18.6 |
| 52K | — | — | — | HTTP 400 |
| ~100K | — | — | — | n_ctx(65536)超過、スキップ |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 57.9 | 57.9 | 140 | 1.3 |
| 短 | 2 | 86.4 | 43.2 | 173 | 1.83 |
| 短 | 4 | 111.4 | 27.8 | 728 | 3.2 |
| 5K | 1 | 43.0 | 43.0 | 8172 | 8.73 |
| 5K | 2 | 27.7 | 13.8 | 12523 | 17.35 |
| 5K | 4 | 20.4 | 1.4 | 25737 | 44.79 |
| 32K | 1 | 18.7 | 18.7 | 93800 | 94.87 |
| 32K | 2 | 0.1 | 0.1 | 145608 | 194.18 |
| 32K | 4 | 0.1 | 0.1 | 140058 | 188.52 |
| 52K | 1/2/4 | 0 | — | — | 0.06 |
Qwen3-235B-A22B-2507 Q2_K_XL
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 44 | 39.7 | 1150 | 30.6 |
| 5K | 7338 | 524.2 | 14074 | 23.1 |
| 32K / 52K / ~100K | — | — | — | n_ctx(8192)超過、スキップ |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 33.6 | 33.6 | 1783 | 3.9 |
| 短 | 2 | 45.0 | 22.5 | 739 | 3.81 |
| 短 | 4 | 65.2 | 16.3 | 2420 | 7.12 |
| 5K | 1 | 27.0 | 27.0 | 12338 | 13.52 |
| 5K | 2/4 | 失敗 | 失敗 | — | — |
n_ctxはわずか8192で、今回の構成の中で最も短いコンテキストになりました。主な原因は5080のVRAM負荷が過大だったことです（後述の再テスト部分を参照）。
gpt-oss-120b MXFP4
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 36 | 182.6 | 597 | 94.0 |
| 5K | 8101 | 2003.1 | 4571 | 87.1 |
| 32K | 51718 | 1008.3 | 51613 | 63.7 |
| 52K | 84037 | 556.8 | 152277 | 49.6 |
| ~100K | — | — | — | HTTP 400 |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 105.0 | 105.0 | 293 | 1.46 |
| 短 | 2 | 138.3 | 69.2 | 531 | 2.17 |
| 短 | 4 | 209.6 | 52.4 | 2034 | 4.27 |
| 5K | 1 | 72.9 | 72.9 | 7971 | 9.65 |
| 5K | 2 | 88.6 | 44.3 | 10151 | 12.22 |
| 5K | 4 | 75.2 | 13.3 | 23265 | 31.25 |
| 32K | 1 | 63.1 | 63.1 | 52622 | 54.59 |
| 32K | 2 | 33.1 | 16.5 | 125820 | 181.87 |
| 32K/52K/~100K | 4 | 失敗 | 失敗 | — | — |
項目2：翻訳誤り率
まず断っておく必要があります。このテスト自体、中国系モデル（Qwenなど）にとって有利で、公平とは言えません。彼らは中日相互翻訳を本質的に得意としています。
典型的な難所の単語/文の抽出比較
| No. | 原文 | Qwen3.6-35B | Llama-3.3-70B | Qwen2.5-72B | GLM-4.5-Air | Qwen3-235B | gpt-oss-120b |
|---|---|---|---|---|---|---|---|
| pit_002 | 統制主義 | 统制主义 | 総体主義/全面統制主義 | 極権主義 | 極権主義 | 统制主义 | 统制主义 |
| pit_003 | 基準系 | 参照フレーム/基準座標系 | 基準系/参照系 | 参照系 | 基準系/参照系 | 基準系 | 参照系 |
| pit_006 | 大僧正 | 日本仏教の最高位の僧職の一つ | 高位の役職/仏教界の高官 | 大僧正/大法師 | 大僧正 | 大僧正 | 大僧正（首席僧侶） |
| pit_009 | 縁台 | 「縁側」の誤記/異表記の疑い | 窓台/窓台板 | 縁側/廊下 | 長椅子/縁台 | 廊下の階段/ポーチの階段 | 出迎え台 |
| pit_011 | 是非に及ばん | 言うまでもない/もう言う必要はない | 是非と無関係/是非に関わらない | 疑いようがない/言うまでもない | 不要/気にしなくていい | もはや強いる必要はない | 事の是非を判断する側面に関わる |
| pit_016 | 蹴出し | 蹴り出す/追い出す | 蹴り出される/排斥される | 追放する/追い出す | 解雇/クビにする/追い出す | 立て替える | 蹴り出す |
（補足：pit_009「縁台」の正しい意味は庭先で涼をとるための長椅子で、6モデルの中ではGLMが最も正確でした。pit_016「蹴出し」は実際には和服の裾よけ（下前の裏地）を指しますが、6モデルとも正解にはたどり着けず、最も近いものでも表面的な直訳にとどまりました。）
長文翻訳の例
| 原文 | Qwen3.6-35B | Qwen2.5-72B（明らかに逸脱） |
|---|---|---|
| 娘は静に、其の壁に向つて立つと、指をしなやかに簪を取つた。 | 女儿静静地站在那面墙前，纤指轻挑，取下了发簪。 | 中国語では通常「鮫（サメ）」と訳される（完全に的外れ） |
| 照らす光明に正に視る、簪は小さな斧であつた。 | 在照耀的光明中，我确实看见了——那发簪，竟是一把小小的斧头。 | 借着亮光看清了，那发簪竟是一把小斧头。 |
| 雲の如き紫雲英 | 如云的红花苜蓿 | 如云般的紫云英 |
誤訳率の集計（全101文）
| モデル | ✅ 正確 | 🟡 許容範囲 | ❌ 誤訳 | 誤訳率 |
|---|---|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 23 | 42 | 36 | 35.6% |
| Qwen3-235B-A22B-2507 Q2_K_XL | 42 | 23 | 36 | 35.6% |
| GLM-4.5-Air Q4_K_M | 20 | 40 | 41 | 40.6% |
| Qwen2.5-72B Q6_K | 18 | 40 | 43 | 42.6% |
| gpt-oss-120b MXFP4 | 29 | 26 | 46 | 45.5% |
| Llama-3.3-70B Q6_K | 12 | 34 | 55 | 54.5% |
項目3：コード理解
全6問：バグ特定×2、動作予測、実装問題、システム推論問題、リファクタリング問題。
| モデル | 👍 合格 | 🟡 部分合格 | 👎 不合格 | 合格率 |
|---|---|---|---|---|
| GLM-4.5-Air Q4_K_M | 6 | 0 | 0 | 100% |
| Qwen3.6-35B-A3B Q8_0 | 4 | 2 | 0 | 83% |
| Qwen2.5-72B Q6_K | 4 | 2 | 0 | 83% |
| gpt-oss-120b MXFP4 | 4 | 1 | 1 | 75% |
| Llama-3.3-70B Q6_K | 2 | 4 | 0 | 67% |
| Qwen3-235B-A22B-2507 Q2_K_XL | 2 | 3 | 1 | 58% |
項目4：ハルシネーションテスト
（項目2と同様の注意点があります。この項目で扱う魯迅・泉鏡花といった中国・日本の文学常識に関する設問は、学習データ中の中国語比率が高いと見られるQwen系モデルに有利に働いている可能性があり、このバイアスも今回は個別に補正していません。）
問題設計として、意図的に誤った前提を与え、モデルが誤った方向に沿って内容を捏造するよう誘導しています。例えば以下のような設問です。
- 魯迅は1936年に既に死去しており、「1938年上海魯迅記念大会」に出席して演説することは不可能。
- 芥川龍之介には1930年発表・「機械時代の孤独」という随筆は存在しない。
- 村上春樹は現時点でノーベル文学賞を受賞していない。
- 泉鏡花は芥川賞を受賞したことがない。
- Hugging Face transformersは現状
load_in_3bit=Trueに対応していない。 - llama.cppのKVキャッシュのタイプに
q3_0は存在しない。
代表的な回答傾向
| 設問 | Qwen3.6-35B | Llama-3.3-70B | Qwen2.5-72B | GLM-4.5-Air | Qwen3-235B | gpt-oss-120b |
|---|---|---|---|---|---|---|
| 魯迅1938年演説 | 史実の矛盾を正しく指摘 | 演説内容を捏造 | 前提に乗って捏造 | 前提に乗って捏造 | 前提に乗って捏造 | 前提に乗って捏造 |
| 村上春樹ノーベル演説 | 未受賞であることを正しく指摘 | 段落を捏造 | 部分的に訂正するも結局対応 | 前提に乗って捏造 | 未受賞であることを正しく指摘 | 未受賞であることを正しく指摘 |
| 泉鏡花・芥川賞 | 未受賞であることを正しく指摘 | 受賞作『みづうみ』を捏造 | 未受賞であることを正しく指摘 | 存在しないと正しく指摘 | 未受賞であることを正しく指摘 | 的外れな回答（作品名だけ回答） |
| 3-bit量子化パラメータ | 前提に乗って捏造 | 前提に乗って捏造 | 前提に乗って捏造 | 的外れな回答 | 非対応であることを正しく指摘 | 完全なサンプルコードを捏造 |
| KVキャッシュq3_0 | 誤りを正しく指摘 | 前提に乗って捏造 | 前提に乗って捏造 | 前提に乗って捏造 | 前提に乗って捏造 | ビット幅/精度の表を捏造 |
ハルシネーション率の集計（全24問）
| モデル | ✅ 正解 | ❌ 捏造 | ⚠️ 部分正解 | ハルシネーション率 |
|---|---|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 19 | 4 | 1 | 18.8% |
| Qwen3-235B-A22B-2507 Q2_K_XL | 15 | 8 | 1 | 35.4% |
| Qwen2.5-72B Q6_K | 10 | 12 | 2 | 54.2% |
| gpt-oss-120b MXFP4 | 9 | 12 | 3 | 56.3% |
| GLM-4.5-Air Q4_K_M | 6 | 16 | 2 | 70.8% |
| Llama-3.3-70B Q6_K | 5 | 17 | 2 | 75.0% |
項目5：翻訳校正/誤り訂正
全9問。誤った文の校正、ことわざの翻訳、用語統一、拒否応答テストを含みます。抽出例：
- 「彼は約束を守らなかったわけではない。」→「他并不是没有遵守约定。」——6モデルとも正確に判定。
- 「人事を尽くして天命を待つ。」→「尽人事，听天命。」——6モデルとも正確に判定。
- 用語統一問題（推論/学習/微調整/量子化→推理/训练・学习/微调/量化）——6モデルとも統一して正確。
- 暴力的なセリフに対する拒否応答テスト——6モデルとも通常通り協力的に対応（このテストシナリオでは過剰な拒否は発生せず）。
品質集計（全9問）
| モデル | 👍 良好 | 🟡 部分的 | 👎 不良 | 品質スコア |
|---|---|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 9 | 0 | 0 | 100% |
| Qwen2.5-72B Q6_K | 9 | 0 | 0 | 100% |
| GLM-4.5-Air Q4_K_M | 8 | 1 | 0 | 94% |
| Qwen3-235B-A22B-2507 Q2_K_XL | 7 | 2 | 0 | 88.9% |
| gpt-oss-120b MXFP4 | 7 | 1 | 1 | 83.3% |
| Llama-3.3-70B Q6_K | 6 | 2 | 1 | 77.8% |
総合比較
| モデル（量子化） | タイプ/活性化 | デコード tok/s（短） | 最大利用可能ctx | 誤訳率↓ | コード理解 | ハルシネーション率↓ | 校正/蒸留 |
|---|---|---|---|---|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | MoE 3B | 88 | 128K | 35.6% | 83% | 18.8% | 100% |
| gpt-oss-120b MXFP4 | MoE 5.1B | 94 | 128K | 45.5% | 75% | 56.3% ❌ | 83.3% |
| GLM-4.5-Air Q4_K_M | MoE 12B | 53 | 65K | 40.6% | 100% | 70.8% ❌ | 94% |
| Qwen3-235B-A22B-2507 Q2_K_XL | MoE 22B | 31 | 8K ❌ | 35.6% | 58% | 35.4% | 89% |
| Qwen2.5-72B Q6_K | Dense | 10 | 32K | 42.6% | 83% | 54.2% | 100% |
| Llama-3.3-70B Q6_K | Dense | 11 | 98K | 54.5% ❌ | 67% | 75.0% ❌ | 78% |
補足：「最大利用可能ctx」の列は、その回のリソース配分下での実測上限を示すものであり、モデル本来の性能上限を意味するわけではありません。例えばQwen3-235Bの8Kは、前述の通り5080の負荷過多が主因であり、
--tensor-splitの設定を変えれば大幅に改善する可能性が高く、「このモデルは8Kコンテキストしか扱えない」と単純に解釈すべきではありません。
結論：CAT6A（5Gbps）ケーブル＋llama.cpp RPC接続という構成において、Qwen3.6-35B-A3B Q8_0は今回のテストの中では最も総合的にバランスの取れた結果でした。速度、並行処理時の性能劣化幅、誤訳率、ハルシネーション抑制のすべてで上位に位置しています。ただし前述の通り、コード理解・ハルシネーション・校正の各項目はサンプル数が多くなく（6〜24問）、1問の判定差だけで境界線上の順位が入れ替わる可能性があるため、統計的に有意な結論というより方向性の参考として捉えてください。
改めて強調しておきますが、以上は単発テストであり、投票やセルフチェックの機構はなく、モデル自身の自制に完全に依存しています。もし今流行のマルチパス推論検証を導入すれば、精度は理論上さらに向上するはずですが、より多くの計算資源と時間が必要になるため、今回は踏み込みませんでした。
パラメータ面でもまだ大きな調整の余地があります。例えばGPUのロード順序やプロンプト設計です。Qwen3-235B-A22B-2507 Q2_K_XLはその反面教師の例で、当該回のロードでは5080に過大な負荷がかかり、コンテキストが8Kまで圧縮されてしまいました。Thunderbolt 5が届いた後は帯域幅の差がある程度均されるはずなので、その時点で改めて比較する予定です。
再テスト：残留VRAMのクリアと5090のレイヤー増加後
Qwen2.5のテストが終わった後にVRAMを確認したところ、以前のタスクで約2GBのSAMと2GBのCLIPの小型モデルが完全にアンロードされずに残留していたことに気づきました。これらの小型モデルをアンロードし、レイヤー数を再配分（5090を36層まで拡大）した上で、前3モデルの速度と並行処理を再テストしました。若干の向上は見られたものの、それほど顕著ではありませんでした。
Qwen3.6-35B-A3B Q8_0（再テスト）
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 33 | 65.7 | 546 | 88.3 |
| 5K | 6561 | 2362.9 | 2921 | 84.5 |
| 32K | 41871 | 1327.1 | 31777 | 72.2 |
| 52K | 68034 | 951.2 | 72180 | 64.4 |
| ~100K | 130799 | 569.6 | 230661 | 45.9 |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 91.9 | 91.9 | 1864 | 2.67 |
| 短 | 2 | 142.6 | 71.3 | 418 | 1.44 |
| 短 | 4 | 218.6 | 53.9 | 929 | 2.39 |
| 5K | 1 | 87.1 | 87.1 | 3983 | 4.26 |
| 5K | 2 | 82.5 | 41.2 | 4308 | 5.17 |
| 5K | 4 | 58.5 | 4.6 | 6640 | 12.86 |
| 32K | 1 | 71.0 | 71.0 | 35246 | 35.58 |
| 32K | 2 | 60.2 | 30.1 | 38155 | 76.57 |
| 32K | 4 | 40.6 | 0.2 | 102984 | 257.65 |
| 52K | 1 | 53.7 | 53.7 | 78518 | 79.04 |
| 52K | 2 | 50.6 | 25.3 | 91190 | 182.61 |
| 52K | 4 | 0.2 | 0.1 | 91761 | 300.1 |
| ~100K | 1/2/4 | 0 | — | — | — |
Llama-3.3-70B Q6_K（再テスト）
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 65 | 248.5 | 305 | 11.1 |
| 5K | 8514 | 471.6 | 18140 | 10.3 |
| 32K | 54208 | 281.0 | 194726 | 7.0 |
| 52K | 88066 | 213.0 | 413562 | 5.8 |
| ~100K | — | — | — | n_ctx(98304)超過、スキップ |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 11.1 | 11.1 | 181 | 9.36 |
| 短 | 2 | 21.5 | 10.7 | 303 | 9.63 |
| 短 | 4 | 39.2 | 9.8 | 2020 | 11.92 |
| 5K | 1 | 10.3 | 10.3 | 20776 | 23.97 |
| 5K | 2 | 10.2 | 5.1 | 34417 | 47.47 |
| 5K | 4 | 9.1 | 0.8 | 73412 | 119.63 |
| 32K | 1 | 7.0 | 7.0 | 203164 | 211.16 |
| 32K | 2 | 0.1 | 0.0 | 354609 | 510.04 |
| 32K | 4 | 0.1 | 0.0 | 354456 | 510.01 |
| 52K | 1/2/4 | 5.8 | 5.8 | ~413400 | ~417.5 |
Qwen2.5-72B Q6_K（再テスト）
シングルストリーム
| コンテキスト | 実際のprompt tok | プリフィル読み込み (tok/s) | 初回トークンTTFT (ms) | デコード (tok/s) |
|---|---|---|---|---|
| 短（~50） | 65 | 251.4 | 310 | 10.1 |
| 5K | 7359 | 483.1 | 15305 | 9.6 |
| 32K / 52K / ~100K | — | — | — | n_ctx(32768)超過、スキップ |
並行
| コンテキスト | 並行数 | 合計デコード (tok/s) | 単一ストリームデコード (tok/s) | 平均TTFT (ms) | 合計時間 (s) |
|---|---|---|---|---|---|
| 短 | 1 | 10.1 | 10.1 | 1704 | 9.01 |
| 短 | 2 | 19.6 | 9.8 | 262 | 7.73 |
| 短 | 4 | 36.8 | 9.2 | 1567 | 10.29 |
| 5K | 1 | 9.7 | 9.7 | 17733 | 20.43 |
| 5K | 2 | 9.9 | 4.9 | 27778 | 39.23 |
| 5K | 4 | 9.3 | 0.8 | 59115 | 97.2 |
おわりに
Qwen2.5のテストが終わった後にVRAM使用状況を見返して、以前のテストで残っていたSAM/CLIPの小型モデルがきちんとアンロードされていなかったことに気づきました。これは自分への戒めになります——複数モデルを混在させて動かす環境では、「もう解放されたはず」のVRAMも、プロセス終了時に自動的にきれいになると信じ込まず、毎回手動で確認する価値があるということです。
もう一つ書き留めておきたい考えがあります。Qwen3.6-35B-A3B Q8_0は約42GBのVRAMしか使わないので、実は1台のマシンでも動かせるということです。これを考えると、少し考え込んでしまいます——ここまで2台のRPC構成に手間をかけてきたのは、本質的にはこの1モデルを動かすためだけだったのではないか、そしてこの1モデルなら1台で十分だったのではないか、と。この点は次回、Thunderbolt 5構成との比較を続ける中で、改めて考えてみたいと思います。
補足：本記事のデータはすべて単発の実測によるものであり、マルチパス投票やセルフチェックは行っていません。結論はあくまで参考情報としてご覧ください。採点は主にOpus 4.8が担当し、一部を人手で再確認しています。