Nemotron 3 EmbedをVRAM 16GBで動かす｜RTX 5080実測の必要VRAM・速度・NVFP4

結論から書きます。RTX 5080の16GB VRAMに余裕で収まるのは1B系（BF16・NVFP4）で、精度優先の8B-BF16は公式重みが約15.9GBあり16GBとほぼ拮抗します。実際に動かすと、8B単体は載っても大量処理には速度が届きませんでした。「ローカルで動くか」の答えは、選ぶチェックポイント次第です。なお埋め込みモデルはchat LLMとは別物で、公式配布チェックポイントをそのままOllamaでは動かせない、という前提も先に触れておきます。

Nemotron 3 Embed とは何か（RAG・検索基盤向けの埋め込みモデル）

新しいAIモデルが出るたびに気になるのが「自分のPCで動くか」という一点。ただしNemotron 3 Embed に関しては、その前に押さえておくべき前提があります。これはChatGPTやClaudeのように文章で答えるモデルではありません。文章を数値のベクトルに変換する「埋め込みモデル（embedding model）」です。

埋め込みモデルの役割を一言で言えば、エージェントがどの文章を見るかを決める土台の層。RAG（Retrieval-Augmented Generation、外部文書を検索してLLMに渡す仕組み）で文書を検索するとき、質問文と文書をそれぞれベクトルに変換し、近いものを取り出します。この「近い・遠い」を計算する精度が、そのまま検索精度に直結する。NVIDIAはNemotron 3 Embed を、本番規模のRAG・エージェント検索・コード検索・エージェントメモリ向けに公開しました。

コレクションは3つのオープンなチェックポイントで構成されます。精度優先のNemotron-3-Embed-8B-BF16、同じ設計を小さく収めたNemotron-3-Embed-1B-BF16、そしてBlackwell向けに4bit化したNemotron-3-Embed-1B-NVFP4。3つとも双方向アテンションマスク（bidirectional attention masking、前後両方の文脈を同時に見る方式）のTransformerエンコーダで、最終的な埋め込みはトークンごとの表現を平均プーリング（average pooling）して得ます。最大シーケンス長はどのチェックポイントも32,768トークンです。

ライセンスは各チェックポイントともOpenMDW License Agreement v1.1（OpenMDW-1.1）で、公式モデルカードでも商用利用可能と明記されています。出発点となったMinistralモデルはApache-2.0です。各モデルは34言語で評価されています。ベースはMistral系で、8BがMinistral-3-8B-Instruct-2512、1B系はMinistral-3-3B-Instruct-2512を出発点にしています。

埋め込みモデルはchat LLMと何が違うか

もっとも大きな違いは、出力の形です。chat LLMの出力はテキストで、速度は毎秒何トークン（tok/s）で測ります。埋め込みモデルの出力はベクトル（数百〜数千次元の数値の並び）で、速度は毎秒いくつの文章を処理できるか（embeddings/sec や facts/sec）で測る。だから「ローカルLLMのtok/s早見表」の感覚をそのまま持ち込むと、指標がかみ合いません。

もう一つの違いが、使う場面。chat LLMは対話や生成そのものが目的ですが、埋め込みモデルはRAGパイプラインの検索フェーズを担う裏方です。ユーザーの目に直接テキストは見えず、検索の質を通じて間接的に効いてくる。両者はライバルではなく、RAGでは両方を組み合わせて使います。埋め込みで候補文書を絞り、生成LLMがその文書を根拠に回答を書く、という分業ですね。

「ローカルで動くか」の結論と前提

1B系（BF16・NVFP4）はRTX 5080のような16GB級のGPUに対して重み容量では大きな余裕があり、現実的に動作を期待できる側。8B-BF16は公式重みが約15.9GB（理論概算でも8B×2byte≒16GB）あるため、16GBカード単体では活性化や長文脈分の余裕が乏しく、現実的な運用は1B系に寄ります。RTEB総合1位という肩書きは8Bのものですが、「1位だから8Bを選ぶ」と単純化すると、VRAMの壁にぶつかります。

もう一つ、実行フレームワークという前提があります。多くのローカルAIユーザーはOllamaやllama.cppを入り口にしますが、Nemotron 3 Embed はその経路に乗りません。特にNVFP4版はvLLM専用です。Ollamaやllama.cpp自体は埋め込みモデルに対応していますが、Nemotron 3 Embed には公式のGGUFや実行手順が用意されていないため、「Ollamaでpullすれば動くだろう」という感覚のままだと、そもそも起動できません。ここは誤解しないように、公式の実行経路（後述）を前提に置いてください。

公式GGUFなし — 現状はOllama経路で動かせない

なぜOllamaやllama.cppでそのまま動かないのか。両者自体は埋め込みモデルにも対応しています。問題はモデル側で、Nemotron 3 Embed には2026年7月時点でOllama／llama.cpp向けの公式GGUFや公式の実行手順が提供されていません。公式配布のチェックポイントを使う場合、対応する実行経路はTransformers・Sentence Transformers・vLLMで、特にNVFP4版はvLLM専用（1B-BF16はTransformers／Sentence Transformersにも対応）。将来コミュニティ製のGGUFが登場すればOllama系でも動く余地はありますが、現状の公式経路には含まれていない、というのが正確な理解です。

