ntransformer - 単一の RTX 3090 で Llama 3.1 70B を実行する NVMe-to-GPU 推論エンジン

 (github.com/xaskasdf)
15 ポイント 投稿者 GN⁺ 2026-02-23 | 1件のコメント | WhatsAppで共有
  • C++/CUDA ベースの LLM 推論エンジンで、GPU メモリストリーミングと NVMe 直接 I/O により、**Llama 70B モデルを RTX 3090（24GB VRAM）**で実行可能
  • 3 段階適応キャッシュ構造を使用し、VRAM・固定 RAM・NVMe/mmap を自動分割、mmap 比で最大 83 倍の高速化を達成
  • gpu-nvme-direct バックエンドは CPU を完全に介さず、NVMe から GPU へ直接データを転送し、PCIe 帯域幅を最大限活用
  • Layer skip と self-speculative decoding 機能により不要な計算を減らし、品質低下なしに処理速度を向上
  • コンシューマー向けハードウェアで超大型モデルを効率的に動作させ、高性能 LLM 推論のアクセシビリティ拡大の可能性を示す

NTransformer 概要

  • 高効率な C++/CUDA LLM 推論エンジンで、RTX 3090（24GB VRAM）上でLlama 70B モデルを実行
    • GPU メモリを通じてモデルレイヤーをストリーミングし、必要に応じてNVMe 直接 I/Oを使って CPU を完全にバイパス
  • CUDA Toolkit 以外の外部依存関係なし、PyTorch や cuBLAS は不要
  • GGUF モデルフォーマットをサポートし、Q4_0、Q8_0、Q4_K_M、Q5_K、Q6_K、F16、F32 の量子化形式を利用可能

性能とキャッシュ構造

  • 3 段階適応キャッシュ（3-Tier Adaptive Caching）
    • VRAM 常駐レイヤー（I/O なし）
    • 固定 RAM（H2D 転送専用）
    • NVMe/mmap フォールバック
  • RTX 3090 + 48GB RAM 環境でmmap 比 83 倍の高速化
  • **PCIe Gen3 x8 帯域幅（約 6.5 GB/s）**がボトルネックとして作用
  • Q4_K_M 量子化では VRAM に 10 層多くのレイヤー（36 vs 26）を配置でき、転送量を削減
  • Layer skip（コサイン類似度ベース）により 80 層中 20 層を省略し、品質低下を最小化

主な機能

  • SLEP ストリーミング: NVMe 読み取り、PCIe DMA、GPU 計算をダブルバッファで重畳処理
  • gpu-nvme-direct バックエンド: NVMe データを GPU からアクセス可能な固定メモリへ直接読み込み
  • Self-speculative decoding: VRAM 常駐レイヤーをドラフトモデルとして活用し、追加モデル不要
  • 自動データパス選択: VRAM 常駐 > 固定 RAM H2D > mmap 固定 > CPU memcpy
  • Llama アーキテクチャ対応: RoPE、GQA、SwiGLU、RMSNorm、KV キャッシュを含む

システム要件

  • Linux（Ubuntu、kernel 6.17+）、CUDA Toolkit 13.1、gcc/g++ 14、CMake 3.24+
  • Compute Capability 8.0+ GPU（RTX 3090 でテスト済み）
  • NVMe 直接 I/O を使用する場合は、別 PCIe スロット上の NVMe SSD と gpu-nvme-direct ライブラリが必要

NVMe 直接ストリーミング

  • モデルが VRAM に収まらない場合、NVMe → GPU 直接パスで CPU を完全に排除
    • データフロー: NVMe SSD → DMA → 固定ステージングメモリ → PCIe H2D → GPU バッファ → 計算
  • NVMe を VFIO にバインドしてユーザー空間から直接アクセス
  • 各レイヤー（70B Q6_K 基準で約 670MB）は、約 202ms 以内に 670 個の NVMe コマンドで読み込まれる
  • NVMe 読み取り、H2D DMA、GPU 計算をダブルバッファパイプラインで並列処理

