RTX 3090 1枚でLlama 70B — NVMe-to-GPU直結でCPUバイパスする革新技術

「70Bモデルを動かしたい。でもVRAMが足りない」——ローカルLLMに取り組む人なら、一度はぶつかる壁ですよね。Llama 3.1 70Bをフル精度で動かすには約140GBのメモリが必要。4ビット量子化しても35GB。RTX 3090の24GB VRAMじゃ、どう逆立ちしても入りきらないわけです。

ところが2026年2月、この常識を覆すプロジェクトがHacker Newsに登場しました。その名は「ntransformer」。NVMe SSDからGPUメモリへダイレクトにデータを流し込み、CPUを完全にスキップするという、ちょっと信じがたいアプローチでLlama 3.1 70BをRTX 3090の1枚で動かしてしまったんです。

Show HNとして投稿されたこのプロジェクトは、あっという間に301ポイント・80コメント超を獲得。「VRAM不足の壁を突破する」技術として、世界中のエンジニアの注目を集めています。

この記事では、ntransformerの技術的な仕組みからベンチマーク結果、Hacker Newsでの賛否両論、そして日本企業がこの技術をどう活用すべきかまで、徹底的に解説します。

何が起きたのか——ntransformerの全貌

そもそもなぜVRAMが足りないのか

まず前提を整理しましょう。LLMの推論（inference）では、モデルの重み（weights）をGPUのVRAMに載せて計算を行います。Llama 3.1 70Bは名前の通り700億パラメータ。FP16で格納すると約140GB、最も一般的なQ4_K_M量子化でも約35GBが必要です。

コンシューマ向けGPUで最もVRAMが多いのはRTX 3090/4090の24GB。つまり、どんなに圧縮しても70Bモデルは1枚のGPUに収まらないんですよね。

従来の解決策は大きく3つでした。

1. マルチGPU構成：2枚以上のGPUでモデルを分割。でも高い
2. CPU/RAMオフロード：VRAMに入りきらないレイヤーをシステムRAMに退避。でも遅い
3. 小さいモデルで我慢：7Bや13Bに妥協。でも性能が違う

ntransformerは、この「VRAM < モデルサイズ」問題に対して、まったく新しい第4のアプローチを提案しました。

ntransformerとは何か

ntransformerは、C++/CUDAで書かれた高効率LLM推論エンジンです。開発者のxaskasdf氏がGitHubでBSD-2-Clauseライセンスとして公開しています。

核心的なアイデアは驚くほどシンプルなんです。

「モデルの全レイヤーをVRAMに載せる必要はない。必要なレイヤーだけをNVMe SSDからGPUメモリへ”直接”ストリーミングすればいい」

ポイントは「直接」の部分。通常、NVMe SSDのデータをGPUに渡すには「NVMe → CPU/システムRAM → GPU」という経路を通ります。CPUがデータを一度受け取って、それをGPUに転送するんですね。これが「バウンスバッファ」と呼ばれるボトルネックです。

ntransformerはこのCPUの仲介を排除し、NVMe SSD → （DMA） → ピン留めメモリ → （PCIe H2D） → GPUバッファというダイレクトパスを実現しました。

3層アダプティブキャッシング・アーキテクチャ

ntransformerの核となるのが、モデルのレイヤーを3つの階層に自動分配する「3-Tier Adaptive Caching」です。

階層の境界はcudaMemGetInfo()と利用可能なシステムRAMから自動計算されます。つまり、ユーザーが手動でレイヤー配分を設定する必要がないんです。賢い。

SLEP ストリーミングパイプライン

もう一つの重要な技術がSLEP（Streaming Layer Execution Pipeline）です。これはダブルバッファリングにより、NVMe読み取り・PCIe DMA転送・GPU計算の3つを同時並行で実行するパイプラインです。

イメージとしては、工場の流れ作業に近いですね。レイヤーNの計算をGPUが実行している裏で、レイヤーN+1のデータがNVMeからRAMに読み込まれ、レイヤーN+2のデータがRAMからGPUに転送されている——という具合に、待ち時間を最小化しています。

レイヤースキップ機構

