NVIDIA AI Models 把選模變成流程

NVIDIA 的 AI Models 頁面把選模型這件事，整理成一套能直接拿去部署的流程。

我用這種 model directory 很久了，老實說大部分都很煩。看起來像在幫你，但真的要上線時，你只是在十幾個分頁之間來回跳：一半是行銷，一半是文件，沒有一個先回答我最在意的三件事：該跑哪個模型、該在哪裡跑、跑太慢或太貴時要怎麼辦。

NVIDIA 的 AI Models 頁面比多數同類頁面好一點，但我還是得用開發者腦袋讀，不是用看型錄的心情讀。它其實比較像一張路由表，從模型家族一路指到部署路徑：DeepSeek、Gemma、gpt-oss、Kimi、Llama，以及其他家族。等我不再把它當目錄，而是當 decision tree，整頁就順了。

我先講結論：這頁不是在說「這裡有一些模型，祝你好運」。它是在說「先選模型家族，再選你的路：用 NIM 快速原型、用 TensorRT-LLM 做優化、用 NeMo 做客製、或用 Ollama、vLLM、Hugging Face、llama.cpp 本地跑。」這才是有用的部分，其他多半是品牌包裝。

這篇我會把這頁拆成我在真實專案會怎麼用的工作流，最後再給你一段可以直接複製的模板。你不用再把一週時間燒在 benchmark 嘉年華裡。

先別把它當 catalog，看成路由表

"Explore and deploy top AI models built by the community, accelerated by NVIDIA’s AI inference platform, and run on NVIDIA-accelerated infrastructure."

白話一點就是：NVIDIA 想把這頁做成模型選擇的入口，但真正有價值的地方，是它把你導向部署路徑。頁面先按模型家族分類，接著立刻把你推去能把這些模型在 NVIDIA 硬體上跑起來的工具。

我之前在選模型時最常犯的錯，是拿模型名稱互相比。這完全反了。真正該比的是 operational path。因為一個 paper 上很漂亮的模型，如果你唯一能走的路是你不想維護的 stack，那它對你就是麻煩，不是答案。

這頁每個家族的節奏都差不多：先看 sample，再接 runtime，再做 inference 優化，最後拿 production-ready 版本。這才是骨架。它比較像「選路線」，不是「逛模型」。

我會這樣做：

• 先看部署限制：edge、workstation、單卡、還是 cluster。
• 再看頁面建議的 runtime 路徑：NIM、TensorRT-LLM、vLLM、Ollama、Hugging Face。
• 最後才比模型大小、架構和 benchmark 數字。

這頁一直重複這個模式，不是因為它沒內容，而是因為它在壓縮常見摩擦：模型發現、整合、優化、部署。這才是流程。其他都是小標題。

DeepSeek 是性能優先的示範案例

"DeepSeek is a family of open-source models that features several powerful models using a mixture-of-experts (MoE) architecture and provides advanced reasoning capabilities."

翻譯一下就是：DeepSeek 是這頁拿來示範「架構和能力一樣重要」的模型家族。MoE 會直接改變你看待性能的方式，因為你不只在問「它聰不聰明」，你還要問「我能不能用合理成本把它跑到夠快」。

這一段 NVIDIA 很明顯在推 optimization。它把 TensorRT-LLM 放在 data center 部署路徑、把 NIM 放在快速試跑和 production 包裝、把 NeMo 放在客製化。這三個一起出現，意思很明確：它預期你從實驗一路走到上線，不要每一步都換一套系統。

我看過太多團隊卡在「模型品質」的討論，結果真正的 blocker 是 throughput。模型再強，如果成本結構 app 吃不下去，那就是不對的選擇。這也是為什麼頁面一直丟 performance notes。像 DeepSeek-R1 8K/1K 那段，提到在 Blackwell GB200 NVL72 上相對 Hopper H200 有 15x performance benefit 和 revenue opportunity。我不把它當成對所有場景的保證，我把它當成訊號：NVIDIA 要你用硬體角度看模型，而不是只看名字。

我會這樣做：

• 如果你做的是 reasoning-heavy app，先拿 DeepSeek 跑你的 latency 和 token budget。
• 你在 NVIDIA GPU 上想把 inference 壓到更好，就先看 TensorRT-LLM。
• 你想要的是包好的部署路徑，就看 NIM docs。
• 你要把模型改成吃你自己的資料，就看 NeMo docs。

實務上，DeepSeek 不是單純一個模型家族，它是 NVIDIA 想教你怎麼看 open models 在自家硬體上的模板：先選模型，再選加速路徑。

Gemma 是「到處都能跑」的那種實用派

"Gemma is Google DeepMind’s family of lightweight, open models."

白話就是：如果你需要的是比較小、但還能進正經部署流程的模型，Gemma 就是這頁給你的答案。頁面直接提到它支援 data center GPU、Windows RTX、Jetson devices。這不是裝飾，這是在告訴你它是拿來到處搬的。

我喜歡這段，因為它最不浮誇，也最有用。不是每個專案都需要一個巨無霸 reasoning monster。有時候你只需要一個能先在 workstation 上跑、很快能試、之後又能搬進產品的模型。Gemma 比那種「看起來很大」的路線更適合這種工作。