システム設定とリスク警告

  • 自動設定スクリプト（setup_system.sh）がGRUB、NVIDIA DKMS、CUDA ヘッダー、VFIO、NVMe バインドを順次構成
  • IOMMU 無効化、カーネルモジュールのパッチ適用、NVMe の VFIO バインドなどの高リスク作業を含む
  • 設定を誤ると起動失敗、NVMe データ損失、システム不安定化の可能性あり
  • ブートドライブは絶対に使用禁止、専用の別 NVMe デバイスが必要
  • すべての変更についてバックアップおよび復元スクリプトを提供

アーキテクチャとコード構造

  • src/ ディレクトリ内の主な構成
    • core/: テンソル、メモリ割り当て、GPU デバイス管理
    • cuda/: GEMV、RMSNorm、RoPE、SwiGLU、softmax カーネル
    • memory/: NVMe および mmap ベースの SLEP ストリーミングエンジン
    • model/: Transformer 構成、GGUF ローダー、attention、FFN、normalization
    • inference/: トークナイザー、サンプラー、エンジン
  • scripts/: システム設定、NVMe バインドおよび復元スクリプトを含む

開発段階ロードマップ

  • 第 1 段階: Llama 8B Q8_0、カスタム CUDA カーネル、48.9 tok/s（完了）
  • 第 2 段階: SLEP ストリーミング、単一 GPU で 70B 実行、33 倍高速化（完了）
  • 第 3 段階: Q4_K_M/Q5_K 対応、Layer skip、self-speculative decoding、F16 KV キャッシュ（完了）
  • 第 4 段階: NVMe Direct バックエンド、GPU 主導 NVMe 読み取り 3.35 GB/s（完了）
  • 第 5 段階: 推論最適化および公開 C API（予定）

ライセンス

  • BSD-2-Clause ライセンス適用

関連記事