裏を返せば、BF16版なら選択肢はあります。8B-BF16と1B-BF16はsentence-transformersやtransformersから読み込めるので、Pythonで数行のコードを書ける人にとっては障壁が低い。RAGパイプラインを組む開発者層なら、むしろこちらの経路の方が自然でしょう。「ワンコマンドで動かしたい」層と「Pythonで組み込みたい」層で、入り口の設計が分かれる点を最初に理解しておくと、後の手順で迷いません。

3チェックポイントのスペック比較（8B-BF16 / 1B-BF16 / 1B-NVFP4）

3つのチェックポイントは、精度と軽さのトレードオフで役割が分かれています。数字で並べると違いが一目でわかるので、まず表で全体像を掴んでください。以下はNVIDIA公式（RTEB blog）の数値で、スコアはいずれも2026年7月17日時点、平均NDCG@10です。

さらに検索精度の細部を見ると、8B-BF16はRTEBで78.46、ViDoRe-V3 textで60.60、MMTEB（Retrieval）で75.45を記録しています。1B-BF16はそれぞれ72.38・57.74・71.04。前世代のベースラインllama-nemotron-embed-vl-1b-v2がRTEB 61.98だったことを踏まえると、新しい1B-BF16は10.4ポイントも上回っています。世代交代で埋め込み精度が大きく伸びた格好ですね。

表を読み解くと、選択の軸が見えてきます。埋め込み次元は8Bが4096、1B系が2048。次元数だけで検索精度や表現力が決まるわけではありませんが、同じ数値形式で保存する場合、4096次元は2048次元より1ベクトルあたりの保存容量が約2倍になり、距離計算の負荷も増えます。最大入力長は全モデル共通の32,768トークンですが、長文入力時の検索品質や実効メモリはモデルと運用条件によって変わります。違いは精度と、後で見る必要VRAMに出ます。

精度優先の8Bか、軽量の1Bか

選び方はシンプルです。検索精度を最優先し、ハードウェアに余裕があるなら8B-BF16。RTX 5080の16GB VRAMのような消費者向け1枚構成で、容量面の余裕を優先するなら1B系。両者のRTEB差は6.08ポイント（78.46対72.38）で、この差を「無視できる」と見るか「効く」と見るかは、扱う文書量と要求精度で変わります。

1B-BF16と1B-NVFP4の差はさらに小さく、RTEBで0.38ポイント（72.38対72.00）。NVFP4化してもRTEBスコア比で約99.5%を保ちます（NDCG@10ベースのスコア比で、あらゆる意味での「精度」が99.5%という意味ではありません）。この0.38ポイントと引き換えに、NVFP4は必要VRAMを大きく削り、Blackwell世代で最大2倍のスループットを狙える。「1Bで運用すると決めたら、次はBF16かNVFP4か」という二段構えで考えると整理しやすいでしょう。RTX 5080はBlackwell世代なので、NVFP4の恩恵を受けられる立ち位置にあります。

NVFP4とは何か（Blackwell向けに最適化された4bit形式と2倍スループット）

NVFP4は、NVIDIAがBlackwell世代向けに最適化した4bitの数値表現形式です。量子化（quantization、モデルの重みを低精度に落としてサイズと計算量を削る手法）の一種で、従来のBF16（16bit）を4bitまで圧縮します。ビット幅が4分の1になれば、単純計算で重みのメモリ占有も大きく減る。これが1B-NVFP4が最軽量になる理由の核心です。

精度への影響はどうか。NVIDIAはNVFP4版について、Blackwell上でBF16比 最大2倍のスループットを、99%以上の精度保持で実現すると述べています。実際、RTEBスコアはBF16親モデルから0.38ポイントしか落ちていません。4bitまで圧縮しながら検索精度をほぼ保てるのは、雑に丸めているのではなく、丁寧な量子化手順を踏んでいるからです。

その手順を具体的に見ると、NVFP4化は線形層の重みと活性化のみをNVFP4に量子化しています（nvidia-modelopt v0.45.0 を使用）。そのうえでQuantization-Aware Distillation（QAD、量子化した状態で蒸留し直して精度を回復させる手法）を施し、特に長い入力での精度を戻している。単に重みを4bitに落とすだけでなく、落とした後の劣化を蒸留で埋め戻す二段構えです。

ここで注意したいのが、「2倍」という数字の扱いです。これはNVIDIAの公称値で、条件は「Blackwell上でBF16比・最大」。これはNVIDIAが特定条件（Blackwell）で示す公称の最大値であり、RTX 5080で必ず2倍になることを保証するものではありません。実効速度は後述する通り、OSやドライバの版にも左右されます。公称値は選択の目安として受け止め、実機の数字は別途確認する姿勢が安全です。

なぜBlackwellで4bitが効くのか