さらに面白いのがレイヤースキップ機能。これは、トランスフォーマーの各レイヤーの出力をコサイン類似度で比較し、「このレイヤーの出力は前のレイヤーとほぼ同じだから、計算をスキップしても品質に影響しない」と判断するものです。

しきい値0.98の設定では、Llama 3.1 70Bの80レイヤーのうち20レイヤーをスキップ。つまり全レイヤーの25%を飛ばしても、出力品質の劣化は最小限に抑えられるんです。これにより、転送すべきデータ量そのものが減り、推論速度がさらに向上します。

NVMe直結I/Oの技術詳細

ここからは少しディープな話になりますが、ntransformerのNVMe直結I/Oは、NVIDIAのGPUDirect Storageの概念を参考にしつつ、コンシューマ向けGPUで動作するよう独自実装されています。

通常、NVMe SSDはカーネルのブロックデバイスドライバを通じてアクセスされますが、ntransformerではVFIO（Virtual Function I/O）を使ってNVMeデバイスをユーザースペースに直接バインドします。これにより、カーネルを介さないダイレクトなI/Oが可能になります。

具体的には以下の流れです。

1. NVMe SSDをVFIOドライバにバインド（カーネルのNVMeドライバから解放）
2. ユーザースペースからNVMeコントローラのレジスタに直接コマンドを送信
3. DMAによりデータがピン留めされたGPUアクセス可能メモリに直接転送
4. GPUがそのメモリからレイヤーデータを読み取り、計算を実行

1つの670MBレイヤーの転送には約202ミリ秒かかり、670回の個別NVMeコマンドで構成されています。転送帯域幅は約3.35 GB/sを目標としています。

ベンチマーク結果

では、実際のパフォーマンスはどうなのか。GitHubリポジトリに掲載されているベンチマーク結果を見てみましょう。

「0.2〜0.5 tok/s」と聞いて「遅すぎでは？」と思った方、ちょっと待ってください。従来のmmapベースの手法だと70Bモデルの推論は事実上フリーズするレベルだったんです。ntransformerはmmap比で最大83倍の高速化を達成しています。

また、開発者のxaskasdf氏がHacker Newsで明かしたところによると、テスト環境のマザーボードはB450で、PCIe 3.0のx8レーン（x16ではなく）に制限されていたとのこと。帯域幅は約6.5 GB/s。PCIe 4.0やPCIe 5.0環境に移行すれば、2〜3倍の速度向上が見込めると述べています。

GPUDirect Storageとの関係

ここで、NVIDIA公式のGPUDirect Storage（GDS）との関係を整理しておきましょう。

GPUDirect Storageは、NVIDIAが提供するエンタープライズ向け技術で、NVMeストレージとGPUメモリ間のダイレクトDMA転送を実現するものです。従来のデータパスでは「ストレージ → CPU/システムRAM（バウンスバッファ） → GPU」という経路を辿りますが、GDSはこのバウンスバッファを排除します。

NVIDIAの公式ブログによれば、DGX-2環境でCPU経由の帯域幅が50 GB/sに制限されるのに対し、GDSではローカルドライブとNICを組み合わせて最大200 GB/s近い帯域幅を実現できるとしています。

ntransformerは、このGDSの概念をコンシューマ向けGPU（GeForce RTX）で再現しようとした試みと言えます。GDS自体はTesla/A100/H100などのデータセンター向けGPUとmellanox NICの組み合わせを前提としていますが、ntransformerはVFIOを使ったユーザースペースNVMeドライバで同様のダイレクトパスを実現しているわけです。

開発ロードマップ

ntransformerは5つのフェーズに分けて開発が進められています。

• Phase 1〜3（完了）：基盤カーネル、SLEPストリーミング、最適化
• Phase 4（進行中）：NVMe Direct — gpu-nvme-directバックエンドで3.35 GB/sの転送速度を目標
• Phase 5（予定）：ドラフトモデル投機的デコーディング、パブリックC APIの整備

なぜこの技術が重要なのか

VRAMの壁——ローカルLLM最大のボトルネック

ローカルLLMの世界では、「メモリ帯域幅 ÷ モデルサイズ ≒ 推論速度（tok/s）」というシンプルな公式が知られています。Hacker Newsのコメントでも指摘されていましたが、DDR4メモリ（約27 GB/s）で70Bモデルを動かすと、理論上0.3〜0.5 tok/s程度になります。