1件のコメント

 
GN⁺ 2026-02-23
Hacker Newsのコメント

  • CPUをバイパスしてNVMeからGPUへ直接転送する方式は本当に賢いと思う
    ローカルで大規模モデルを動かすときのボトルネックは常にメモリ階層だったが、これはNVMeを拡張VRAMのようにDMAで直接扱うようなものだ
    Apple Mシリーズの**ユニファイドメモリ（unified memory）アプローチと比べるとどうなのか気になる。M4 Maxなら70Bモデル全体をメモリに載せられるが、スループットは3090より低い
    NVMeアプローチを使った3090とM4 Maxのネイティブ性能を    バッチ推論（batch inference）**基準で比較したベンチマークがあれば面白そうだ

    • M3を持っているので、Metalでテストしてみる予定だ

  • GPUdirectを使えば、ストレージデバイスへ直接DMA転送できる
    もしm.2ストレージが実際にはDRAMだったらどうだろうと考えた。GPUからモデルをスピルするときは永続性が不要なので、システムRAMをCPU用に残しておける

    • RAMディスクを使えばずっと良くなりそうだ。Intel Optaneが標準になれなかったのは残念だ。こういうワークフローにぴったりの技術だった
    • 自分も同じことを考えた。以前Dask Summitでdask-cudfに関する発表をしたが、並列SSDアレイ → GPUDirect Storage → PCIe → A100 GPUという構成でログ解析を高速化していた。今ならこうした構成をLLMやMoEモデルに適用すると面白そうだ
    • 実際、DRAMベースのm.2ストレージはすでに**CXL（Compute Express Link）**という形で存在する。ただ、RAM価格が高すぎて、NVMeコネクタあたり31GB/sの帯域幅を活かしにくいのが問題だ

  • 毎秒0.2トークンという速度はチャットには遅いが、バッチ/非同期処理には十分だ
    自分は自動コンテンツ生成パイプラインを回していて、複数のLLM呼び出しを同時実行している。画像生成がボトルネックなので、全体の処理時間はどうせ20分ほどかかる
    70Bモデルをローカルで動かせるならAPIトークン費用を節約できるので、大きなコスト削減になるはずだ

    • コスト面では効率的ではない。0.5 tok/sだと1時間あたり3600トークンで、3090システムは200〜300Wを消費する。同じ量のトークンをOpenRouterで llama 3.1 に流したほうが、電気代よりずっと安い。それでもプライベート推論という点では意味がある
    • 3090を350Wで長時間回す場合の電力コストも考慮すべきだ

  • 0.2 tok/sは実験用としてはよいが、インタラクティブに使うには不十分だ
    たいていの場合、うまく量子化された8Bや13Bモデルのほうが、より良いレイテンシ-品質のバランスを提供する

    • 自分も単に可能性を試してみたかった。以前PS2でクラシックなTransformerを動かして毎秒3000トークン出したことがあるが、これはメモリからGPUへ直接コマンドを送る構造のおかげだった。一般的なPCはCPUを経由しなければならないので遅い。業務向けGPUはこの問題を解決するが、高価すぎる
    • それでも状況によっては大規模モデルの品質のほうが重要なこともある
    • CPU+GPUの組み合わせで動かすほうが速い。自分の7950X+3090構成では1.5 tok/sくらい出る
    • 性能表を見てから、上位の項目が8Bモデルだと理解した。5秒/トークンは遅すぎる。自分の5950X+128GB RAMシステムなら、CPUと3060 GPUの組み合わせのほうが速そうだ。3090で2秒/トークンが計算限界だという主張にもあまり納得できない

  • 本当に興味深い実験だ。自分も先にこういうことを試しておくべきだった
    PCIeの理論帯域幅に対して、実際の**スループット（throughput）**がどのくらいなのか気になる。これがレイテンシの問題なのか、帯域幅の問題なのか知りたい

    • 実際には帯域幅ボトルネックだ。自分のB450マザーボードはPCIe3 x8しか対応していないので、GPUが制限されている。X570にアップグレードすれば速度は2〜3倍になるはずだ

  • すごいハックではあるが、70Bモデルで0.5 tok/sというのは、同じカードで7Bモデルが30+ tok/s出るのと比べると遅い
    NVIDIAの研究によれば、10B以下のモデルでもエージェント作業の40〜70%を処理でき、品質差も急速に縮まっている

  • この分野は今後も実験する価値が大きい
    長期的にはモデル最適化、つまりモデルの一部を省略しても性能に影響しない部分を見つける研究が鍵になる気がする。結局モデルも一種の非可逆圧縮（lossy compression）構造だからだ。こうした方向性はAIの民主化にも役立つ

    • 圧縮という比喩は面白い。ファインチューニングも似たように見られる。たとえば3Bモデルを特定タスク向けに調整すれば、70Bモデルの汎用性は不要になる

  • 本当に素晴らしいプロジェクトだ。こういうアイデアを思いつくには、どんなシステム/ハードウェアの背景知識が必要なのか気になる
    自分はハードウェアがかなり抽象化された環境で働いているので、こういうアプローチを考えるのが難しい。単なる創造性だけでなく、システムレベルの理解が必要そうだ

    • これがまさにその実験だ: ps2-llmプロジェクト
      PS2でLLMを動かそうとしてRAM 32MB、VRAM 4MBの制約にぶつかり、レイヤーストリーミング方式を考案した。PS2はVRAMが32ビットアドレスを直接処理できたので非常に高速で、それをPCでも再現しようとした
    • 自分も似たことを思う。昔のコンソールはCPUが遅かったので、DMA転送が重要だった。たぶんその経験がこういうアイデアにつながったのだろう。PS2のスマートメモリーカードもDMA機能がかなり複雑だった

  • 自分も似たことを試している。VRAMの半分以下で1Tモデルを動かす実験中だ
    SGLangのルーティングレイヤーを修正して、Gen5 NVMeからGPUメモリへJIT予測ベースのexpert swapを実装できそうだ。NVIDIA DynamoとNIXLプリミティブを活用している
    すでに試した人がいるのか気になる

    • それは自分も見てみたい。3090をもう1枚買ってPCIe3ボトルネックを解消するために、マザーボードのアップグレードを検討している。glm 4.7〜5をq4_k_mで動かせそうだ

  • 素晴らしいプロジェクトだ。一般向けGPUでのDKMSパッチ手順をもう少し詳しく知りたい。自分も試してみたい

    • ドキュメントを更新して、パッチ手順とリスク情報を追加した
    • NVIDIAオープンソースドライバを改変して、P2P GPU通信やvGPU分割のようなエンタープライズ機能をアンロックした事例もある
      関連リンク: RTX4090 P2P Unlock, vGPU Unlock