Blackwell世代のGPUは、低ビット演算を高速に処理するハードウェアを備えています。4bitのような狭いビット幅の計算を、専用の経路でまとめて処理できるため、同じ演算量でもスループットが上がる。NVFP4がBlackwellで最大の利点を得やすいのは、この世代のハードウェア支援を前提に設計されているからです。ただし「Blackwell固有＝他では動かない」わけではありません。対応アーキは次に見るとおり、実際にはもっと広く取られています。

実際、対応アーキテクチャの記載はかなり広めです。NVFP4のモデルカードは、対応アーキとしてAmpere・Blackwell・Hopper・Lovelaceを、対応GPUとしてA100・H100・L40・L4・GB200・RTX PRO 6000などを挙げており、非Blackwell環境も動作・テスト対象に含まれます。つまり「Blackwell以外では動かない」のではなく、「Blackwellが主な最適化対象」と捉えるのが正確です。とはいえNVIDIAの最適化ターゲットとNIM検証環境はBlackwell（GB200）とRTX PRO 6000で、RTX 5080はBlackwellアーキですが公式の検証対象そのものではありません。各GPUでのBF16比の実効速度や効率までは公開されておらず、RTX 5080を含む消費者向けGPUの数値は別途確認が要ります。

パラメータ数から見る必要VRAMの目安

「このモデルは何GB VRAMが必要か」を知りたいとき、まず使えるのがパラメータ数からの概算です。BF16（16bit＝2バイト）なら、必要な重みの容量はおおむね「パラメータ数×2バイト」。この計算で各チェックポイントの重みサイズの目安が出ます。

8B-BF16なら、8B×2バイト＝概算16GB。1B-BF16は1.14Bパラメータなので約2GB台。NVFP4は4bit（0.5バイト相当）なので、1.14B×4bitの純粋な量子化パラメータだけなら0.6GB前後が下限です。ただしこれはあくまで下限で、実際の公式配布ファイル（HuggingFace の Files タブの実サイズ）は8B-BF16が約15.9GB、1B-BF16が約2.28GB、1B-NVFP4が約1.03GB。NVFP4はスケールや非量子化テンソルを含むぶん、この下限より大きくなります。ただしこれらの数値はいずれもHugging Face上の重みファイルの容量であって、実行時の必要VRAMそのものではありません。実運用ではこれにvLLM本体・CUDAコンテキスト・活性化・ワークスペース・CUDA Graphなどが上乗せされるため、必要VRAM＝ファイルサイズとはならず、実際の占有量は環境ごとに確認するのが前提です。第三者評価では、あるプレリリース環境で1B-NVFP4のGPUメモリ使用量がBF16版の約4分の1と観測されていますが、これは特定のチェックポイント・実行系・入力条件・GPUに依存する実測値で、そのまま一般化はできません（詳しい値は後述、GPUが異なる点に注意）。

ここで強調したいのが、この数字はあくまで重みロード分のみの下限だという点。実運用ではこれに、入力長・バッチサイズに応じた活性化や中間テンソル、attention用のワークスペース、フレームワークやCUDAグラフの管理領域が上乗せされます。埋め込み用の双方向エンコーダは、生成LLMのデコード時のように増え続けるKVキャッシュを抱えるわけではなく、メモリの使われ方が異なります。特に最大系列長32,768トークンをフルに使う長文RAGでは、その分の作業メモリが別途必要です。だから「重みが載るから16GBカードで大丈夫」とは単純に言えません。

8B-BF16はRTX 5080 16GBに収まるか（理論値の限界）

公式重み約15.9GB（理論概算では約16GB）を、16GBのカードに載せる。数字だけ見ると「ちょうど収まる」ように見えますが、実態は拮抗、いや余裕が乏しいと表現するのが正確です。VRAMは重みだけで満杯にはできません。デスクトップ環境やドライバが使うベースライン、そして先に触れた活性化・長文脈分の作業メモリを差し引くと、8B-BF16をRTX 5080単体で快適に回すのは厳しい方向に振れます。

なお、NVIDIAはどのチェックポイントについても公式のVRAM要件を公表していません。ここで挙げた16GBはパラメータ数からの計算値であって、公式・実測のVRAM要件ではない点は明確にしておきます。だからこそ結論は「8Bは動くかどうかがVRAM次第でシビア、1B系はVRAM容量上かなり有力」となる。ただしNVFP4版の公式テスト対象にはGB200・RTX PRO 6000・A100・H100・L40・L4が挙がっており、GeForce RTX 5080そのものは含まれていません。容量的な余裕は十分でも、公式の検証結果が公開されていない以上、動作や速度を保証するものではない点は押さえておきたいところです。RTX 5080でNemotron 3 Embed を実運用するなら、まず1B系から入るのが堅実な判断です。8Bを試すなら、より大容量のVRAMを積んだ環境か、系列長・バッチを絞った運用が前提になります。この見立てが実測とどう合うかは、後の「RTX 5080 実測」で確認します。

RTX 5080で動かす実行経路（vLLM / sentence-transformers）