頁面還提到 Gemma 3n 原生支援多語與 multimodal，包含 text、image、video、audio。這很重要，因為它會直接改變你能做的 app 類型，不用為每種 modality 再拼一套系統。NVIDIA 接著把你導去 NIM 做 production-grade support、NeMo 做 customization、TensorRT-LLM 做 optimization、Ollama 做快速本地實驗。

我會這樣做：

• 如果你的主要限制是跨裝置可攜性，先選 Gemma。
• 先用 Ollama 跑一輪本地測試。
• 如果你要在 NVIDIA GPU 上衝 throughput，就用 TensorRT-LLM。
• 如果你要做正常的 fine-tune 或 adaptation，就走 Hugging Face 的工具鏈。

頁面也把 sample application 和 Jetson demo 拉出來，這其實是在說：第一版 prototype 不要想太多，先在目標裝置類型上跑起來，看真正的痛點在哪。

gpt-oss 在提醒你：open-weight 也要有 runtime 計畫

"NVIDIA has optimized both new open-weight models for 10x inference performance on NVIDIA Blackwell architecture, delivering up to 1.5 million tokens per second (TPS) on an NVIDIA GB200 NVL72 system."

翻譯一下就是：NVIDIA 沒把 gpt-oss 當成單純又一個模型家族，它是在講硬體加 runtime 的整體故事。模型重要，但 runtime 和 kernel 工作一樣重要。你如果忽略這件事，就會錯過這頁真正想講的東西。

我對這種直接丟 throughput 數字的頁面一向很警惕，因為上下文不夠時很容易變成 benchmark 口水戰。不過這裡我不需要把它當成比賽，也看得出模式。它在說同一個模型，跑在 TensorRT-LLM、vLLM、SGLang、Ollama 或其他支援路徑上，結果會差很多。這才是重點。

這也很清楚地看出 NVIDIA 的生態策略。頁面提到 OpenAI 的 gpt-oss、TensorRT-LLM、vLLM、llama.cpp，還有 Ollama。這不是亂列，是在示範同一個模型家族可以從多個開發入口切進去。

我會這樣做：

• 如果你要 open-weight 彈性又想快點上線，先看 gpt-oss。
• 如果瓶頸是 NVIDIA GPU 上的 inference，先試 TensorRT-LLM。
• 如果團隊本來就在 vLLM 或 SGLang，那就別硬換。
• 如果你要 local-first 開發迴圈，就用 Ollama 或 llama.cpp。

我的判斷很直接：這段最清楚地說明，model choice 已經不能跟 serving choice 分開看。你如果沒一起想，其實你還沒真的在選模型，你只是在蒐集名字。

Kimi 告訴你，scale 變大後事情就沒那麼乾淨

"Kimi K2 is a state-of-the-art MoE language model with 32 billion activated parameters and 1 trillion total parameters."

白話就是：Kimi 是這頁拿來提醒你，headline 數字只是一半故事的地方。activated parameters 跟 total parameters 不是同一件事，NVIDIA 很明顯在期待你理解這件事，因為這種模型的 serving path 才是重點。

頁面說 Kimi K2 Thinking MoE 在 NVIDIA GB200 NVL72 上，相較 NVIDIA HGX H200 有 10x performance leap，還提到 Fireworks AI 在 NVIDIA B200 上部署 Kimi K2，跑到 leaderboard top performance。我不把這些當成對所有環境都成立的真理，我把它們看成訊號：這頁要你把 scale、routing、infrastructure 放在一起看。

這是很多團隊容易搞混的地方。他們聽到 open model 就以為 operational burden 比較低。沒有這種事。大型 MoE 模型如果硬體和 serving topology 沒規劃好，很容易變成爛攤子。頁面一直把你拉回 optimized deployment path，就是因為真正常見的麻煩都在這裡。

我會這樣做：

• 當你真的需要大型 open model，而且基礎設施撐得住，再考慮 Kimi。
• 想要包好的部署方式，就先看 NIM。
• 想把手上的硬體榨乾，就看 TensorRT-LLM。
• 先用頁面上的 sample 去驗證你的 workload 是 reasoning-heavy、chat-heavy，還是 agent-heavy，再決定要不要跳下去。

我會把 Kimi 當成「先看細節」的家族。DeepSeek 是 performance-first 的示範，Gemma 是 portable 的示範，Kimi 則是在提醒你：scale 一大，部署問題就會開始反咬人。

Llama 是熟悉的預設值，但 NVIDIA 仍然要你做優化

"Llama is Meta’s collection of open foundation models, most recently made multimodal with the 2025 release of Llama 4."

翻譯一下就是：Llama 是最多開發者本來就認得的家族，所以 NVIDIA 把它當成整頁最容易進入的入口。頁面不是只說「這裡有 Llama」，而是說 NVIDIA 跟 Meta 一起推進 TensorRT-LLM 的 inference、提供優化過的 NIM microservices，還能用 NeMo 做 customization。

