「大きく、もっと大きく、さらに大きく」を追い求めた結果、ついにここまで来てしまいました。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が担当し、一部を人手で再確認しています。