Cost per Query

3 秒看懂

Cost per Query（单次查询成本）是大语言模型（LLM）从实验室走向规模化商用的生死线。它衡量的是为一个用户请求生成完整回复（全链路算力、电力、网络、运维摊分）所消耗的全口径经济成本。它直接决定了 API 的定价底线、自建方案的盈亏模型，以及模型架构设计能否穿越“成本-体验”的剪刀差。

3 分钟产业解释

在 ChatGPT 引爆市场之前，行业衡量模型成本的核心指标是“训练一次要烧多少钱”。但当模型变成服务，每天要响应数十亿次用户请求时，推理成本就上升为压倒性的财务主题。Cost per Query 把一切工程努力——模型架构（稠密 vs 混合专家）、系统软件（量化、内核融合、KV 缓存管理）、硬件效率（显存带宽、算力利用率）、部署策略（批处理、弹性伸缩）——收敛为一张商业账单：每回答一个问题的花费。云厂商和模型公司围绕这一指标展开“价格战”：同等效果下，谁能提供更低的单次查询成本，谁就能掌握开发者生态和终端定价权。近 18 个月，主流模型级别推理的单位成本下降幅度超过 90%（行业粗略感知，因未检索到确切报告，此处为基于公开定价趋势的估算）。其背后是一轮从“暴力出奇迹”到“精算到每一个浮点操作”的技术体系重构。

15 分钟专家深入

Cost per Query 的构成远比直观的“GPU 使用时长 × 租赁单价”复杂。它必须覆盖五层：

1. 硬件成本层：GPU/ASIC 的折旧或云端实例计费，通常以每卡·小时为单位。
2. 能源与散热：数据中心电力费用，随芯片功耗和冷却方案变化，大致与硬件成本呈一定比例（高密度部署下电力成本占比上升）。
3. 分布式通信开销：对于超出单卡显存的大模型，多卡之间的张量并行、流水线并行会引入大量通信，延长单次查询的端到端延迟，从而增加“卡时”占用。
4. 服务框架与调度损耗：请求排队、前缀缓存（prefix caching）、KV 缓存管理失效等。
5. 可用性冗余：为保证服务等级协议（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 本地运行）将“零边际成本”作为终极形态，但这需要模型蒸馏与硬件协同大幅进步。

技术路线对比（量化表）

注：上表“降本定性幅度”为无检索数据下的趋势判断，实际数值受模型规模、硬件代际、软件实现影响，浮动空间大。

上下游

• 上游：
  • 半导体与硬件：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 缓存压缩与投机解码算法公司、面向特定领域（如代码、法律）的轻量化“小参数大能力”模型公司，以及能够将成本下降转化为订阅增长的强应用公司。

投资逻辑

1. 成本成为护城河：当模型能力趋于同质化，推理成本更低的厂商更容易用价格和延迟优势争取客户，但能否保持毛利取决于折扣、硬件折旧和模型调用结构。分析时需拆解其推理架构是否具备长期降本路径。
2. 架构性机会：MoE、模型蒸馏、新型注意力的突破可能让后来者以数量级降本，颠覆现有格局。重点关注那些在模型架构与系统层面双优化的团队。
3. 硬件替代周期：ASIC 与新型存储（如 HBM 升级、内存优先架构）一旦大规模部署，可能再次改变推理成本曲线。相关产业链的封装、互连、散热环节需要用订单、毛利率和产能利用率验证弹性。
4. 端侧推理变量：端侧推理本地运行可能降低部分云端推理成本，但仍受设备算力、模型质量、隐私策略和更新频率约束。端侧 NPU 和极小模型（<3B）的进展需要结合实际体验和出货节奏观察。
5. 风险点：推理降本速度若快于预期，可能过快压缩头部公司的定价能力和利润；硬件投资过热导致产能过剩；以及技术路径突然跃迁（例如某种新架构完全颠覆 GPU 成本结构）。

常见误读纠偏

• 误读 1：“模型参数越大，单次查询成本一定越高。” 纠正：成本取决于每次推理的活跃计算量和访存量，而非总参数数量。MoE 模型总参数可能上千亿，但单次推理仅激活几十亿参数，推理成本远低于同等效果稠密模型。此外，量化技术和投机解码可大幅降低大模型的等效成本，使得许多“小模型”在成本上并不占绝对优势。
• 误读 2：“推理成本大头是计算，所以需要更高 FLOPS 的芯片。” 纠正：在 decoding 阶段，绝大部分时间消耗在从显存搬运模型权重和 KV 缓存，而非计算。因此，推理成本对显存带宽的敏感度远高于纯算力。一味堆砌 FLOPS 而不提升带宽，对降低 Cost per Query 收效甚微。这也是为什么 HBM 带宽成为推理芯片的核心竞争力，以及量化压缩能直接转化为成本节省的根本原因。
• （额外）误读 3：“降低推理成本就是纯粹的工程问题，与模型研究无关。” 部分真：系统优化是重要分支，但模型架构创新（如 GQA、MLA 注意力等）可以从数学上成倍降低 KV 缓存体积，从而减少访存，这种“算法-硬件协同设计”带来的降本远比单纯工程优化更为深刻。

学习路径

1. 入门：阅读 OpenAI 和 Anthropic 的 API 定价文档，理解不同模型、不同上下文窗口的价格分层。
2. 系统核心：精读 vLLM 论文 [Efficient Memory Management for Large Language Model Serving with PagedAttention] 与 SGLang 文章，理解连续批处理和零拷贝显存管理如何降低成本。
3. 原理深入：学习英伟达《Rethinking LLM Inference》系列博文、TensorRT-LLM 文档，掌握计算与访存的分析模型，学会估算给定硬件下的理论最优 cost per token。
4. 开源实践：部署一个开源模型（如 Llama 3 或 Qwen 系列），使用 vLLM 实测不同批大小、量化方案下的吞吐与成本，获取一手的“卡时与 query 数”转化率。
5. 跟踪前沿：关注 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 价格、硬件性能测试数据、云实例计费标准随时变化，请以各厂商官方数字为最终依据。