---
# System prepended metadata

title: NVIDIA 解讀 AI Tokenomics：如何將 Token 轉化為商業價值
tags: [YT訪談摘錄]

---

---
type: yt_article
date: 2026-05-22
source: YouTube
youtube_url: https://www.youtube.com/watch?v=zNuOOMM20Tk
channel: "NVIDIA"
video_title: "Inside AI Tokenomics: How to Profitably Turn Tokens Into Business Value | NVIDIA AI Podcast Ep. 299"
tags: ["AI基礎設施", "Tokenomics", "NVIDIA Blackwell"]
---

# NVIDIA 解讀 AI Tokenomics：如何將 Token 轉化為商業價值

> 原始影片：[Inside AI Tokenomics: How to Profitably Turn Tokens Into Business Value | NVIDIA AI Podcast Ep. 299](https://www.youtube.com/watch?v=zNuOOMM20Tk) | NVIDIA | 2026-05-20

## 導言

Shruti Koparkar 任職於 NVIDIA 加速運算團隊，專注於推理（inference）領域。這集 Podcast 的主題是「Tokenomics」，一個在 AI 產業中頻繁出現但缺乏清晰定義的術語。Koparkar 在訪談中拆解了 Token 的估值、供應、需求與貨幣化，提供了一套企業決策者可以直接使用的分析框架。

對投資者來說，核心看點是：Blackwell 相比 Hopper 每瓦產出 50 倍 Token、成本低 35 倍的具體數據，以及代理式 AI 如何大幅放大 Token 需求的邏輯。

## Tokenomics 的四支柱框架

Koparkar 首先定義 Tokenomics：「Tokenomics 是關於 Token 如何被估值、供應、消費和貨幣化的學問。」她將其對應到四個支柱：

「Token utility，關乎 Token 的價值。Token supply，這是攸關 AI 基礎設施決策的層面，思考要投資什麼樣的基礎設施，才能在最小化成本的同時最大化 Token 產出。然後是 Token demand，這是客戶和組織思考的核心：他們有多少用戶、多少使用案例、什麼類型的使用案例，這涉及到他們需要的 Token 數量和速度。最後是 Token monetization，也就是將 Token 轉化為商業價值。」

## Token 價值的兩個決定因素

並非所有 Token 都具有相同價值。Koparkar 指出有兩個關鍵因素：

「第一是嵌入在 Token 中的智慧，這個 Token 承載了多少智慧。另一個是它到達的速度，也就是所謂的互動性。」

關於智慧層面：「Token 的智慧取決於產生這個 Token 的模型。更複雜、更聰明的模型所產出的 Token，普遍具有更高的價值。」模型所能處理的上下文長度也會影響智慧含量：「一般來說，允許模型查看的上下文越長，準確率就越高，Token 的智慧也就越強。」

關於速度：「Token 到達的速度就是 Token 的互動性，本質上是每個用戶每秒生成的 Token 數，也就是 Token 生成的速度。」

由此形成一個價值光譜：「一方面是基礎模型，較短的上下文，以不算快的速度生成 Token；在另一個極端則是更複雜、更聰明的模型，具有更大的上下文，以非常快的速度生成 Token。在這個完整光譜上，分佈著不同的使用案例，你需要將這些使用案例映射到對應的 Token 價值上。」

她特別強調相對價值：「你的使用案例可能不需要那麼複雜、那麼聰明的模型，而額外的價值對你來說完全沒有用處。例如在特定領域應用中，經過微調的小型語言模型可以在非常窄的上下文範圍內提供你所需的價值，在某些情況下甚至能達到更好的準確率。」

關於互動性，她以代理式應用為例：「代理式應用絕對需要高互動性的 Token，但像聊天介面或企業搜尋這類應用，可能不需要那種程度的互動性。這在你思考 AI 部署決策、將使用案例映射到什麼樣的 Token 價值時，是非常關鍵的考量。」

## Token 需求的三層分析框架

企業如何估算所需的 Token 數量？Koparkar 提供了一個三層遞進的分析框架，準確度逐層提高：

「最基本的粗略估算方法是：你有多少用戶、每個用戶每天或每月會發起多少請求或會話、每個請求或會話需要多少 Token。這三個數字加在一起，就是你在單一天或一個月的基本需求。」

但還有幾個重要的乘數效應：

第一個乘數是推理模型的使用：「推理模型使用所謂的『思考 Token』，這些 Token 永遠不會被終端用戶看到。通常在部署 AI 時，你可以設定每個互動允許多少思考 Token 的閾值。所以在估計需求時，你需要思考：我們是否使用推理模型？我們的閾值是多少？這些使用量的高峰和平均值預期是多少？」

第二個乘數是代理式工作流：「代理式是一個巨大的乘數。因為任何使用案例，如果你是以代理式工作流的方式部署，就會有多輪循環發生，可能大幅增加 Token 需求。」

第三個乘數是 KV Cache 命中率：「KV Cache 是模型的短期記憶。當一個輸入請求進入模型時，它需要處理它。但如果這個輸入請求之前已經看過，它實際上會被存儲在 Cache 中，再次進入時就不需要重新計算，可以直接使用緩存的值。」

還有需求變異性：「需求變異性指的是一天中需求如何變化。有時產品在早上時段使用頻繁，但晚上比較少，反之亦然。季節性變異也是如此。例如零售業者或電子商務在節慶期間會看到流量激增。」當然還有使用者成長率需要納入預測模型。

## Token 供應與成本：成本效益分析的關鍵指標

從需求進入供應層面，Koparkar 強調這是 AI 基礎設施決策的核心所在：「當你做這個決策時，你想要的是最大的 Token 可用性和產出，同時最小化 Token 成本。」

她指出了一個常見的決策陷阱：「當談到成本或總擁有成本時，組織和決策者往往會被容易取得的指標所吸引，我所謂的『輸入指標』，例如每 GPU 小時的成本，或每秒浮點運算次數與美元的比率。這些是輸入指標，因為它們沒有告訴你任何關於實際交付的 Token 產出的信息。」

真正的關鍵指標是成本 per Token：「這個指標代表了你的輸入和輸出。它非常簡單，告訴你的是你為生成一個 Token 所支付的費用。基本上就是 GPU 的成本除以這個 GPU 產出的 Token 數量。某種程度上，它結合了輸入和輸出，讓你感受到從 AI 基礎設施獲得的真正 ROI。」

她用 Blackwell 對比 Hopper 的案例說明：「如果你看 Nvidia Blackwell 對比 Nvidia Hopper，僅僅看輸入指標，GPU 小時成本，Blackwell 是 Hopper 的 2 倍。看每秒浮點運算次數與美元的比率，Blackwell 也是 2 倍的優勢。聽起來這是一個巨大的優勢，確實也是，但它甚至沒有觸及 Blackwell 真正效益和價值的表面。」

真正的差異在於：「當談到實際交付的輸出時，Blackwell 相比 Hopper 每瓦能交付 50 倍的 Token。50 倍。相同的基礎設施佔地，Blackwell NVL72 系統比 Hopper 產出 50 倍的 Token，這轉化為 35 倍更低的 Token 成本。」

「最終，如果企業運行在輸出上，也就是 Token，那麼根據輸入來評估基礎設施，但企業的營運卻建立在輸出之上，這基本上是一種根本性的錯配。這就是為什麼成本 per Token 開始觸及真正的 ROI，因為它在許多方面同時衡量了兩者。」

## Extreme Co-Design 的核心意義

Koparkar 區分了整合（Integration）和協同設計（Co-Design）的本質差異：「當你想到整合，你想到的是不同的部分、獨立的單元，然後在後續環節整合在一起。而協同設計是從頭開始同時設計系統的多個部分，因為你知道它們都會被優化以達到同一個目標，最低的 Token 成本。」

為何稱之為「Extreme」：「Nvidia 所做的之所以被稱為 Extreme Co-Design，是因為它的深度和廣度。它不僅僅是計算的協同設計，還包括記憶體、儲存、網路，所有層面。光是 Vera Rubin 平台就有七顆晶片。但它甚至超越硬體本身，還有所有位於上層的軟體，從 CUDA 核心到執行階段再到服務軟體，一直到整個生態系統：晶片合作夥伴、OEM、雲端供應商、各個 OSS 框架。這種協同設計延伸到系統內部、AI 工廠內部，一直延伸到生態系統，這就是為什麼它是 Extreme。」

一個具體例子是 MoE（Mixture of Experts）模型與 Blackwell/NVL72 的配合：「Blackwell 和 NVL72 非常適合 MoE 模型，因為它有助於 GPU 間的通訊，再加上所有軟體層面，Dynamo 的分解服務、任何我們支援的執行階段，不管是 TensorRT、VLLM、SGLang，執行一種稱為廣專家並行（Wide Expert Parallel）的技術，大幅優化這些 MoE 模型的推論效能，從而降低 Token 成本。」

第二個例子是 Vera Rubin 平台：「Vera Rubin 平台是專為代理式 AI 時代打造的。」

## Agentic AI 工作負載的特性

Koparkar 以對比方式解釋了代理式工作負載與對話式工作負載的差異：

「在對話式場景中，用戶提示了一些內容，你提示了一些內容，然後 LLM 說了一些什麼，然後你又說了些什麼，它又回覆。所以作為人類，你與 LLM、與 AI 交替發言。」

「而在代理式情境中，實際上是 AI 在與 AI 交替發言，同時也與軟體互動。因為一個主要代理可以根據用戶輸入決定：讓我做一些推理、決定我需要進行工具調用所以要呼叫某些軟體、決定我需要一個子代理或專業代理去做一些工作，所以它會與專業代理交替發言，直到專業代理完成計算、帶回結果，然後這個過程持續進行。」

「代理式是多輪的，但這種多輪是在沒有用戶參與的情況下進行的。用戶的輸入可能只是『幫我預訂一張去邁阿密的機票』，然後系統就會經過這幾輪處理，最終產生結果。代理式涉及的輪次數量遠比對話式要多，LLM 的調用次數也因此更高，整體 Token 需求自然也更高。」

這就是為什麼 Extreme Co-Design 在代理式時代如此關鍵：「因為你要消耗這麼多 Token，所以你必須降低每次 Token 的成本。每個輪次的延遲，即使只是多幾毫秒，都會累積成最終結果可能延遲好幾秒。」

Vera Rubin 如何從硬體層面支援代理式工作負載：「你需要 Rubin GPU，需要 Groq 3 LPX 解決方案來提供超低延遲；你需要 Vera CPU 因為它會執行所有的工具調用或程式碼生成和測試的沙箱化；你需要 CMX 平台，也就是 BlueField DPU 配合 Spectrum X，允許 KV Cache 在需要時卸載，以便在收到匹配請求時能夠檢索。這就是另一個協同設計的範例，能夠從頭開始開發所有這些組件，帶來巨大的幫助。」

## 軟體在系統優化中的角色

「軟體實際上是現實世界中你實際獲得的交付 Token 輸出和成本，與規格表上所見之間的差異。軟體決定了一切。規格表上的所有東西、系統設計，所有這些都無法完全發揮，除非你有軟體來使用它並真正交付好的輸出。」

「另一個關於軟體的重要一點是，它不能是零散的優化。你需要一個穩健的軟體堆疊，能夠同時開啟所有優化：NVFP4 量化、MTP 或推測解碼、分解服務、廣專家並行、KV Cache 卸載、KV 感知路由等等。要能夠將所有這些優化堆疊在一起，這一點非常重要，因為這就是讓你獲得那 50 倍效能提升的原因，Blackwell 看到的 50 倍更高吞吐量，以及 35 倍更低的 Token 成本。」

軟體生態也在持續演進：「軟體從來不會停止。開源軟體尤其如此，而且不只是 Nvidia 團隊在構建軟體，整個生態系統都在參與：所有 OSS 框架、我們所有的合作夥伴、客戶、開發者社群。每一個小小的優化都是一滴水，不斷累積成 Nvidia 生態系統的巨大優勢。」

一個具體數據：「就拿 VLLM 和 SGLang 這兩個推論執行階段來說，我們在短短大約六個月內看到了 8 倍的性能提升。這是巨大的，因為從相同的基礎設施佔地，你獲得了遠遠更多的 Token 輸出，這也在推低你的 Token 成本。」

## Token 貨幣化：定價策略的三個維度

將 Token 貨幣化的最佳方式是把它想像成「你在生成 Token，然後你在銷售這些 Token」。Koparkar 提出了三個定價維度：

第一個維度是成本導向定價：「你需要思考的是生產這個 Token 的成本是多少，這是 Nvidia 正在幫助降低的最低 Token 成本。然後你當然想要收取比這個成本更高的價格。」

第二個維度是價值導向定價：「這本質上是你願意支付多少的問題，這個 Token 效用對於將要付費的人來說有多大價值。你需要把這個考量進去。」

第三個維度是需求分佈：「在你思考定價之前，你還需要思考需求分佈是什麼樣的。最終你有營收目標和利潤率目標需要達成。要達到你滿意的位置，你需要思考：你的大量需求會來自哪裡？當 Token 效用不是那麼高的時候，需求會如何遞減——可能沒有那麼多買家；但另一方面，效用非常高的 Token，願意支付溢價的人會比較少。你需要把這個需求分佈考量進去。」

某些客戶會在 Token 之上建構附加服務：「當然還有客戶在他們的 Token 之上建構 AI 原生產品或服務。在那種情況下，流程是相似的，但你需要思考你在那些 Token 之上附加的額外價值是什麼。」

## Jevons 悖論與 Token 需求的持續增長

當基礎設施效率提升、成本 per Token 下降時，是否意味著企業需要的 GPU 會變少？Koparkar 以 Jevons 悖論回應：

「你可能會認為：好吧，GPU 的生產力高多了，它們產出了這麼多更多的 Token，你需要的數量會變少吧？答案是絕對不會。原因在於：當你看到效率提升時，新的使用案例就會被解鎖。」

「人們不會遠離智慧，他們會想要使用它。而且你看看我們所看到的宏觀模式，非常能說明問題。當生成式 AI 興起時，人們生成摘要、生成圖像，這很好。然後我們降低了成本 per Token，但他們需要的 GPU 更多了、Token 也更多了。為什麼？因為測試時間擴展和推理。研究人員發現，透過在測試時間進行擴展，我們可以生成更好、更準確、更聰明的回應，這對於使用案例很有價值。不僅如此，現在隨著代理式，我們又看到了同樣的情況。既然我們已經弄清楚了如何高效部署這些 MoE 模型、推理模型，並顯著降低了那些模型的成本 per Token，現在又來到了另一個轉折點：嘿，我們有更多的 Token 了，讓我們用它們做更多事情，這就是代理式革命的所在。」

## 企業將 Token 轉化為商業價值的四種模式

Koparkar 總結了四種主要商業模式：

第一種是直接銷售 Token：「許多 Nvidia 客戶和合作夥伴正在這樣做，比如 Fireworks、Beam 和 Together AI 等。他們都在幫助其終端客戶在他們銷售的 Token 之上建構有價值的服務。」

第二種是 AI 原生公司：「這些公司從第一天起就將 AI 融入產品 DNA 中。例子包括 Perplexity 或 Cursor 等。他們的商業模式建立在 AI 的能力之上，而非將 AI 作為現有產品的增強功能。」

第三種是用 AI 增強現有產品：「這些公司使用 AI 為現有產品注入新能力。例子包括 Shopify、Airbnb 和 Adobe。實際上許多公司兩種模式都在做，既建構 AI 原生能力，也用 AI 來改進其現有產品。例如 Adobe 建構了他們的 Firefly 模型家族，然後用這些模型為 Photoshop 等產品注入新功能。」

第四種是內部營運優化：「幾乎每個現代組織都在嘗試透過部署 AI 來改進其內部營運、內部流程和員工生產力。他們不一定是部署面向外部客戶的產品或服務，而是應用於自身營運的內部環節。」

## 從客戶需求回推的實踐路徑

Koparkar 最後為企業領導者總結了實踐框架：

「最好的起點是先思考最終結果是什麼，通常這從你的客戶開始，無論是外部客戶還是你自己的內部員工和內部流程，這都不重要。你必須從客戶需求、從使用案例往回推。因為就像我們討論過的，使用案例決定了很多事情：用戶和使用案例決定了你會使用什麼類型的模型、決定了你可能需要支援的上下文長度、決定了你需要什麼類型的互動性，也就是智慧和互動性。而這些因素決定了你需要什麼類型的基礎設施。」

「你從 Token 效用和 Token 需求往回推，思考 Token 供應，然後當你掌握了這三者的情況後，你再思考你的貨幣化策略和進入市場策略，然後你就起飛了。」

---
*本文由 AI 根據 YouTube 影片內容生成，僅供參考。*