本稿は前回の検証記事の補足であり、5GbE・偽TB5・USB10GBps という3本の回線で6モデルを測定し、通信速度の違いが性能にどう効くかを比較したものです。
当初はTB5の検証だけを想定していました。線を買って、挿して、測って、終わり——数時間で片付くつもりでした。
ところがTB5はASMedia4242というチップの部分で、エンドツーエンドの導通に失敗しました。最初は納得がいきませんでしたが、最終的には諦めました。どうやらASM870/870EはDMA経由のエンドツーエンド転送を、ASMedia4242モジュール自体を交換しない限り実現できないようです。
そこで後からUSB10GBpsを買い足しましたが、残念ながらTB5はUSB10GBpsにも非対応で、USB-C10（実測7.2Gbps程度）でしか使えませんでした。Realtekを手動でインストールしてプロトコルを調整する方が、まだ簡単でした。TB5とUSB10gbpsのデバッグ過程は、また別記事にまとめるかもしれません……
こういった諸々のトラブルがあったので、家庭環境には似つかわしくない「デプロイ」という重い言葉をあえて使いました。
前置きはこのくらいにして、本題に入ります。
今回は6モデルで速度・並行処理のテストを行いました。最適化はまだ行っておらず、それは今後の課題です。丸1週間かけて調整し、実測には72時間を要しました。室温は35℃前後でした。
「モデル×回線」の組み合わせごとに1回のlaunchしか回していません。主な誤差要因は温度ドリフトだと考えています（昼夜の温度差が明確に出ていました）。精度に関する補足は末尾にまとめます。
今回も追加の最適化は行っていませんが、前回のバグを2つ修正しています。
- 前バージョンのスクリプトで、モデルによって入力長がズレるバグを修正
- ctxを動的に割り当て、より大きなKVを確保できるようにした
回線
| 回線 | 実際のプロトコル | A→B | B→A | 双方向合計 | 無負荷ping |
|---|---|---|---|---|---|
| 偽TB5 | TB5ケーブルだが、USB4 40Gbpsにネゴシエーションが落ちる。マザーボード統合のASMedia ASM4242はUSB4 40Gまでしか対応せず、TB5本来の80Gではない。リンク層は40Gb/s = 20Gb/s × 2レーンでネゴシエート | 4.38 | 4.76 | 6.64 | 0.224 ms |
| 5GbE | CAT6A直結 | 4.71 | 4.71 | 9.38 | 0.084 ms |
| USB 10GbE | TB5非対応のためUSB-C 10Gのみ。Realtek RTL8159 10GbE、Cat6a直結 | 7.28 | 7.28 | 11.93 | 0.136 ms |
（帯域の単位はGbps）
偽TB5の片方向帯域は5GbEとほぼ同じだが、双方向合計は29%低い——thunderbolt-netのシングルリングDMAエンジンが全二重を頭打ちにしている。
別途、16KBのリクエスト-レスポンス往復も測定した：p50 856µs、うち固定オーバーヘッドは326µs。
1. 回線差異まとめ表
prefillは相対的な向上率、decodeはトークンあたりの遅延増分で示す。基準 = 5GbE。
| モデル | prefill（短 / 5K / 32K / 52K / 100K） | decode Δms/token |
|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 偽TB5 −2% / −8% / −5% / −3% / −2% USB10G +28% / +8% / +13% / +15% / +17% |
偽TB5 +1.59 / +1.71 / +1.63 / +1.77 / +2.14 USB10G −0.86 / −0.82 / −0.97 / −1.01 / −1.06 |
| gpt-oss-120b MXFP4 | 偽TB5 −30% / −8% / −3% / −3% / −0% USB10G −9% / +8% / +13% / +15% / +16% |
偽TB5 +1.46 / +1.71 / +1.63 / +1.65 / +2.13 USB10G −0.48 / −0.33 / −0.17 / −0.51 / −0.66 |
| GLM-4.5-Air Q4_K_M | 偽TB5 −18% / −4% / −2% / −1% / −0% USB10G −3% / +5% / +6% / +5% / +5% |
偽TB5 +1.77 / +1.78 / +1.71 / +1.83 / — USB10G −0.27 / −0.18 / — / — / — |
| Qwen3-235B-A22B Q2_K_XL | 偽TB5 −12% / −6% / −3% / — / — USB10G −5% / +2% / +4% / — / — |
偽TB5 +2.23 / +2.93 / +2.56 / — / — USB10G +0.21 / +0.44 / — / — / — |
| Llama-3.3-70B Q6_K | 偽TB5 −5% / −1% / −1% / −0% / +0% USB10G +1% / +4% / +5% / +5% / +5% |
測定分解能以下 |
| Qwen2.5-72B Q6_K | 偽TB5 −6% / −1% / −1% / — / — USB10G +0% / +4% / +5% / — / — |
測定分解能以下 |
decode欄の「—」は、差分が量子化1目盛り以内に収まり読み取れなかったマス（スクリプトは小数点1桁までしか記録しておらず、9 tok/s付近では1目盛りが1.2msに相当する）。2つのdenseモデルは全行がこの状態——1.7msを足し戻して小数点1桁に丸め直すと、8マス中5マスが実測値とぴったり一致し、「影響なし」という仮定では1マスしか一致しない。同じオーバーヘッドが97〜204msの中に埋もれると1〜2%にしかならず、まさに記録精度の下限に引っかかっている。
単発ストリームはすべて正常完走しておりエラーなし。減衰曲線も滑らか（Llama-3.3の短→100Kは100%→94%→74%→63%→48%）で、KVの増加に沿っている。OOMが出ているのはdenseモデルの52K×4と100K×2のみ。
読み取れる部分：偽TB5は全表で劣位、しかもその劣位幅はモデルの速度にも文脈長にも依存せず、1.5〜2.9ms/tokenでほぼ一定。USB10Gはほとんどのマスでわずかに速いが、Qwen3-235Bだけ逆方向。
2. 単発ストリーム
USB10Gのみ掲載。3回線の相対関係は上表を参照。
decode（tok/s）
| モデル | 短 | 5K | 32K | 52K | 100K | 100K/短 |
|---|---|---|---|---|---|---|
| gpt-oss-120b MXFP4 | 85.5 | 78.3 | 60.3 | 53.3 | 39.4 | 46% |
| Qwen3.6-35B-A3B Q8_0 | 78.0 | 74.8 | 67.2 | 61.6 | 50.8 | 65% |
| GLM-4.5-Air Q4_K_M | 51.5 | 41.4 | 20.7 | 15.1 | 9.1 | 18% |
| Qwen3-235B-A22B Q2_K_XL | 37.9 | 30.1 | 15.5 | ❌ 400 | ❌ 400 | — |
| Llama-3.3-70B Q6_K | 10.3 | 9.7 | 7.6 | 6.6 | 4.9 | 48% |
| Qwen2.5-72B Q6_K | 9.3 | 8.9 | 7.1 | ❌ 400 | ❌ 400 | — |
prefill（tok/s）
| モデル | 短 | 5K | 32K | 52K | 100K |
|---|---|---|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 300 | 2528 | 1756 | 1332 | 844 |
| gpt-oss-120b MXFP4 | 400 | 2221 | 1536 | 1134 | 693 |
| GLM-4.5-Air Q4_K_M | 295 | 1016 | 586 | 394 | 214 |
| Qwen3-235B-A22B Q2_K_XL | 146 | 676 | 494 | — | — |
| Llama-3.3-70B Q6_K | 293 | 419 | 301 | 243 | 165 |
| Qwen2.5-72B Q6_K | 248 | 425 | 305 | — | — |
TTFTは単独の列にしていない。TTFT ≈ prompt_tok ÷ prefill tok/sで、例えばQwen3.6の100Kでは100000 ÷ 844 ≈ 118s、実測は120sだった。
3. 並行処理
利用可能な境界（3回線とも結果が一致するため1つだけ記載）
単発decodeが1 tok/s未満になったものはクラッシュとみなす——これは緩やかな劣化ではなく、VRAM溢出後の破滅的な落ち込みである。400 = ctxの壁、500 = 溢出エラー。
| モデル | 短 | 5K | 32K | 52K | 100K |
|---|---|---|---|---|---|
| Qwen3.6-35B-A3B Q8_0 | 4 | 4 | 2（4並行崩壊） | 2（4並行崩壊） | 2（4並行崩壊） |
| gpt-oss-120b MXFP4 | 4 | 4 | 2（4並行崩壊） | 2（4並行崩壊） | 2（4並行崩壊） |
| GLM-4.5-Air Q4_K_M | 4 | 4 | 2（4並行崩壊） | 2（4並行500） | 1（2並行失敗） |
| Qwen3-235B-A22B Q2_K_XL | 4 | 4 | 1（2並行失敗） | ❌ 400 | ❌ 400 |
| Llama-3.3-70B Q6_K | 4 | 4 | 2（4並行崩壊） | 2（4並行500） | 1（2並行失敗） |
| Qwen2.5-72B Q6_K | 4 | 4 | 2（4並行崩壊） | ❌ 400 | ❌ 400 |
真の並行率 overlap（5GbE、2並行/4並行）
| モデル | 短 | 5K | 32K | 52K | 100K |
|---|---|---|---|---|---|
| gpt-oss-120b | 1.0 / 1.0 | 1.0 / 0.5 | 0.1 / 0.0 | 0.0 / 0.0 | 0.0 / −0.2 |
| Qwen3.6-35B-A3B | 1.0 / 1.0 | 0.8 / 0.3 | 0.1 / 0.0 | 0.0 / 0.0 | 0.0 / −0.2 |
| Llama-3.3-70B | 1.0 / 1.0 | 0.6 / 0.3 | 0.1 / 0.0 | 0.1 / — | — |
| Qwen2.5-72B | 1.0 / 1.0 | 0.6 / 0.3 | 0.1 / 0.0 | — | — |
| GLM-4.5-Air | 1.0 / 1.0 | 0.5 / 0.3 | 0.1 / 0.0 | 0.0 / — | 0.0 / — |
| Qwen3-235B | 1.0 / 1.0 | 0.5 / 0.2 | —（2並行で即失敗） | — | — |
クライアント側は本当に並行：concurrency_onceはNスレッドで同時にN個のリクエストを発行し、各トークンを同一の絶対時計上に配置してoverlap（N並行が同時にdecodeしている時間の割合）を算出する。サーバー側が本当に並行処理できているかは、この表が定量的に答えている。
overlap=1.0 は完全な真並行 ｜ =0 は完全逐次（見せかけの並行）｜ <0 は逐次より悪い（KV不足による追い出し・再計算の繰り返し）。
メカニズム：llama.cppのprefill（プロンプト処理）は一度に1スロットしか処理できない（逐次）が、decodeはバッチで並行処理される。短いpromptならprefillは無視できる規模なので、4ストリームは速やかにbatch-decodeに入り真並行になる。長いpromptだとprefillの逐次処理が時間の大半を占め、並行decodeの番が回ってきた頃にはウィンドウがほとんど残っていない——見せかけの並行になる。
5Kのカラムがちょうどこのメカニズムを定量化している：prefillが最速のgpt-ossは1.0/0.5を叩き出し、最遅のQwen3-235Bは0.5/0.2にとどまる。順序はprefillの序列と一致する。32K以降は全モデルが0まで落ちる。
結論
1. prefillは片方向帯域に依存するが、5GbEを超えると効果は逓減する
片方向帯域を5GbEの4.71GbpsからUSB 10GbEの7.28Gbps（+55%）に上げても、prefillは+5%（GLM / Llama-3.3 / Qwen2.5 / Qwen3-235B）〜+17%（Qwen3.6、gpt-ossの長文脈時）にしか伸びない。
帯域への感度は2つの要因で上がる。モデルのprefillが速いほど、単位時間あたりに境界を通過するデータ量が多い——2000+ tok/sの2つのMoEは+13〜17%まで伸びる一方、300〜500 tok/s帯の4モデルは一律+4〜6%で文脈長によらず平坦。文脈が長いほど、各層境界で渡すhidden stateが大きくなる——Qwen3.6は5Kの+8%から100Kの+17%まで単調に上昇する。
結論として、prefillは主に計算律速であり、通信速度は副次的な要因にすぎない。この構成では5GbEの時点で、prefillはすでにケーブルに縛られていない。
2. decodeが食っているのはステップごとのトランザクションオーバーヘッドであり、帯域ではない
これが今回もっとも実のある収穫であり、しかもtok/sという単位では完全に見えなくなる部分だ。
tok/sで見ると、偽TB5は速いモデルで約10%の劣位、遅いモデルではほとんど見えない——「速いモデルほどネットワークを食う」ように見える。トークンあたりの所要時間に換算すると様子が一変する：偽TB5は5GbEに対して常に1.5〜2.9 ms/tokenの遅れがあり、これはモデルの速度にも文脈長にも依存しない。
GLM-4.5-Airのグループが最もクリーンだ：同一launch内で、トークンあたりの所要時間は19.7ms（短）から66.7ms（52K）まで3.4倍になったが、回線由来の増分は終始1.71〜1.83msのまま。所要時間が3.4倍になっても増分はびくともしない——これは固定オーバーヘッドの特徴であり、比例的なオーバーヘッドではない。
このオーバーヘッドの正体は、16KBのリクエスト-レスポンス測定が答えを出している：偽TB5のp50は856µs、うち固定オーバーヘッドが326µs。4.38Gbpsで計算すると16KBの往復の伝送時間はわずか59.9µs——往復全体のわずか7%にすぎず、残り93%はプロトコルスタック、DMAスケジューリング、コンテキストスイッチに費やされている。decodeが毎ステップ境界を越えるpayloadは1トークン分のactivationで、サイズは数KB——ちょうどこの帯域に収まる。
これを逆算すると、decodeのステップごとに最低でも3回のクロスマシントランザクションがあることになる（N=2だと5GbEの16KB RRがわずか6µsという、ping 84µs+伝送56µsの物理下限を下回る値を要求してしまう）。tensor-splitのトポロジー上は、1トークンあたり理論上は往復1回、つまり2回で足りるはずだ。余分な部分は最適化の余地があり、しかも回線を変えるより価値が高い。
3. 偽TB5はどこで負けているのか
片方向帯域は5GbEとほぼ同じ（4.38–4.76 vs 4.71）だが、双方向合計は29%低い（6.64 vs 9.38）。16KB往復の固定オーバーヘッドは326µs。同じこの3つの数字が、2種類の負荷でまったく異なる現れ方をする。
- prefill（大きな塊の片方向転送）：短い文脈で最も不利、文脈が伸びるにつれ5GbEに追いつく——帯域律速に転じれば、両者の片方向帯域はもともと同じだから。
- decode（数KBのリクエスト-レスポンス）：最初から最後まで約1.7ms/tokenの遅れが続き、収束しない——このpayloadサイズはトランザクションオーバーヘッド律速の領域に落ち、そこでは終始劣位のまま。
根本原因はおそらく同じものだ：thunderbolt-netのシングルリングDMAが送受信を同一エンジン上で逐次化しており、「双方向スループットの低さ」と「トランザクションオーバーヘッドの高さ」は、同一のボトルネックが2つの側面に映し出されたものだろう。
4. 超長文脈での崩壊はVRAMの問題であり、回線の問題ではない
100Kと32Kを比較すると、prefillが急激に低下する（Qwen3.6は1756→844 tok/s、gpt-ossは1536→693 tok/s）が、この崩壊に関して3回線間に差はなく、落ち幅は同じだった。
つまりこれは伝送の問題ではなく、大量のデータ演算の圧力下でKVの読み書きがVRAMのボトルネックに突き当たっているということだ。並行処理のデータもこれと相互に裏付け合っている：32K以降はoverlapが軒並み0まで落ち、4並行は総じて崩壊するかエラーで即死する——いずれもVRAM側の表れである。
5. モデル間の差異
単発decodeの序列：gpt-ossが最も出足が速く（短85.5→100K 39.4）、Qwen3.6が続く（78.0→50.8）、Qwen3-235Bが中位（37.9→15.5 @32K）、GLMが最も急激に減衰（51.5→9.1）、2つのdenseモデルが最下位（Llama-3.3 10.3→4.9、Qwen2.5 9.3→7.1）。
ただしgpt-ossの維持率はわずか46%、Qwen3.6は65%あり、両者は32K付近で逆転する。長文脈が主な負荷であれば、優位性は入れ替わる。
高並行時の溢出耐性：52K×4/100K×4に耐えられるのはgpt-ossとQwen3.6だけで、退化した値は出すもののクラッシュはしない。GLM、Llama-3.3は溢出すると即座にHTTP 500。Qwen2.5、Qwen3-235Bはctxの壁に直接ぶつかる（400拒否）。この項目は回線とは無関係だ。
6. 構成判断への示唆
「600MB/sのレイヤー分割で十分」という判断は成立するが、その根拠は当初の想定とは異なる。当初は「帯域が足りているから」だと思っていたが、実際はprefillが5GbEの時点ですでに帯域律速から抜け出しており、decodeはそもそも最初から帯域律速ではなかったからだ。
したがって、
- VRAMを増やす、より速いMoEモデルに換える方が、通信速度を上げるより優先度が高い。すべてのクラッシュ、ctxの壁、並行処理の崩壊は、VRAM側で発生している。
- decode側に帯域を追加しても意味がなく、削るべきはステップごとのクロスマシントランザクション回数だ。N≥3に対してトポロジー上の下限は2で、ここには確実な余地がある。ケーブルを変えるのは、あの7%の伝送時間を最適化しているにすぎない。
- クロスマシンRPCの天井は、ケーブルの帯域にはない。
最後に
モデルが「動く」ことと「使える」ことの間には大きな距離がある。多くの個人向け・家庭用モデルの性能が振るわないのは、VRAMだけでなく、エンジニアリングも重要な要因だ。たとえば、未対応のcontinueではskillを認識できないが、ollama配下のcopilotなら認識できる。文脈やコンテキストキャッシュの働き、KVの計算と設定など——これらはどれも興味深く、価値の高い方向性だ。
結論を振り返ると、私のUSB10Gは無駄な買い物だったのだろうか？vllmのテンソル並列を試してみようか？
気泡（バブル）問題と5枚のグラフィックカード、あまり手こずらずに解決できるといいのだが。パラメータ調整に沼って、本業を忘れないように……
そういえば、最初の数日で3メートルの「thunder bot5」伝送ケーブルも買っていました（そう、彼らの広告文句がそうだったんです）。
もしみなさんのASMedia4242を文鎮化させてしまったなら、こちらにUEFI shellのガイドがあります。著作権の問題があるため、リソース自体は公開しません。私自身もその過程でたくさん学びました。ASMedia4242あるいはTB5のハンドシェイクに関して、Linuxコミュニティにpatchを1つ提出しました。通らないかもしれませんが。でも、hello world。