これまでの解決策は「より大きなVRAMを持つGPUを買う」か「複数GPUを並べる」でした。でも、RTX 4090は30万円近く、H100に至っては数百万円。一般のエンジニアや中小企業には手が出ません。

ストレージ階層を活用するという発想の転換

ntransformerが示した最大のブレイクスルーは、「VRAMに全部載せなくてもいい」という発想です。NVMe SSDは2TB品でも1万円台。PCIe 4.0対応のNVMe SSDなら読み取り速度7,000 MB/s超を実現できます。PCIe 5.0なら14,000 MB/s以上です。

つまり、安価なストレージの帯域幅を活用してVRAMの壁を突破するという、コスト効率に優れたアプローチなんですよね。GPU本体を買い替えることなく、NVMe SSDを1本追加するだけで巨大モデルが動く——これは大きな意味を持ちます。

ローカルLLM民主化の新章

2025年の時点で、日本でもローカルLLM導入の動きが加速しています。リコーの「オンプレLLMスターターキット」が日経優秀製品・サービス賞の最優秀賞を受賞するなど、企業のデータ主権・セキュリティニーズとの親和性が高く評価されています。

しかし現実には、70Bクラスの高性能モデルをオンプレミスで動かすには、マルチGPU構成のサーバーが必要で、初期投資が大きな障壁でした。ntransformerの技術が成熟すれば、RTX 3090 1枚＋NVMe SSD 1本という20万円以下の構成で70Bモデルが動く可能性が出てきます。

これはまさに、ローカルLLM民主化の新しい章の幕開けと言えるでしょう。

Hacker Newsの反応——賛否両論を読み解く

Hacker Newsでは80を超えるコメントが寄せられ、活発な議論が展開されました。肯定的な意見と懸念の両方を整理します。

肯定的な意見

1. 「CPUバイパスの発想が巧み」

「NVMe-to-GPU転送でCPUをバイパスするのはクレバーだ。ローカルでの大規模モデル実行のボトルネックは常にメモリ階層だった」——MarcLore氏はこう評価しました。従来のCPU/RAMオフロード方式では、CPUが律速になっていた問題を根本から解決するアプローチだと。

2. バッチ処理なら十分実用的

umairnadeem123氏は興味深い指摘をしています。「0.2 tok/sの速度でも、自動化されたコンテンツ生成パイプラインのようなバッチワークロードには十分。APIコール代と比べると大幅なコスト削減になる」と。インタラクティブなチャットには向かなくても、バッチ処理という実用的なユースケースがあるんですよね。

3. 研究基盤としての価値

jacquesm氏は「どのコンポーネントを省略できるかを理解するモデル最適化は、AIを企業の独占から民主化する方向に進む」と、より広い文脈での意義を評価。圧縮アルゴリズムの進化と同じ道筋だと述べています。

4. 既存技術との接続点

lmeyerov氏は「以前、GPU-Direct Storageを使って並列SSDアレイから複数のA100 GPUにデータを供給するデータ分析を探求していた」とコメント。エンタープライズ領域で実績のある技術をコンシューマ向けに応用した点を高く評価しています。

5. コスト度外視の長時間バッチ処理

thatwasunusual氏は「なぜコスト効率がそんなに重要なのか？最終的に最良の結果を得ることのほうが大事では？」と問いかけ、自身のホームラボで一晩かけてレポートを生成している事例を紹介。速度よりも品質と自律性を重視するユースケースの存在を示しました。

懸念・批判的な意見

1. 「0.2 tok/sはインタラクティブとは言えない」

randomtoast氏は率直に「0.2 tok/sは実験には良いが、意味のあるインタラクティブ利用はできない」と指摘。1トークンの生成に5秒。100トークンの応答に約8分。チャットボットとしては確かに厳しい数字です。

2. 電力コスト vs API料金

esquire_900氏はコスト分析を展開。「0.5 tok/sで200〜300Wを消費する。この電力コストを考えると、クラウドAPIの料金のほうが経済的ではないか」と。特にヨーロッパのように電気代が高い地域では、無視できない論点です。