実際に動かす段になると、チェックポイントごとに経路が分かれます。ここを間違えると起動できないので、対応表として頭に入れてください。8B-BF16と1B-BF16はsentence-transformers / transformers / vLLM のいずれでも動きます。1B-NVFP4はvLLM専用（v0.25.0で検証）です。なお公式モデルカードが想定する動作環境はLinuxで、WindowsのRTX 5080でNVFP4／vLLM経路を使う場合はWSL2などLinux環境が実質的な前提になります（BF16版はWindowsネイティブのPyTorch環境でも動作する可能性はありますが、NVIDIAモデルカード上の公式サポートOSはBF16版を含めてLinuxです。vLLM自体もWindowsをネイティブサポートせず、WindowsではWSL利用が案内されているため、確実性を優先するならLinuxまたはWSL2環境を選ぶのが無難です）。

BF16版をsentence-transformersで読み込む場合、埋め込みの取得はシンプルです。ただしNemotron 3 Embed では、クエリと文書で役割を分けるのが公式の使い方です。公式モデルカードは、クエリに query:、文書に passage: のプレフィックスを付ける（またはそれを内部で行う encode_query() / encode_document() を使う）ことを指定しています。これを省くと本来の検索性能を再現できないことがあります。なお encode_query() / encode_document() は新しめのバージョンで整備されたAPIなので、実行前に必要バージョン（CUDA対応PyTorchを含む）を入れておきます。

pip install --upgrade torch "transformers>=5.2.0" "sentence-transformers>=5.4.1"

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("nvidia/Nemotron-3-Embed-1B-BF16", device="cuda")

# クエリと文書は役割を分ける（対応APIなら encode_query / encode_document）
queries = ["ローカルでRAGを組む"]
documents = ["埋め込みモデルの必要VRAMについて説明した文書"]

query_embeddings = model.encode_query(queries)
document_embeddings = model.encode_document(documents)
print(query_embeddings.shape)  # (1, 2048) ← 1B系は埋め込み次元2048

NVFP4版はvLLMで起動します。vLLMは4bit量子化済みの重みをロードし、埋め込み用のランナー（pooling／embed）として推論エンドポイントを立てます。バージョンは検証済みのvLLM v0.25.0を目安にしてください。

# vLLM で NVFP4 埋め込みモデルをサーブ（公式モデルカードの例に準拠）
MODEL_ID=nvidia/Nemotron-3-Embed-1B-NVFP4
MAX_MODEL_LEN=4096
MAX_BATCHED_TOKENS=4096

vllm serve "$MODEL_ID" \
  --max-model-len "$MAX_MODEL_LEN" \
  --max-num-batched-tokens "$MAX_BATCHED_TOKENS" \
  --max-cudagraph-capture-size "$MAX_BATCHED_TOKENS"

モデル自体は32,768トークンまで対応しますが、公式例は起動時間とCUDA Graph用メモリを抑えるため、初期値をすべて4,096に置いています。32,768トークンをフルに扱う場合は、全長でCUDA Graphをキャプチャすると起動時間とGPUメモリ消費が大きく膨らむため、公式モデルカードが示す疎なCUDA Graph capture設定（capture-sizeのリスト）を参照してください。

具体的な起動オプションやAPIの呼び出し形式は、モデルの版によって変わり得ます。上のコマンドは公式カードの例に沿った起点で、細部はNVIDIA公式のモデルカードとvLLM公式ドキュメントの手順に合わせるのが確実です。エンドポイントのパスを自作で継ぎ足さず、公式例と同じ形をなぞってください。

なお vllm serve は既定でHTTPの推論APIを立てます。ローカル利用でも --host 127.0.0.1 のように待受を絞り、LANや外部に露出しないようファイアウォールで隔離してください（vLLM公式もネットワーク隔離を推奨しています）。

NVFP4はvLLM一択、BF16はsentence-transformersが入りやすい（vLLMも可）

経路の選び方を整理すると、判断は「NVFP4を使うかどうか」で決まります。Hugging Face 配布の NVFP4 チェックポイントを手元で直接動かす公式経路は vLLM で、Ollama・llama.cpp・transformers・sentence-transformers には乗りません。ローカル実行に限ればここは代替がききません。別経路として NVIDIA NIM のNVFP4最適化構成や AIクラウド／推論パートナー経由もありますが、NIM の NVFP4 検証GPUは RTX PRO 6000 Blackwell Server Edition と GB200 で、RTX 5080 は含まれません。

一方、まず手早く埋め込みを取り出して挙動を確かめたい、あるいは既存のsentence-transformersベースのRAGコードに組み込みたいなら、1B-BF16 + sentence-transformers が入りやすい。精度をさらに求めて8B-BF16に上げるときも、コード側の経路は同じsentence-transformersのまま、モデル名を差し替えるだけで済みます。VRAMの余裕と相談しながら、1B-BF16で組み始めて必要に応じてNVFP4へ最適化、あるいは8Bへ精度アップ、という段階的な進め方が現実的です。

RTX 5080 実測 — 必要VRAMとembeddings/sec

ここまでは公式ファイルサイズと理論概算の話でした。NVIDIA はどのチェックポイントについても、消費者向けGPUでの必要VRAMやスループットを公表していません。そこで RTX 5080（16GB）で3チェックポイントを実際に動かし、VRAM占有と埋め込み速度を計測しました。以下は下表の環境で測ったスナップショットで、最適化を詰めていない素の構成（FlashAttention を明示導入しない、sentence-transformers / vLLM の既定に近い設定）での値です。条件を変えれば数字は動くので、絶対値ではなく傾向として読んでください。

