cuMemcpyHtoD/DtoHと**NBD(Network Block Device)**を組み合わせて実現今回紹介するのは、GitHubの nbd-vram というプロジェクトです。
一言でいうと、NVIDIA GPUのVRAMをLinuxのswapスペースとして使うための仕組みです。
「swapって何？」という人向けにざっくり説明すると、
PCのメモリ（RAM）が足りなくなったときに、一時的な退避場所としてSSDやHDDを使う機能です。
ただしswapはRAMよりずっと遅いので、使いすぎると体感が重くなります。
そこでこのプロジェクトは、SSDの代わりにGPUのVRAMを退避先にするわけです。
VRAMは通常、ゲームや3D描画で使うGPU専用メモリですが、ハイブリッドGPU構成のノートPCだと、GPUがあまり働いていない時間帯にVRAMが空いていることがあります。そこを活用しよう、という発想です。
これはかなり面白いです。正直、最初に見たとき「その手があったか」と思いました。
READMEでは、特に次のような環境を想定しています。
特に刺さるのは、8GBやそれ以上のVRAMがあるのに、普段はほぼ寝ているような構成だと思います。
もしRAMが少なくてSSD swapが頻繁に発生しているなら、「そのVRAMを使えるなら使いたい」という気持ちはかなり自然です。
このプロジェクトの肝は、NBD (Network Block Device) を使っていることです。
名前に “Network” とありますが、実際にはネットワーク経由でなくても使えます。
要するに、Linuxカーネルが外部のブロックデバイスに接続するための仕組みで、ここではUnix socketを通してローカルのdaemonにつなぎ、VRAMをブロックデバイスのように見せています。
流れをかなり簡単にするとこんな感じです。
/dev/nbdX を使うnbd kernel driver がそれを受けるREADMEにあるデータ経路はこんな感じです。
kernel swap subsystem - /dev/nbdX - nbd kernel driver - Unix socket - nbd-vram daemon - cuMemcpyHtoD/DtoH - GPU VRAM
ここで出てくる cuMemcpyHtoD/DtoH は、簡単に言えば
HtoD = Host to Device（CPU側からGPU側へコピー）DtoH = Device to Host（GPU側からCPU側へコピー）という意味です。
つまり、特別な裏技ではなく、CUDAで普通に使えるメモリコピー機能を利用しているのがポイントです。
個人的には、ここがこのプロジェクトのいちばん賢いところだと思います。
NVIDIAのカーネル内部の特殊機能に頼るより、動く範囲の広いAPIで組み立てているので、更新に比較的強いんですよね。
READMEでは、よく思いつく方法として NVIDIA P2P API を使う案が説明されています。
これはGPUのメモリをCPUから直接扱えるようにする方向の技術ですが、GeForceなどのconsumer GPUでは EINVAL が返るケースがあるそうです。
つまり、Quadro/datacenter系のSKU向けに制限されているとのことです。
また、BAR1の物理アドレスを直接 ioremap_wc で触る方法も試したものの、
GPU内部のページテーブルで実際に見えているBAR1領域は約16 MiB程度で、ほとんどは使えなかったと説明されています。
その結果、mkswap は通っても swapon で失敗する、という流れになるそうです。
要するに、**“GPUのVRAMを直接いじる”王道っぽい方法は、consumer GPUではうまくいかない**。
だからこそ、nbd-vram はNBD経由でブロックデバイス化する回り道を選んでいるわけです。
こういう、正面突破ではなく「通る道を探す」アプローチは、OSSらしくて好きです。
必要条件は比較的シンプルです。
libcuda.so.1
nbd module が必要nbd-client packagegcc と makeつまり、巨大なCUDA開発環境を入れなくても動かせるのは地味にうれしい点です。
「研究用の特殊環境がないと無理」という感じではなく、比較的ふつうのLinux環境で試せるのが良いですね。
READMEでは、次のような手順が案内されています。
git clone https://github.com/c0dejedi/nbd-vram
cd nbd-vram
sudo ./install.sh
sudo systemctl start vram-swap-nbd
インストール後は swapon --show で確認できます。
READMEの例では、/dev/nbd0 が swap として見えており、優先度も 1500 になっています。
このプロジェクトは、サービスとして起動し、ブート時に自動的に有効化される構成です。
なので、単なる一回限りのハックではなく、日常運用を意識しているのがわかります。
設定は systemd service の環境変数で行います。
VRAM_SETUP_SIZE_MB
VRAM_SWAP_PRIORITY
優先度が高いほど、Linuxはそのswapを先に使います。
READMEでは例として、VRAM_SWAP_PRIORITY=1500 が設定されています。
面白いのは、指定サイズを“上限”として扱う点です。
もしGPU側に余裕がなければ、512 MiBずつ下げながら確保可能な分だけ使うそうです。
これなら、すでに画面描画などでVRAMを消費していても、取れるだけ取るという動きになります。
これは実運用をよく考えた設計だと思います。
「固定サイズしか取れません」だとちょっと使いにくいですが、こういう柔軟な後退処理があると試しやすいです。
さらにREADMEでは、AC電源接続中だけ有効にするような管理も案内されています。
ノートPC向けとしてはかなり納得感があります。
VRAMをswapに使うのは面白いですが、バッテリー駆動中まで積極的に回すのは現実的ではない場面もあります。
そのため、こういう電源連動の制御があるのはかなり親切です。
READMEによると、手動で systemctl stop した場合は、それを尊重して勝手には復帰しないそうです。
このあたりも、運用者の気持ちをわかっている感じがします。
ここがいちばん気になるところですよね。
結論からいうと、用途によるです。
READMEのベンチマークでは、対象は RTX 3070 Laptop（8GB VRAM） + NVMe cryptswap です。
結果の要点をざっくり見るとこうです。
連続転送では、当然ながらNVMeのほうが強いです。
これは、VRAM側が遅いというより、NBD + CUDA のユーザー空間経由の往復オーバーヘッドが効いているためです。
ここでもNVMeが強いです。
高い負荷で連続してアクセスするなら、やはりSSDのほうが有利です。
ここがかなり面白いところです。
たまにちょっとだけアクセスする場合は、VRAMのほうが圧倒的に速い。
READMEでは、NVMeはAPST（省電力機能）で寝たり起きたりするので、1秒に1回程度の疎なアクセスだと毎回数msの起床コストが乗ると説明されています。
つまり、
という見方になります。
これ、swapの性質を考えるとかなり筋が通っています。
swapは必ずしも巨大な連続ストリームではなく、細かいページがときどき飛ぶ世界です。
なので、「帯域」だけでなく「応答の速さ」が効く場面がある、というのはなるほどと思いました。
ここははっきり書いておきたいのですが、nbd-vram は魔法の高速化装置ではありません。
むしろ、かなり条件付きです。
たとえば：
要するに、これは
「余っているVRAMを、SSDの代わりに少し賢く使う」ための道具
であって、
メモリ不足を根本解決する最強の手段
ではない、ということです。
個人的には、こういうプロジェクトは「実用かどうか」を二択で見るより、**“どの条件なら面白く効くか”を見るのが大事**だと思います。
その意味で nbd-vram は、かなり良い実験材料ですし、刺さる人にはすごく刺さるはずです。
私が特に魅力を感じたのは、次の3点です。
「使っていないVRAMをswapに回す」。
この説明だけで価値が伝わるのが強いです。
難しい最適化を持ち出さなくても、課題と解決策が直感的です。
Linuxの深いところを触ると、どうしても保守が重くなります。
でもこのプロジェクトは、既存の仕組みをつないで実現している。
こういう設計は、あとから見返しても筋が良いです。
メモリは増設できない。
でもGPUは積んでいる。
そしてGPUのVRAMは空いている。
この状況、まさに「もったいない」を拾いにいく発想です。
Linux好き、ハード好きにはかなりニヤリと来ると思います。
nbd-vram は、NVIDIA GPUのVRAMをLinuxのswapとして使うかなりユニークなプロジェクトです。
普通のユーザーに無条件で勧められるものではないですが、メモリ増設できないノートPCや、遊んでいるVRAMを有効活用したい人には、かなり面白い選択肢だと思います。
速度面ではNVMeに勝てない場面もありますが、疎なアクセスでの低レイテンシは魅力的です。
しかも、カーネルモジュールに依存しすぎない設計なので、更新に強いのも良いところです。
こういう「ちょっと変だけど理にかなっている」プロジェクト、私はかなり好きです。
実用一点張りではないけれど、Linuxの自由度と工夫の面白さがぎゅっと詰まっている感じがします。