3. 「7Bモデルのほうが実用的では」

7777777phil氏は「クールなハックだけど、同じカードで7Bモデルなら30+ tok/s出る。0.5 tok/sの70Bと、30 tok/sの7Bと、どちらが実用的か」と問いかけました。モデルサイズと速度のトレードオフは、確かに考慮すべきポイントです。

4. 計算効率への疑問

tyfon氏は「RTX 3090で1トークン2秒はcompute-boundではないはず。もっと最適化できるのでは」と技術的な指摘。これに対し開発者のxaskasdf氏は「ボトルネックは純粋に帯域幅。B450マザーボードでPCIe 3.0のx8レーンに制限されている」と回答しています。

5. システム安定性のリスク

セットアップにはIOMMUの無効化、カーネルモジュールのパッチ、VFIOデバイスパススルーなど、かなり「低レベル」な操作が必要です。README自体が「NVMe link failure requiring power cycle」「Data loss on the NVMe device」「System instability」といったリスクを明記しており、プロダクション環境での利用にはまだ課題があります。

バランスの取れた見方

結局のところ、ntransformerは「概念実証（PoC）として極めて優れたプロジェクト」というのが、Hacker Newsの全体的なコンセンサスだと筆者は読み取りました。

現時点の0.2〜0.5 tok/sはリアルタイムチャットには不向きですが、以下のような要素を考慮すると将来性は十分です。

• テスト環境がPCIe 3.0 x8という最低水準のハードウェアであること
• PCIe 5.0環境なら理論上4〜8倍の帯域幅が得られること
• レイヤースキップ機構がさらに最適化される余地があること
• Phase 5の投機的デコーディングが実装されればさらなる高速化が見込めること

Hacker Newsのコメントでexabrial氏が述べた「LLMには計算パワーよりも帯域幅とストレージに特化した、まったく新しいタイプのシリコンが必要だ」という指摘は、この技術の本質を突いています。ntransformerは、その未来への一歩と位置づけるべきでしょう。

日本企業への影響——オンプレLLMの構図が変わる

急速に広がるオンプレLLMのニーズ

日本では、データ主権とセキュリティの観点からオンプレミスLLMへのニーズが急拡大しています。金融機関では顧客データや取引データを外部クラウドに出せない規制があり、ある地方銀行ではオンプレLLMの導入により事務規定管理で従来比130%の応答精度向上を達成した事例もあります。

リコーの「オンプレLLMスターターキット」が2025年日経優秀製品・サービス賞の最優秀賞を受賞したことは、このニーズの大きさを物語っています。

コスト構造の変化

ntransformerの技術が成熟した場合、日本企業のオンプレLLM導入コストに大きな変化が起きる可能性があります。

初期投資が10分の1以下に下がるインパクトは大きいですよね。特に中小企業やスタートアップにとって、「とりあえず70Bモデルを試してみる」ハードルが劇的に下がります。

日本特有の文脈

日本企業にとって、この技術にはいくつかの特有の意味があります。

• 電力コストの考慮：日本の電気料金はヨーロッパほど高くないものの、24時間稼働のGPUサーバーのランニングコストは無視できません。低消費電力のRTX 3090 1枚構成は、電力面でもメリットがあります
• データセンターの制約：東京のデータセンター費用は高額。省スペースな1GPU構成はラックコストの削減にもつながります
• 日本語LLMとの組み合わせ：ELYZAやPLaMo、Swallowなどの日本語LLMの70Bクラスモデルが今後登場した際に、低コストで評価・運用できる環境が整います
• 製造業のエッジAI：工場のエッジデバイスで大規模LLMを動かすという、これまで考えられなかったシナリオが視野に入ります

企業がとるべきアクション

ntransformerはまだPoC段階ですが、この技術トレンドを踏まえて、今から準備できることがあります。

1. NVMe-to-GPU直結技術の動向をウォッチリストに追加

ntransformerのGitHubリポジトリにスターを付けて、Phase 4〜5の進捗を追いましょう。特にPCIe 4.0/5.0環境でのベンチマーク結果が出たタイミングが、実用性判断の重要なマイルストーンになります。

2. ハードウェア調達戦略の見直し

次回のGPUサーバー調達では、以下の点を検討してください。