※「ロード時VRAM」は構成で指標が異なります（1B-BF16=torchの予約量、8B単体=nvidia-smiのGPU総使用量、NVFP4・デュアル=vLLMログのmodel weights）。異なる指標同士の単純比較はできません。GB表記はnvidia-smiのMiB値を約1000で割った概算です。「実用性」列は本記事の計測条件（単発・合成入力）での相対評価で、必要処理件数や許容待ち時間の基準を定めたものではありません。

読み取れることははっきりしています。1B-BF16 はロードで約2.2GB、短いチャンクなら毎秒500件を超えるペースで埋め込める。RAG構築で数万件のチャンクをベクトル化する用途でも、RTX 5080 単体で十分に実用的です。ただし系列長を512、4096と伸ばすとバッチ時のメモリは6〜15GB台まで増え（4096トークンを大きめのバッチで詰めると16GBの上限近くまで迫ります）、素の構成ではスループットも落ちます（長系列は FlashAttention 等の最適化が効く領域）。短〜中程度のチャンクなら16GBに快適、長文を大きなバッチで詰めると余裕は急速に縮む、と押さえておくのが実測に即しています。

問題は8B-BF16です。重み約15.9GBは16GBにギリギリ載りはします——実測でも約15.7GBを使い、空きは約0.6GBでした。ところが速度は64トークンのバッチですら約2.6 docs/sec と、同条件（Windows・Sentence Transformers）の1B-BF16 の200分の1近くまで落ち込みました。512トークン以上は継続すら難しい。速度低下の主因がVRAM余裕の薄さか、モデル規模か、実行バックエンドかは本計測では切り分けていません。少なくとも数万件を一括ベクトル化するインデックス構築のような用途では実用性が低く、「載る＝どんな用途でも実用的に使える」ではないことを示しています（質問を1件ずつ埋め込むオンライン検索なら許容余地はありますが、docs/secだけでは単発レイテンシまでは分かりません）。

8BをデュアルGPUで救済する — 5080＋5060 Ti

単体16GBで詰まる8B-BF16も、GPUを2枚に分ければ景色が変わります。RTX 5080 に RTX 5060 Ti（同じく16GB）を足し、vLLM のテンソル並列（tensor parallel、モデルを複数GPUに分割して載せる方式）で2枚に分散すると、重みは各GPU約7.5GBずつに割れて余裕を持って載り、64トークンのバッチで約21 docs/sec まで回復しました。ポイントは、8Bの重みを16GB×2枚に分散して各GPUの重み占有を約7.5GBまで下げたことで、単体では取れなかった活性化とバッチの余地を確保できたことです（2枚のVRAMは自由に使える単一の32GB空間ではなく、あくまで分散でマージンを作った、という理解が正確です）。ただしこの比較は注意が要ります。単体の約2.6 docs/sec は sentence-transformers（Windows）、デュアルの約21 docs/sec は vLLM（WSL2）での値で、GPUが2枚になっただけでなく実行系とOSも変わっています。連続バッチ処理に強い vLLM の効率もこの差に含まれるため、約8倍のすべてを2枚目のGPUの効果と読むのは正確ではありません。確かなのは、単体では実用にならなかった8Bが、2枚に分けることで短文なら実用的な速度で回るようになった、という点です。

ただし2枚あれば万能というわけではありません。今回の5060 Ti は外付け（OCuLink）接続で、GPU間の帯域は内部バスより細い構成です（RTX 5080はNVLink非対応で、2枚構成はPCIe／OCuLink経由になります）。実測では512トークン以上でスループットが落ち込み、4096トークンでは安定動作しませんでした。ただし長系列そのものの計算・メモリ負荷とGPU間通信のどちらが主因かはプロファイルしておらず、原因は特定していません。いずれにせよデュアルGPUは「8Bを載せて短文を回す」には有効でも、長文RAGまで含めて万能に速くなるわけではない、というのが実測の手触りです。

NVFP4はRTX 5080で約1GBでロードできる — ただし実測環境では推論がまだ不安定

NVFP4版も RTX 5080 上の vLLM で実際にロードできました。ロード時のモデルメモリは約1.0GBで、公式ファイル（約1.03GB）とほぼ一致します。4bit量子化の軽さは、Blackwell の RTX 5080 でもそのまま効いていました。一方、ロード直後の推論で fp4 演算カーネルが不安定になり、素の環境では埋め込みスループットの安定計測までは到達できませんでした。ここで注意したいのは、この不安定さと vLLM の警告は別物だという点です。vLLM が読み込み時に出す「フォーマットは実験的で今後変わりうる」という警告は、ModelOpt NVFP4 のチェックポイント形式が将来変わりうるという意味で、推論の不安定性そのものを示すものではありません。また今回の実測は、公式が明示検証している vLLM 0.25.0 ではなく 0.25.1（未検証版）で行っており、公式コンテナや 0.25.0 での安定性は本記事では未評価です。公式モデルカードは NVFP4 を商用利用可（ready for commercial use）とし、Blackwell 上でBF16比 最大2倍・99%以上の精度保持を掲げています。確認できたのは「RTX 5080＋未検証版vLLMという特定構成では、ロード後の推論に失敗しスループットを計測できなかった」という一点で、fp4 実行系全体の成熟度を一般化するものではありません。当面、この構成で安定して扱えるのはBF16版です。

