Cost per Query
3 秒看懂
Cost per Query(單次查詢成本)是大語言模型(LLM)從實驗室走向規模化商用的生死線。它衡量的是為一個使用者請求生成完整回覆(全鏈路算力、電力、網路、運維攤分)所消耗的全口徑經濟成本。它直接決定了 API 的定價底線、自建方案的盈虧模型,以及模型架構設計能否穿越“成本-體驗”的剪刀差。
3 分鐘產業解釋
在 ChatGPT 引爆市場之前,行業衡量模型成本的核心指標是“訓練一次要燒多少錢”。但當模型變成服務,每天要響應數十億次使用者請求時,推論成本就上升為壓倒性的財務主題。Cost per Query 把一切工程努力——模型架構(稠密 vs 混合專家)、系統軟體(量化、核心融合、KV 快取管理)、硬體效率(視訊記憶體頻寬、算力利用率)、部署策略(批處理、彈性伸縮)——收斂為一張商業賬單:每回答一個問題的花費。雲端廠商和模型公司圍繞這一指標展開“價格戰”:同等效果下,誰能提供更低的單次查詢成本,誰就能掌握開發者生態和終端定價權。近 18 個月,主流模型級別推論的單位成本下降幅度超過 90%(行業粗略感知,因未檢索到確切報告,此處為基於公開定價趨勢的估算)。其背後是一輪從“暴力出奇跡”到“精算到每一個浮點操作”的技術體系重構。
15 分鐘專家深入
Cost per Query 的構成遠比直觀的“GPU 使用時長 × 租賃單價”複雜。它必須覆蓋五層:
- 硬體成本層:GPU/ASIC 的折舊或雲端端例項計費,通常以每卡·小時為單位。
- 能源與散熱:資料中心電力費用,隨晶片功耗和冷卻方案變化,大致與硬體成本呈一定比例(高密度部署下電力成本佔比上升)。
- 分散式通訊開銷:對於超出單卡視訊記憶體的大型模型,多卡之間的張量並行、流水線並行會引入大量通訊,延長單次查詢的端到端延遲,從而增加“卡時”佔用。
- 服務架構與排程損耗:請求排隊、字首快取(prefix caching)、KV 快取管理失效等。
- 可用性冗餘:為保證服務等級協議(SLO)中 99.9% 以上的可用性,需要額外增加備卡、跨地域冗餘,這部分“空轉成本”也會攤入每一筆有效查詢。
技術上,單條查詢的處理本質上是“在極嚴格的延遲約束下完成計算和訪存密集型任務”。典型對話場景要求首 token 延遲在 200~500 毫秒以內,生成速度 ≥30 tokens/秒。為了把硬體利用率做上去,推論系統會盡量攢批(batching),引入“連續批處理”(continuous batching)動態插入新請求。但這又必須在延遲 SLO 和批大小之間做權衡:批越大,單 token 生成時間越長,可能突破使用者的耐心閾值,導致體驗劣化。因此,Cost per Query 的最優解通常不是硬體利用率最高點,而是滿足 SLO 時的成本最低點。
此外,輸入長度(系統提示、聊天曆史)與輸出長度的比例會顯著影響單次查詢成本。輸出 token 的計算和訪存量遠大於輸入段的上下文處理(後者可通過 KV 快取複用共享字首),因此 API 定價普遍區分輸入、輸出價格(輸出 token 價格通常是輸入的 3~5 倍,具體倍數因模型而異,為定性觀察)。複雜應用(如帶聯網搜尋增強生成)會大幅增加輸入 token,抬升成本。
技術原理(最深)
從第一性原理拆解,每生成一個 token 的成本可以抽象為:
成本 / query ≈ Σ ( 單卡時間 × 卡數 ) × 全摺疊單價 / 有效查詢數
單卡時間 / token = max( 計算時間, 訪存時間 )
計算時間 = (2×引數量) / (單卡可用算力 × BF16/FP8計算效率)
訪存時間 = (引數量 × 位寬 + KV快取增量) / (視訊記憶體頻寬 × 頻寬利用率)
為了清晰化,下圖為單卡一次 decoding 步驟的簡化瓶頸模型(程式碼塊內為 ASCII 描述):
┌─────────────────────────────────────────┐
│ Query (single step) │
└─────────────────────────────────────────┘
│
┌──────────────▼──────────────┐
│ Load Weights from HBM/GDDR │ ← 引數量×精度位元組
│ + Load KV Cache (history) │ ← 隨序列長度增長
└──────────────┬──────────────┘
│
┌──────────────▼──────────────┐
│ Matrix Multiply (FMAs) │ ← 約 2×引數量 次浮點運算
└──────────────┬──────────────┘
│
┌──────────────▼──────────────┐
│ Store new KV cache entry │
└──────────────┬──────────────┘
│
┌─────▼─────┐
│ Next token│
└───────────┘
瓶頸判斷:若 2×引數量 / 算力 < (引數量×2位元組 + KV增量) / 頻寬
→ 瓶頸在視訊記憶體頻寬(典型大型模型 decoding 的常態)
→ 成本主要由“搬運模型引數”決定,而非計算
關鍵引數(以典型 7B~70B 稠密模型、高階 GPU 為例,以下均為基於行業常識的定性範圍,未獲取檢索證據):
- 模型權重訪存量:引數數量 × 每個引數位元組數(FP16 為 2 位元組,INT8 為 1 位元組)。
- KV 快取訪存量:2×層數×頭數×每頭維度×精度位元組×序列長度。在長上下文(如 32k、128k)場景下,KV 快取體積可能數倍於模型權重。
- 算術強度:單 token 的計算量(約 2×引數量 FLOPs)與總訪存量之比極低,導致傳統計算利用率(MFU)在 decoding 階段僅有 1%~3%(由硬體設計決定,該量級屬業界共識)。
- 批處理效應:增大批大小(同時處理多個請求)可以複用模型權重的一次載入,將權重訪存時間分攤到多個 token 的生成上,從而降低每 token 視訊記憶體頻寬成本。這是降低成本最有力的槓桿之一,但受 SLO 限制。
量化壓縮:將權重和啟用值由 FP16 降低到 FP8 或 INT4,可將訪存量壓縮 2~4 倍,幾乎成比例地降低每 token 頻寬成本。同時需配合硬體對低精度計算的加速能力,避免額外格式轉換開銷。
投機解碼(Speculative Decoding):用小模型快速生成若干個“草案” token,再由大型模型並行驗證,每次驗證可接受多個 token,從而在保持大型模型輸出質量的同時,用更少的卡時生成更多 token,降低單 query 成本。其增益取決於小模型與大型模型的匹配度,以及驗證長度。
混合專家(MoE)架構:總引數量雖大,但每次前向僅啟用部分專家(如 8/64 的專家)。在 decoding 時,啟用引數訪存量接近總引數的一部分,而非全部。但 MoE 引入 All-to-All 通訊,在大規模張量並行情境下可能增加通訊成本。最終成本優勢體現在加速訪存受限的 decoding 階段,但需要額外考量通訊延遲。
硬體拓撲影響:非統一視訊記憶體訪問(如 Grace-Hopper、NVLink-C2C 等)可以緩解部分瓶頸,但改變不了訪存牆本質。推論成本主要由視訊記憶體頻寬總量與頻寬利用率決定,新一代硬體通過增加 HBM 頻寬、堆疊更多堆疊等路線持續壓降單 token 成本。
技術演進史
- 2020 年之前:推論成本不敏感,模型引數量小,純 GPU 推論即可滿足延遲,社群關注焦點在訓練。
- GPT-3 時代:175B 稠密模型的推論首次暴露出“大型模型推論極貴”,但僅少量企業試用,成本未成核心焦慮。
- 2022 年 ChatGPT 釋出:千萬級 DAU 瞬間將推論成本推至百萬美元量級/天(公開採訪資料),倒逼系統級最佳化。PagedAttention(vLLM)將 KV 快取從固定預分配改為按需分頁,視訊記憶體利用率提升數倍,直接降低單位成本。
- 2023–2024 年:連續批處理(continuous batching)、GPTQ/AWQ 等權重量化方案成熟,INT8 推論成本比 FP16 降低約 30%~50%(行業估算,因具體軟硬體組合差異大,僅示量級);投機解碼、融合運算元進一步發力。MoE 架構(如 Mixtral 8x7B、DeepSeek-V2)因其活躍引數少,推論成本較同等效果稠密模型大幅壓縮,引發“從稠密走向稀疏”的推論成本革命。
- 2024–2025 年初:推論成本競爭白熱化,頭部 API 廠商多次降價,免費額度增多;硬體側,HBM3e 頻寬提升、大 batch 推論專用晶片(如 Groq LPU)或通過架構創新繞過傳統 GPU 訪存瓶頸(定性描述);在長上下文成為標配後,KV 快取壓縮技術(如 GEAR、CacheGen)從另一個維度削減單位查詢成本。
- 未來趨勢:單 query 成本仍有望持續下降,但降速可能放緩。超長上下文、即時音影片多模態推論會引入新的成本壓力;端側推論(手機、PC 本地執行)將“零邊際成本”作為終極形態,但這需要模型蒸餾與硬體協同大幅進步。
技術路線對比(量化表)
| 技術路線 | 降本定性幅度 | 延遲影響 | 實現複雜度 | 適用場景 |
|---|---|---|---|---|
| 權重量化(FP8/INT8) | 中等至顯著 | 幾乎無額外延遲,常伴加速 | 低,成熟的生態支援 | 幾乎所有生產推論,但有精度敏感場景需驗證 |
| 投機解碼 | 中等(取決於小模型匹配度) | 降低延遲(草案並行驗證) | 中等,需訓練或選擇合適草稿模型 | 高吞吐即時對話,對 batch 敏感 |
| 連續批處理 | 大幅(提高硬體利用率) | 在 SLO 允許範圍內小幅增加延遲 | 低(vLLM/SGLang 等架構原生支援) | 所有面向多使用者的線上服務 |
| KV 快取壓縮 | 中等(長上下文場景幫助更大) | 可能引入少量計算開銷 | 中高,演算法仍在迭代 | 長文件問答、記憶型助手 |
| MoE 架構 | 顯著(活躍引數少,訪存量低) | 可能引入跨裝置通訊延遲 | 模型訓練成本高,工程複雜 | 超大型模型部署,兼顧高效果與低推論成本 |
| 模型蒸餾/剪枝 | 中度至顯著(小模型直接降低成本) | 通常降低延遲 | 中等,需要精心設計蒸餾過程 | 目標場景明確,端側或邊緣推論 |
| 硬體架構創新 | 顯著(更高頻寬、更優吞吐) | 通常降低延遲 | 高,需適配新硬體指令集 | 追求極致成本優勢的大規模推論叢集 |
注:上表“降本定性幅度”為無檢索資料下的趨勢判斷,實際數值受模型規模、硬體代際、軟體實現影響,浮動空間大。
上下游
- 上游:
- 半導體與硬體:GPU(NVIDIA H200/B200、AMD MI300X 等,注意具體型號未驗證)、ASIC(Google TPU v5p、AWS Inferentia)、儲存器(HBM3/3e/4 堆疊),直接決定單卡推論的頻寬上限與單位成本。
- 資料中心基礎設施:高密度供電與液冷方案,影響電力成本 (PUE)。
- 推論軟體棧:編譯器(TensorRT-LLM, XLA)、執行時(vLLM, SGLang, LMDeploy)、模型量化工具、排程編排系統,決定硬體實際利用率。
- 下游:
- 模型即服務(MaaS):API 提供商(OpenAI, Anthropic, Google Cloud, Azure, AWS Bedrock)將 Cost per Query 轉化為公開定價,並承受成本端壓力。
- 應用層:AI 搜尋引擎、程式碼 Copilot、AI 客服、遊戲 NPC 等,將單次查詢成本嵌入自身商業模式,成本越低,免費增值/廣告模式空間越大。
- 私有化部署:金融、醫療等對資料自主性要求高的客戶,自建推論叢集,直接面對 TCO 核算。
關鍵指標
- 每百萬 token 價格:最直觀的對外報價指標,區分輸入/輸出。輸出價格 3~10 倍於輸入價格(經驗範圍)。價格持續下探是行業基調。
- 總擁有成本(TCO)折現到每次查詢:包含 GPU/ASIC 折舊(通常按 4~5 年)、電力、冷卻、機架空間、網路裝置攤分、運維人員等。精細運營團隊會做到每天按例項級別核算。
- 等效利用率(考慮 SLO):Max batch size under SLO 下的硬體算力利用率,不同於純 MFU。該數值通常在 20%~50% 區間(模型差異大),越高則單 query 分攤成本越低。
- 首 token 延遲(TTFT)與每 token 生成時間(TPOT):SLO 的硬約束,直接限制批大小上限,從而鎖定理論最低成本。
- 模型服務密度:單卡能承載的最大同時請求數(或最大批大小),由視訊記憶體容量和頻寬共同決定。
- Query 複雜度分裂:短查詢與長生成、低難度與高難度(思維鏈)的混合,會導致資源潮汐,增加排程成本。
供需與市場資料
(本節因搜尋失敗,無法提供具體定量資料,僅採用行業趨勢定性描述,所有數字均為模糊感知。)
模型推論的算力需求正在超過訓練,成為 AI 晶片市場的最大驅動力。多家第三方機構預測,未來幾年推論晶片出貨量將佔 AI 加速器市場的大頭。供給端,GPU 產能持續擴張,同時自研 ASIC 陣營壯大,推論硬體的稀缺性較前兩年緩解。因此,推論硬體的雲端租用價格呈下降趨勢,但新技術(如 HBM3e、更大規模叢集)的上線也帶來短期溢價。
需求端,企業將 AI 融入核心業務的比例攀升,日均查詢量級從百萬向十億量級演進,長上下文和多模態帶來的每次查詢資源消耗也在增長。兩相疊加,雖然單 query 成本快速下降,但總體推論花費可能因為查詢量激增而持續擴大。這種“成本通縮 + 總量爆發”的格局類似雲端運算早期:客戶 IT 負載的單價降低,但總支出不降反升。
競爭層面,開源模型和低成本 API 的湧現,讓單純比拼價格成為紅海,迫使企業將單查詢成本優勢轉化為“成本-效果”綜合體驗壁壘。
代表公司與資本對映
- API 定價權玩家:OpenAI、Anthropic、Google(Gemini)、Meta(Llama 開源但雲端服務商付費)通過持續最佳化推論棧壓縮成本,擁有較強議價能力。市場密切關注其毛利率變化;在缺少分產品揭露前,本頁不寫具體推論毛利率區間。
- 推論系統公司:以 vLLM(獨立社群專案,UC Berkeley 團隊背景)、SGLang 等為代表的開源推論架構,正在成為事實標準;Fireworks AI、Together AI、Anyscale 等提供託管的低遲、低成本推論服務,搶佔企業市場。
- 硬體領軍:NVIDIA(Hopper/Blackwell)憑藉寬 HBM 與 CUDA 生態,仍是大規模推論部署的預設選項;AMD、Intel 通過開源軟體生態(如 ROCm)努力追趕;自研 ASIC 巨頭(Google TPU、Amazon Trainium/Inferentia)依靠內部超大規模應用降低成本;初創如 Groq、SambaNova、Cerebras 則試圖以改變計算架構的方式打破訪存牆,重塑成本公式。
- 投資對映:資本關注推論降本賽道,包括:新一代推論加速硬體、極低功耗端側推論晶片、KV 快取壓縮與投機解碼演算法公司、面向特定領域(如程式碼、法律)的輕量化“小引數大能力”模型公司,以及能夠將成本下降轉化為訂閱增長的強應用公司。
投資邏輯
- 成本成為護城河:當模型能力趨於同質化,推論成本更低的廠商更容易用價格和延遲優勢爭取客戶,但能否保持毛利取決於折扣、硬體折舊和模型呼叫結構。分析時需拆解其推論架構是否具備長期降本路徑。
- 架構性機會:MoE、模型蒸餾、新型注意力的突破可能讓後來者以數量級降本,顛覆現有格局。重點關注那些在模型架構與系統層面雙最佳化的團隊。
- 硬體替代週期:ASIC 與新型儲存(如 HBM 升級、記憶體優先架構)一旦大規模部署,可能再次改變推論成本曲線。相關產業鏈的封裝、互連、散熱環節需要用訂單、毛利率和產能利用率驗證彈性。
- 端側推論變數:端側推論本地執行可能降低部分雲端端推論成本,但仍受裝置算力、模型質量、隱私策略和更新頻率約束。端側 NPU 和極小模型(<3B)的進展需要結合實際體驗和出貨節奏觀察。
- 風險點:推論降本速度若快於預期,可能過快壓縮頭部公司的定價能力和獲利;硬體投資過熱導致產能過剩;以及技術路徑突然躍遷(例如某種新架構完全顛覆 GPU 成本結構)。
常見誤讀糾偏
- 誤讀 1:“模型引數越大,單次查詢成本一定越高。” 糾正:成本取決於每次推論的活躍計算量和訪存量,而非總引數數量。MoE 模型總引數可能上千億,但單次推論僅啟用幾十億引數,推論成本遠低於同等效果稠密模型。此外,量化技術和投機解碼可大幅降低大型模型的等效成本,使得許多“小模型”在成本上並不佔絕對優勢。
- 誤讀 2:“推論成本大頭是計算,所以需要更高 FLOPS 的晶片。” 糾正:在 decoding 階段,絕大部分時間消耗在從視訊記憶體搬運模型權重和 KV 快取,而非計算。因此,推論成本對視訊記憶體頻寬的敏感度遠高於純算力。一味堆砌 FLOPS 而不提升頻寬,對降低 Cost per Query 收效甚微。這也是為什麼 HBM 頻寬成為推論晶片的核心競爭力,以及量化壓縮能直接轉化為成本節省的根本原因。
- (額外)誤讀 3:“降低推論成本就是純粹的工程問題,與模型研究無關。” 部分真:系統最佳化是重要分支,但模型架構創新(如 GQA、MLA 注意力等)可以從數學上成倍降低 KV 快取體積,從而減少訪存,這種“演算法-硬體協同設計”帶來的降本遠比單純工程最佳化更為深刻。
學習路徑
- 入門:閱讀 OpenAI 和 Anthropic 的 API 定價文件,理解不同模型、不同上下文視窗的價格分層。
- 系統核心:精讀 vLLM 論文 [Efficient Memory Management for Large Language Model Serving with PagedAttention] 與 SGLang 文章,理解連續批處理和零複製視訊記憶體管理如何降低成本。
- 原理深入:學習輝達《Rethinking LLM Inference》系列博文、TensorRT-LLM 文件,掌握計算與訪存的分析模型,學會估算給定硬體下的理論最優 cost per token。
- 開源實踐:部署一個開源模型(如 Llama 3 或 Qwen 系列),使用 vLLM 實測不同批大小、量化方案下的吞吐與成本,獲取一手的“卡時與 query 數”轉化率。
- 追蹤前沿:關注 ICML、NeurIPS、MLSys 等會議上關於 Long-Context 壓縮、投機解碼、KV 快取淘汰演算法的論文,以及半導體行業對下一代記憶體(HBM4、CXL)的路線圖更新。
一句話總結
Cost per Query 是大型模型從技術勢能向商業動能轉化的貨幣化樞紐,它的每一次下探,都寫滿了從電晶體到使用者介面之間的全棧創新與經濟理性。
延伸閱讀與來源
- 權威報告類(因搜尋失敗,無法確認最新連結,建議關注):NVIDIA 季度財報電話會議中關於資料中心推論佔比的評論;IDC、Omdia 對 AI 推論晶片的市場預測;ARK Invest 《Big Ideas》中針對推論成本下降曲線的預估。
- 技術論文:PagedAttention (vLLM)、FlashAttention、SGLang、SpecInfer (投機解碼)、AWQ: Activation-aware Weight Quantization。
- 生態專案:vLLM GitHub 倉庫、SGLang 文件、Hugging Face TGI、NVIDIA TensorRT-LLM。
- 行業觀察:Semianalysis 對推論成本拆解的深度分析;Lifearchitect.ai 的推論硬體評測;各雲端廠商官方部落格(如 Google Cloud、AWS)中關於推論最佳化最佳實踐的文章。
- 注意:具體 API 價格、硬體效能測試資料、雲端例項計費標準隨時變化,請以各廠商官方數字為最終依據。