• PCIe 5.0対応マザーボードを選定する（NVMe直結の帯域幅に直結）
• 専用NVMe SSD用の空きM.2スロットを確保する
• マルチGPU構成だけでなく、1GPU + 高速NVMeの構成パターンも検証対象に入れる

3. バッチ処理ワークフローの棚卸し

社内で「リアルタイム応答が不要」なLLMワークロードを洗い出しましょう。たとえば以下のようなタスクです。

• 夜間の大量文書要約・分析
• 週次レポートの自動生成
• コードレビューの自動化
• 社内FAQの一括更新

これらは0.5 tok/sでも十分実用的であり、ntransformer方式の恩恵を最も受けやすいユースケースです。

4. PoC環境の構築を検討

すでにRTX 3090を保有している企業なら、Linux環境にntransformerをインストールしてPoC（概念実証）を実施することも選択肢です。ただし、以下の注意点があります。

• NVMe直結I/Oには専用のNVMe SSDが必要（ブートドライブは使えない）
• IOMMUの無効化が必要なため、本番環境や共有サーバーでは非推奨
• Linux kernel 6.17+、CUDA 13.1、gcc-14が必要

5. AI導入戦略全体の再構築

ntransformerのような技術は、「クラウドAPI vs オンプレミス」の二項対立を超えた、新しい選択肢を提示しています。自社のAI活用ロードマップにおいて、ワークロードの特性ごとに最適な実行環境を選ぶ「ハイブリッド戦略」を策定しましょう。

AI導入戦略の策定にお悩みの方は、こちらのAI導入戦略ガイドもあわせてご参照ください。100社以上の導入支援実績に基づいたフレームワークをご紹介しています。

まとめ

ntransformerは、NVMe SSDからGPUメモリへの直接データ転送によりCPUをバイパスし、RTX 3090 1枚でLlama 3.1 70Bを動作させるという、ローカルLLMの世界に新しいパラダイムを提示しました。

改めて要点を整理します。

• 技術的革新：3層アダプティブキャッシング + SLEPストリーミングパイプライン + レイヤースキップにより、VRAM 24GBのGPUで70Bモデルの推論を実現
• 現状のパフォーマンス：0.2〜0.5 tok/s。リアルタイムチャットには不向きだが、バッチ処理には十分実用的。mmap比で最大83倍の高速化
• 将来の伸びしろ：PCIe 5.0環境、レイヤースキップの最適化、投機的デコーディングの実装により、数倍の速度向上が見込める
• 日本企業へのインパクト：オンプレLLMの初期投資を10分の1以下に削減できる可能性。特にバッチ処理、文書分析、エッジAIに親和性が高い

正直に言えば、現時点でntransformerを本番環境に投入するのは時期尚早です。しかし、この技術が示した方向性——「VRAMの壁はストレージの帯域幅で突破できる」——は、ローカルLLMの未来を確実に変えるものです。

Hacker Newsで301ポイントを獲得したのは伊達ではありません。今後のPhase 4〜5の進捗、そしてPCIe 5.0環境でのベンチマーク結果から、目が離せません。

参考・出典

1. xaskasdf/ntransformer – GitHub（参照日: 2026-02-23）
2. Show HN: Llama 3.1 70B on a single RTX 3090 via NVMe-to-GPU bypassing the CPU – Hacker News（参照日: 2026-02-23）
3. GPUDirect Storage: A Direct Path Between Storage and GPU Memory – NVIDIA Technical Blog（参照日: 2026-02-23）
4. GPUDirect Storage Overview Guide – NVIDIA Documentation（参照日: 2026-02-23）
5. HighPoint’s adapter enables GPUDirect storage — up to 64 GB/s from drive to GPU – Tom’s Hardware（参照日: 2026-02-23）
6. 「RICOH オンプレLLMスターターキット」が「2025年日経優秀製品・サービス賞 最優秀賞」を受賞 – リコーグループ（参照日: 2026-02-23）
7. セキュア×高速！ローカルLLMが変える企業AI活用とデータガバナンス最前線 – NTTPC（参照日: 2026-02-23）

生成AIの研修・導入支援について詳しくは サービス紹介ページ をご覧ください。