第三者実測（Zep）が示す規模感 — ただしRTX 5080の値ではない

自前の RTX 5080 実測に加えて、規模感の参考になる外部データも一つあります。RAGメモリ基盤を手がけるZepがプレリリース評価として公開した観測値で、これはワークステーション級のRTX PRO 6000 Blackwell上で、しかもプレリリース版のチェックポイントで計測されたもの。RTX 5080 の数値でも、現行の1.14B配布版の保証値でもないため、そのまま自分のGPUに当てはめてはいけません。

Zepの観測では、1B-BF16 が単一のRTX PRO 6000 Blackwell上で約1,535 short facts/秒、GPUメモリ使用量は約2.6GB。1B-NVFP4 はBF16版のおよそ4分の1まで下がったと報告されています（Zepの報告は「約4分の1」で、BF16版の約2.6GBから概算すると0.65GB相当）。ただしこの「約4分の1」は、Zepのそのチェックポイント・実行系・入力条件・GPUでの実測値で、現行の配布版やRTX 5080でも同じ比率になるとは限りません。参考までに、現行配布の重みファイルで比べるとNVFP4版の約1.03GBはBF16版約2.28GBの約45%で、ファイル容量では4分の1ではありません（総VRAMには非量子化層・スケール・エンジン・ワークスペース・CUDA Graphなども入るため、量子化対象テンソルだけの理論比とはずれます）。絶対値の速度もGPUの演算能力で大きく変わるため、そのまま流用はできません。

一方で速度の絶対値は流用不可。RTX PRO 6000 と RTX 5080 では演算ユニット数もメモリ帯域も別物で、「1,535 facts/秒がRTX 5080でも出る」とは言えません。ここは公式・第三者いずれも消費者向けGPUの実測を出していない空白地帯であり、正確を期すなら自分の環境とワークロードで計測するしかありません。埋め込みは1クエリあたりのミリ秒（ms/query）やバッチ全体のembeddings/secで測るのが実態に近く、生成LLMのtok/sとは指標そのものが違う点も押さえておいてください。

RTEB首位の意味 — 埋め込み精度ベンチの読み方

Nemotron-3-Embed-8B-BF16 が「RTEBで総合1位」という見出しは強い訴求ですが、その中身を正しく読めなければ判断を誤ります。RTEB（Retrieval Embedding Benchmark）は、埋め込みモデルが検索タスクでどれだけ的確に関連文書を上位に返せるかを測るベンチマーク。評価は16の公開タスクにわたり、指標は平均NDCG@10、評価時の系列長は4096トークンで統一されています。

8B-BF16 のスコアは78.46で、2026年7月時点の総合1位。同時に公開された1B-BF16 は72.38、1B-NVFP4 は72.00です。前世代ベースラインの llama-nemotron-embed-vl-1b-v2 が61.98だったことを踏まえると、新しい1B系は同じ軽量クラスで10.4ポイントも押し上げたことになります。ViDoRe-V3 text や MMTEB（Retrieval）でも、8B-BF16 はそれぞれ60.60、75.45と高い水準を示しました。

NDCG@10という指標が示すもの

NDCG@10（Normalized Discounted Cumulative Gain at 10）とは、検索結果の上位10件に、関連度の高い文書がどれだけ上位に並んでいるかを数値化した指標。指標自体は通常0〜1で表され、1に近いほど「本当に必要な文書を、上のほうに正しく持ってこられる」ことを意味します。ただしこの記事で使うRTEBスコアは、これを100倍した百分率形式で、78.46はNDCG 0.7846相当です（NVIDIAの発表も78.5%という形で示しています）。RAGでは、この上位数件がそのまま生成AIに渡る材料になるため、NDCG@10の差は最終的な回答品質へ直結しやすい。

ただし、特定ベンチマークで首位＝あらゆる用途で最良、ではありません。RTEBの16タスクはあくまで公開データセット上の評価であり、扱う社内文書や特定分野の日本語コーパスで同じ順位になる保証はどこにもない。ベンチスコアは「有力な候補を絞る目安」として使い、最終判断は自分のデータで小さく検証してから下すのが現実的です。この検証の手間を惜しむと、ベンチ首位モデルが自社データで平凡だった、という落とし穴にはまります。

RAG構築でどう使うか — 埋め込みモデルの居場所

埋め込みモデルがRAGパイプラインのどこに座るのか、ここを掴むと使いどころが一気に明確になります。RAG（Retrieval-Augmented Generation）は、質問に関連する文書を検索で引き当て、それを生成AIに渡して回答させる仕組み。この「検索で引き当てる」工程の心臓部が埋め込みモデルです。

