私は「コンシューマ向けマルチGPUでのPCIeボトルネック」に取り組んできました。Nvidiaは4090/5090からNVLinkを削除しており、70Bモデルを2枚のコンシューマカードに分割すると、PCIeのピアツーピア経由でおよそ~30 GB/sまで落ちます。

ここ数か月、GPUが本来アイドルになっているNVENC/NVDECシリコンを使って、アクティベーションとKVキャッシュをその場で圧縮し、その小さなビットストリームを同じ配線で送るためのPythonライブラリを作ってきました。

Repo: https://github.com/shootthesound/torch-nvenc-compress (Apache 2.0)

先行研究（このアイデア自体は新しくありません）

• LLM.265 — "Video Codecs are Secretly Tensor Codecs"（2025年後半）。最も近い直接の前例は、同じ洞察がLLMの重み、アクティベーション、KVキャッシュにも適用できるという点です。
• KVFetcher（2026年4月）。リモートのプレフィックス取得のためのKV圧縮。
• CodecFlow（2026年4月）。プリフィル中のKVリフレッシュのための、コーデックのモーションベクトル・メタデータ。

「テンソル上のビデオコーデック」という発想は、私が始めたときにはすでに文献にありました。この取り組みで追加されたのは：

1. PCA + ランク打ち切りを前処理として。 アクティベーションとKVは、標準基底ではノイズのような挙動です（~4×圧縮フロア、基本的にはガウスノイズの限界）。PCA基底は、コーデックが実際に活用できるヘビーテイルなチャネル共分散を明らかにします。基底は層ごとで、オフラインで計算し、モデルにLoRA形式で同梱します（FLUX.2 Klein 9Bの8つのダブルブロック、K=500で約~32 MB）。
   
2. 並列パス／デュアルレーンのアーキテクチャ再解釈。 NVENCとNVDECは、SMクラスタとPCIeコントローラから物理的に別のハードウェアユニットです。CUDAストリームのパイプライン化により、コーデックの時間は他のテンソルの計算と転送の背後に隠れます。圧縮率は、単にペイロードを小さくするだけでなく、有効帯域のマルチプライヤとして効いてきます。
3. 純ctypesによるDirect Video Codec SDKラッパ（DirectBackend）— FFmpegのサブプロセス起動に伴うオーバーヘッドを排除。torch CUDAテンソルからゼロコピー、NVENCエンジンごとに非同期出力リングを8段ディープ、必要ならnvEncSetIOCudaStreamsでCUDAストリームのバインドをオプション指定。5090の3つのNVENCエンジンすべてに対してMultiEngineDirectBackendを適用可能です。
4. 3つのドキュメント化された「ヌルな」発見 — スパース残差、Blackwell上でのAV1 NVENC、チャネル順序の入れ替え。なので、誰もが行き止まりを再実行する必要はありません。

測定結果（RTX 5090、実ワークロード）

• 圧縮率： 拡散（FLUX.2 Klein 9Bミッドブロック）で6.1×のロスレス、LLMのKVキャッシュ（Mistral 7B v0.3）で2.7×のロスレス。LOO検証を、1,735件の拡散キャプチャと6つのLLMプロンプトに対して実施。 （FLUX.2 Klein 9Bは内部の研究ターゲットで、公開PoCリポジトリではApache 2.0で自由にダウンロードできるためFLUX.1-schnellを使用しています。数値はschnellでも質的に再現されます—ヘビーテイルなPCAスペクトルで、Paretoに類似した分布です。）
• コーデック速度： 実PCA回転したFLUXアクティベーション上で、256×256 YUV444、QP=18の条件。DirectBackend はエンコード0.243 ms/frame、デコード0.435 ms/frame。5090の3つのNVENCエンジン全体にMultiEngineDirectBackendを適用すると、エンコード0.180 ms/frame、デコード0.262 ms/frame。FFmpegサブプロセス基準に対して約7.9×です。
• 並列パスのオーバーラップを経験的に測定： CUDAストリームAで30×4096²のfp16 GEMM と、ストリームBで64フレームDirectBackendエンコード（nvEncSetIOCudaStreamsでエンコーダをストリームBに結びつける）を同時実行。ウォールクロックの逐次（シリアライズ）40.1 ms、並列ウォールクロック26.0 ms、理論上限のオーバーラップ下限20.9 ms。逐次実行に対する1.34×の高速化＝実現された理論上限オーバーラップの67%。これは、NVENCシリコンがSM計算と同時に動作するというアーキテクチャ主張を支える負荷のかかった測定です。
• 遅い配線でも勝つ、エンドツーエンド： 100 Mbpsの家庭用ブロードバンドでウォールクロック3.13×高速化、50 Mbpsで5.29×（実際のコーデック往復＋模擬ワイヤ）。模擬1 Gbitイーサネットでデュアルレーンは1.69×。

エンドツーエンドで測定していないもの（上記からの推計）

マルチGPU PCIeピアツーピアでのアクティベーション転送により、有効帯域が~180 GB/sまで回復 — コーデックのプリミティブは準備されベンチマーク済みですが、GPU間のPCIeピアツーピア配線はまだ未着手です。（この部分はコミュニティの助けが必要です。私の検証環境にはデスクトップGPUが1枚しかなく、同じマザーボード上で2枚必要なためです。）

実際の2台マシンでのイーサネット分割モデル推論 — 配線シミュレーションPoCでは、実際のコーデック時間＋模擬ワイヤを測れますが、まだ真の2台マシン展開ではありません。（来週、ネットワーク経路のこの部分を物理的に検証するための4090ラップトップが届く予定です。）

長コンテキストKVスピルのエンドツーエンド tok/s（実モデルのデコードループ） — 圧縮率は測定済みですが、例えば32B＋64Kコンテキストのような条件での実際のN tok/s → 3N tok/sベンチマークはまだリポジトリにありません。数式がそれを示していますが、ベンチマークはまだ書かれていません。

私が助けを欲しいところ

• デュアル4090／デュアル5090／PCIe P2P付きの2台マシン構成で、私がそのベンチマークを書いたときに、クロスGPUのピアツーピアベンチマークを実行したい人。そうすれば、「75%」のギャップを意味のある形で縮められます。
• 長コンテキストKVスピルのワークロードを回していて、エンドツーエンドのtok/s測定のためにDirectBackendをデコードループに配線したい人。統合についてあなたと一緒に作ります。
• ベンダー横断の対応範囲 — AMD VCNとIntel QSV/Arcの経路は完全にオープンです。同じアーキテクチャ主張で、異なるSDKの表面。

リポジトリに入っているもの

番号付きの実行可能PoCが19個。測定した数値はすべて再現可能です。READMEの先頭に、正直なステータス表があります。PCA基底ビルダー＋チャネルごとの量子化＋YUVのパック／アンパック＋コーデックラッパはすべて部品として分離されているので、必要に応じて差し替えできます。

私はフルタイムの介護の傍らで一人で組み立てました。技術的なフィードバック、批評、または私が見落としていた関連研究への指摘は、本当にありがたく受け取っています。