我猜大多數團隊會從這裡開始，因為 Llama 最不陌生。這沒問題，熟悉本身就是優勢。但頁面還是在重複同一件事：不要停在模型名。你要決定的是本地實驗、優化 serving，還是拿自己的資料去做客製。

我自己也常踩這坑：以為預設模型會有預設的 operational path。通常不是。Llama 這段其實就是 NVIDIA 在說，「你可以用你熟的東西，但如果你在意性能，就請走我們優化過的 stack。」這話很現實，我也認同。

我會這樣做：

• 如果團隊本來就熟 Llama，想最快做出能跑的 prototype，就先用它。
• 如果你想要 production-ready microservice，不要自己從零接，直接看 NIM。
• 如果你在 NVIDIA GPU 上要更好的 throughput，就看 TensorRT-LLM。
• 如果業務邏輯吃你的資料，就用 NeMo。

這頁把 Llama 拉長不是沒原因。它是那條橋，從「我知道這模型是什麼」走到「我現在得像個成年人一樣把它跑起來」。

真正的模式是 model、runtime、optimize、ship

"Get started with the right tools and frameworks for your development environment."

白話就是：NVIDIA 想把這頁做成工作流清單。每個家族都走同一條路：先探索模型、再接 runtime、再做 inference 優化、最後部署成 production-ready microservice。這個順序就是我會抄的地方。

很多 model page 都做錯：不是直接丟一排 checkpoint 給你，就是把 deployment path 包在太多平台話術裡。NVIDIA 至少有把順序講出來，雖然裡面塞了很多 product 名稱。只要你看懂順序，這頁就會從吵鬧變成有用。

如果是我接一個真實專案，我會這樣排：

• 先根據 use case 選一個模型家族，不要先看 hype。
• 先用最快的路徑做 prototype，通常是 NIM 或 Ollama。
• 在自己的硬體上量 latency、memory use、token throughput。
• 需要優化時再上 TensorRT-LLM。
• 真的需要改資料、改行為，再用 NeMo。

這個順序可以避免我把時間燒在錯的層。很多團隊是先 fine-tune，結果根本還沒證明 use case；或是先做優化，卻連基本需求都還沒跑通。這頁有價值，就是因為它在推你走對順序。

而且 NVIDIA 這堆基礎設施名字你不用全背：Blackwell、Hopper、Jetson、RTX、DGX、NIM、NeMo、TensorRT-LLM。你只要知道每一層在解什麼問題，夠了。

可抄的模板

# 參考 NVIDIA AI Models 頁面的模型選擇模板

## 1) 我要做什麼？
- Use case:
- 主要輸入：text / image / audio / video / multimodal
- 主要限制：latency / cost / portability / customization / throughput
- 目標部署：local / edge / workstation / data center / cloud

## 2) 先選哪個模型家族？
- DeepSeek：reasoning-heavy、重視效能的工作
- Gemma：輕量、可攜、跨裝置流程
- gpt-oss：open-weight、重視 serving/runtime
- Kimi：大型 MoE、需要處理 scale 和 routing
- Llama：熟悉的通用 foundation model 路線
- Other:

## 3) 第一條跑法是什麼？
- 快速原型：NIM / Ollama / Hugging Face / llama.cpp
- Serving stack：TensorRT-LLM / vLLM / SGLang
- 客製化：NeMo / Transformers / PyTorch
- 硬體目標：Blackwell / Hopper / RTX / Jetson

## 4) 我先量什麼？
- Tokens per second:
- Time to first token:
- Memory footprint:
- Cost per request:
- 自己 prompt 的品質表現:

## 5) 如果它可行，下一步是什麼？
- 保留模型，先優化 serving
- 做 quantization
- 改用 NIM 打包
- 用 NeMo 做 fine-tune 或 adaptation
- 換更小或更快的家族

## 6) 決策規則
如果模型夠好但太慢，先優化 runtime。
如果模型太貴，先試更小的家族，不要急著 fine-tune。
如果模型需要我的資料，先 benchmark，再做 customization。
如果部署目標變了，就重新選家族，不要硬套舊方案。

## 7) 給內部評估的可複製 prompt
我需要為以下應用選一個 AI model：
[describe app]

限制：
- Deployment target: [local/edge/cloud/data center]
- Latency budget: [number]
- Cost budget: [number]
- Input types: [text/image/audio/video]
- Need for customization: [low/medium/high]

請從以下家族中推薦一個：
- DeepSeek
- Gemma
- gpt-oss
- Kimi
- Llama

再推薦第一條 runtime 路徑：
- NIM
- TensorRT-LLM
- Ollama
- vLLM
- llama.cpp
- NeMo

請用一段話說明原因，並列出我應該先跑的第一個 benchmark。

這個模板好用的地方，是它逼你把討論從 model fandom 拉回 shipping。這才是重點。如果你連部署路徑都講不清楚，那你其實還沒真的選模型。

這篇是根據 NVIDIA 的 AI Models 頁面整理的：https://developer.nvidia.com/ai-models。我的拆解方式、敘事順序和模板是原創；模型家族摘要、部署路徑與頁面上的公開內容，則來自 NVIDIA 與其連結文件。其他延伸連結包含 NIM、TensorRT-LLM、NeMo、vLLM、Ollama。