具体的な流れはこうなります。まず手持ちの文書を適切な長さのチャンクに分割し、それぞれを埋め込みモデルでベクトル化してベクトルデータベースに格納する。ユーザーが質問すると、その質問文も同じモデルでベクトル化し、近いベクトルを持つチャンクを検索で取り出す。取り出した文書を生成AIのプロンプトに添えて回答を作らせる。Nemotron 3 Embed が担うのは、この最初と検索時のベクトル化。生成そのものは別のchat LLMの仕事です。

長文・多言語RAGでの適性

全チェックポイントは最大32,768トークンの入力に対応しており、契約書や技術文書、長いコードのように前後の文脈が絡む長文でも、細切れにせず直接ベクトル化できる余地があります。ただし、チャンクを長くすれば検索精度が上がるとは限りません。1つのベクトルに多くの話題をまとめると意味が平均化され、かえって検索しにくくなることもあります。RTEBの掲載値も系列長4096で評価されているため、実際に使うチャンク長は自分の文書で検証するのが前提です。加えて34言語で評価されており、日本語を含む多言語文書を同じモデルで一貫して扱える点も実務では扱いやすい。

実効速度は環境で変わる — OS・カーネル・ドライバの影響

自分で計測した速度が、なぜ他人の数字と食い違うのか？その答えの一部は、同じGPUでもソフトウェア環境で実効性能が動くという事実にあります。技術メディアPhoronixは、同じBlackwell世代のノート（RTX 5090搭載機）でUbuntu、Windows 11、Arch系のCachyOSを比較検証しました。同一ハードでも、Linuxディストリビューションやカーネル版、GPUドライバ版の違いが実効性能を左右することが実測で示されています。

この観測はNemotron 3 Embed そのものの話ではありませんが、示す教訓は重い。vLLMのバージョン、CUDAやドライバの世代、OSのスケジューラ設定が変われば、同じRTX 5080でも埋め込みスループットは動きます。だからこそ、どんな実測値も「その版・その環境で測ったスナップショット」として扱うべきです。

実測値は版に紐づくスナップショット

Nemotron 3 Embed の実行系はまだ若く、vLLMは検証済みのv0.25.0、NVFP4量子化には nvidia-modelopt v0.45.0 が使われています。これらは今後更新され、そのたびに速度もメモリ挙動も変わり得る。数か月前のブログ記事にあった数字が、手元の最新環境で再現しないのは珍しくありません。

実務での対処はシンプル。速度を根拠に構成を決めるなら、必ず自分の環境で、使う版を固定して計測する。そして計測日と版番号を記録に残しておくこと。これをやっておけば、後日「遅くなった」と感じたときに、モデル・vLLM・ドライバのどれが変わったのかを切り分けられます。環境を書き残さない実測値は、半年後には根拠として使えなくなります。

小型オープンモデルをローカルに積むエコシステム

Nemotron 3 Embed の登場は、単発のニュースではなく、大きな流れの一部として捉えると価値が見えてきます。ここ最近、汎用の巨大モデル一本で全部こなすのではなく、役割ごとに小型の専用モデルを自前で積む動きが加速しています。埋め込みはその代表格。ほかにも、音声認識のような特定タスクに特化した軽量オープンモデルが、少ないパラメータで高い性能を出す形で次々に公開されています。

こうした専用モデルは、汎用巨大モデルに比べて桁違いに軽い。1B級の埋め込みモデルなら数GB、量子化すればさらに小さくなります。つまり、VRAM 16GBのGPU1枚に、埋め込み・生成・音声認識といった役割の異なる小型モデルを同居させ、パイプラインとして組み合わせる運用が現実味を帯びてきました。

汎用巨大モデルより「小型×専用」を積む選択

家庭のGPUで750B級の巨大生成モデルを動かすのは、VRAMの壁で今も非現実的です。一方、Nemotron 3 Embed のような小型専用モデルは、重み容量から見てRTX 5080一枚に十分収まる側にいる。この対比が、個人や小規模チームの戦略を変えます。「一つの万能モデルを無理に載せる」より「小さく確実に動く専用モデルを複数役割分担させる」ほうが、限られたVRAMを効率よく使えるからです。

RAGを組むなら、埋め込みは軽量なNemotron 3 Embed の1B系に任せ、生成は別の中規模モデルに振る。この分業なら、限られた16GB VRAMの取り合いを大幅に減らせます（同一GPUに両方を載せればVRAMは共有するので、ゼロにはできません）。汎用巨大モデルを待つのではなく、手元で回る小型専用モデルを組み合わせる。Nemotron 3 Embed は、その組み合わせの入口に置きやすいモデルです。

同じNemotron系でも、75B-A9Bクラスを手元のGPUで動かせるかは、必要VRAMの桁が変わるため別途検証しています。

まとめ — RTX 5080でどう向き合うか

Nemotron 3 Embed をRTX 5080で扱う判断は、チェックポイントごとに分かれます。1B-BF16 と 1B-NVFP4 は重みが数GB規模で、16GB VRAMに余裕を持って収まる。短〜中程度の系列なら実測でもバッチの余地が残るため、RTX 5080での実運用は1B系、なかでも安定して回る1B-BF16 が現実的な主軸になります。8B-BF16 は公式重みが約15.9GB（理論概算では8B×2byte≒約16GB）で、RTX 5080の16GBとほぼ拮抗。実測でも約15.7GBを使って空きは約0.6GB、64トークンでも約2.6 docs/secと、単体では大量の一括処理には速度が届きませんでした。RTX 5080 で8Bを使うなら、5080＋5060 TiのようなデュアルGPUでテンソル並列に分け、重みを各GPUに分散する（各約7.5GB）のが現実的で、実測では短文で約21 docs/secまで回復しました（ただし単体はSentence Transformers、デュアルはvLLMで実行系も異なり、外付け接続では長系列で伸び悩みます）。

実行経路の前提も外せません。NVFP4版の公式実行経路はvLLMで、2026年7月18日時点では公式GGUFや公式実行手順がなく、公式配布のチェックポイントをそのままOllama／llama.cppで動かすことはできません。Ollamaで手軽に、という前提の読者は、ここでvLLM環境の用意が必要になる点を最初に押さえてください。RTEB首位は精度の指標であって、あらゆる用途での最良を保証するものではない。公式値や第三者ベンチはまだ消費者向けGPUの数字が乏しく、Zepの値もRTX PRO 6000という別GPUのもの。本記事のRTX 5080実測も単発・素の構成での目安なので、実効速度は最終的に使う構成と版で計測してこそ根拠になります。

精度を最優先し環境も整うなら8B-BF16、軽さと導入のしやすさなら1B-BF16、VRAMを最小化したいなら1B-NVFP4（ただし今回の RTX 5080 実測では fp4 推論が不安定で速度は安定計測できず、当面はBF16版が無難）。この3択を、自分のVRAM・実行系・用途に照らして選ぶのが、Nemotron 3 Embed とローカルで付き合う出発点になります。

よくある質問

Q. RAGでは埋め込みモデルと生成LLM（chat LLM）のどちらか一方でいいですか？

両方使います。両者はライバルではなく分業の関係です。埋め込みモデルが質問と文書をベクトル化して候補を絞り、生成LLMがその文書を根拠に回答を書きます。Nemotron 3 Embed が担うのは検索フェーズのベクトル化で、回答生成そのものは別のchat LLMの仕事です。RAGを組むなら、埋め込みは軽量な1B系に任せ、生成は別モデルに振ると、16GB VRAMの取り合いを大幅に減らせます（同一GPUに載せる場合はVRAMを共有します）。

Q. どうしても8B-BF16をRTX 5080で使いたい場合は？

8B-BF16は公式重みが約15.9GB（理論概算でも約16GB）あり、16GBのRTX 5080では活性化や長文脈分の余裕が乏しくなります。単体で試すなら、系列長やバッチを絞った運用が前提です。精度をフルに活かしたいなら、より大容量のVRAMを積んだ環境のほうが安心できます。公式VRAM値は非公開のため、実際に動かすなら小さい系列長から占有量を確認しながら詰めるのが安全です。

Q. NVFP4にすると精度はどれくらい落ちますか？

1B-NVFP4のRTEBは72.00で、BF16親モデルの72.38からわずか0.38ポイントの低下（RTEBスコア比で約99.5%）に収まっています。4bitまで圧縮しても、量子化後に蒸留で劣化を埋め戻す手順を踏んでいるためです。引き換えにNVIDIAはBlackwell上でBF16比 最大2倍のスループットを掲げています。ただしこれは公称・最大値で、実行系はvLLM専用という制約がある点に注意してください。

Q. RTEBで総合1位なら、自分の用途でも最良ですか？

そうとは限りません。RTEBは16の公開タスクでの評価で、扱う社内文書や特定分野の日本語コーパスで同じ順位になる保証はありません。ベンチスコアは有力な候補を絞る目安として使い、最終判断は自分のデータで小さく検索精度を検証してから下すのが現実的です。ここを省くと、ベンチ首位モデルが自社データでは平凡だった、という落とし穴にはまります。

Q. 埋め込みをローカルで動かせば、文書は外部に出ませんか？

クラウドの埋め込みAPIはベクトル化のたびに文書を外部へ渡しますが、手元のRTX 5080で埋め込みを完結させれば、その経路をなくせます。ただし「ネットワークから一切出ない」と断定するには、ベクトルDBやRAGの他コンポーネントの通信も含めて構成全体を確認する必要があります。正確には、埋め込み処理単体で外部の推論APIに依存しなくなる、という理解になります。

参考資料

• NVIDIA: Nemotron-3-Embed-8B-BF16 モデルカード（Hugging Face）
• NVIDIA: Nemotron-3-Embed-1B-BF16 モデルカード（Hugging Face）
• NVIDIA: Nemotron-3-Embed-1B-NVFP4 モデルカード（Hugging Face）
• NVIDIA NeMo Retriever Text Embedding NIM サポートマトリクス
• NVIDIA GeForce RTX 5080 製品仕様（16GB GDDR7）
• NVIDIA: Nemotron 3 Embed が RTEB で首位（Hugging Face Blog）