本文深度解析大语言模型推理服务的技术瓶颈、架构演化和商业定价逻辑，揭示KV缓存管理、连续批处理、上下文缓存如何共同塑造每Token成本，并对比开源引擎与云厂商的服务模式差异。
大模型推理不是魔法，而是资源调度的极限挑战
当你用一句“写一首关于春天的诗”调用大模型API时，背后其实是一场高度精密的资源战争。大模型推理服务的核心问题，并不是“能不能生成”，而是“在多快时间内、以多低成本、稳定地生成多少Token”。
这本质上是一个吞吐量与延迟的多目标优化问题，但它的自由度被两个硬性约束牢牢锁死：
第一，自回归解码天然就是串行的，每个新Token都依赖前面所有Token；
第二，注意力机制中的Key/Value缓存（KV Cache）会疯狂吞噬GPU或TPU的显存，尤其在长上下文场景下，一个130亿参数的模型，单个请求的KV缓存就能占掉好几GB。
正因为如此，所有高杠杆的推理优化创新，几乎都围绕着三大方向打转：怎么更聪明地管理和复用KV缓存；怎么在请求形状千奇百怪的情况下实现更智能的批处理和调度；以及如何通过硬件定制的算子和精度优化，把宝贵的加速器内存带宽和互联能力，转化为实实在在的每秒输出Token数，同时还能守住尾部延迟的底线。
云厂商兜售的“按Token计费”，卖的其实是调度能力
表面上看，OpenAI、Anthropic这些前沿实验室，或者AWS、Azure、Google Cloud这些超大规模云厂商，卖的是一个简单的“输入Token+输出Token”计费模型。但实际上，他们真正在兜售的，是一整套极其复杂的多租户调度与容量管理系统。
这套系统把共享的加速器资源池，包装成一个看似平滑的“Token进出”抽象接口。
而为了匹配不同客户的工作负载特征，商业设计越来越趋同于三种容量模式：
第一种是“按需共享池”，最简单但波动最大，适合流量不可预测的初创公司；
第二种是“预留吞吐量”，比如Azure的PTU（Provisioned Throughput Units）或Google的GSU（Generative AI Scale Units），客户付费锁定固定算力，换来确定性的延迟和容量保障；
第三种是“批处理/异步模式”，价格直接打五折，但要求你接受24小时内完成，代表产品包括OpenAI的Batch API、AWS Bedrock的批处理模式和Azure OpenAI的批量接口。
这三种模式，本质上就是把内部复杂的利用率工程问题，直接映射给客户选择，让客户用自己的成本预算和延迟容忍度，来为云厂商的调度系统“投票”。
上下文缓存：从技术红利到商业定价杠杆
在所有推理优化技术中，提示词（Prompt）或上下文（Context）缓存已经从一个高级技巧，演变成了基础性的服务原语。
它的核心价值在于三重节省：大幅削减重复的Prefill（预填充）阶段计算开销，显著降低首Token延迟（Time-to-First-Token），以及平滑掉流量峰值带来的瞬时压力。
OpenAI在其官方文档中罕见地披露了具体实现细节：系统会对提示词的前缀（通常是前256个Token）进行哈希，并将请求路由到持有该缓存的特定主机上。为了防止小提示词滥用缓存空间，系统还设定了最小长度阈值（通常是1024个Token）。
更关键的是，当某个提示词前缀的请求速率过高（比如超过每分钟15次），系统会启动“溢出”机制，将部分请求分流到其他机器，虽然会降低缓存命中率，但能避免单点过载。缓存策略也分层级，内存中保留5-10分钟，而通过将KV张量卸载（Offload）到GPU本地的高速存储（如NVMe），可以将缓存有效期延长至24小时。
Google的Vertex AI更是直接给出了经济激励：对于缓存命中的Token，客户只需支付10%的标准价格，折扣高达90%。AWS Bedrock和Azure OpenAI的文档也描述了几乎相同的机制，包括前缀哈希、短TTL（生存时间）以及对缓存读写Token的精确计量。
这说明，上下文缓存不仅是技术优化，更是云厂商用来引导用户行为、提升自身资源利用率的精妙商业杠杆。
从PyTorch到SGLang：推理引擎光谱揭示市场分层
面对大模型推理的复杂性，开发者可选的技术栈呈现出一条清晰的“推理引擎光谱”，从最灵活但低效的原始框架，到高度优化但耦合度高的专用引擎。
位于光谱最左侧的是原始的PyTorch或Hugging Face Transformers库。这种方式把推理直接嵌入应用代码，模型内部、自定义算子、实验性解码策略都能完全掌控，但代价是所有调度、KV缓存管理、内存碎片处理都得自己从头造轮子。
在真实生产环境中，这种方式的吞吐量被普遍认为是“非常低”的，因为它无法有效处理多请求并发下的内存压力。
再往右是Ollama，它主打的是本地开发体验，提供一个轻量级的运行时和简单API，方便开发者在本机快速拉取、运行和管理模型，尤其强调与OpenAI API的兼容性，但它并非为高并发、多租户的生产环境设计。
接着是Hugging Face的TGI（Text Generation Inference），这是一个成熟的“推理服务器”，内置了路由、队列、监控指标和高性能生成引擎，明确支持连续批处理和多GPU策略，是很多团队上线开源模型的首选。
而vLLM则代表了“推理引擎”的新范式，它通过独创的PagedAttention技术，把KV缓存管理类比为操作系统的虚拟内存分页问题，有效解决了传统系统中高达60%-80%的显存浪费问题，在真实多请求负载下，吞吐量能比Hugging Face Transformers高出24倍，比TGI高出3.5倍。
更进一步，NVIDIA的TensorRT-LLM则是“厂商深度优化”的代表，它通过算子融合、量化、飞行中批处理（In-flight Batching）等技术，将NVIDIA GPU的性能压榨到极致，通常与Triton推理服务器和Kubernetes一起部署。
光谱最右侧是SGLang，它提出了一种“运行时+编程模型”协同设计的新思路，将复杂的LLM应用视为多步骤程序，并引入RadixAttention技术，在多个生成调用间自动高效地复用KV缓存，在特定工作负载下，吞吐量能比现有系统提升5倍。
这条光谱清晰地展示了市场分层：你想要的是灵活性、开发速度，还是极致的吞吐与成本效率？
推理的两大阶段：Prefill与Decode的博弈
要真正理解推理成本，必须拆解自回归推理的两个截然不同的阶段。
第一阶段是Prefill（预填充），即模型一次性处理用户输入的整个提示词序列，生成初始隐藏状态，并为所有提示词Token填充KV缓存。这个阶段计算密集、高度并行，能很好地利用GPU的计算单元，其效率受序列长度和批处理大小的显著影响。通过将多个请求打包批处理、使用融合算子（如FlashAttention），Prefill效率可以大幅提升。
第二阶段是Decode（解码），即逐个生成输出Token。每个新Token的生成都依赖于之前所有的Token，KV缓存正是在这里发挥作用，避免了重复计算。但Decode阶段是天然串行的，且随着生成的Token越来越多，它对内存带宽的依赖会越来越强。
最关键的是，每次Decode操作都需要从完整的KV缓存中读取信息，因此有效边际成本会随着上下文长度的增加而上升。
在许多生产场景中，KV缓存本身就成了最稀缺的资源，其大小与批处理规模、序列长度、模型层数和注意力头维度成正比，必须保持在低延迟可访问的状态。这也正是为什么“推理引擎”作为一个独立品类存在的根本原因——管理这个动态、碎片化、高占用的KV缓存，其复杂度远非一个普通的模型库所能胜任。
前沿实验室的底牌：OpenAI的Azure耦合与Anthropic的TPU豪赌
两大前沿实验室的基础设施策略，揭示了不同的技术信仰和商业考量。
OpenAI的公开招聘信息和文档证据都强烈指向一个事实：他们运行着一套高度定制的推理栈，并与微软Azure的GPU基础设施深度耦合。其工程师职位明确要求优化Azure虚拟机集群，以“榨干每一个FLOP和每一GB显存”，技术栈涉及NVIDIA GPU、NCCL、CUDA、InfiniBand、MPI和NVLink。
这说明OpenAI的生产推理发生在分布式GPU集群上，节点间的互联效率和通信模式，是决定每Token成本和p99延迟的首要因素。
此外，OpenAI对缓存细节的披露（如前缀哈希、15请求/分钟的溢出阈值、分层缓存保留策略）都表明，其内部调度系统是围绕缓存局部性进行极致优化的，甚至通过API设计引导用户写出更“缓存友好”的提示词。
相比之下，Anthropic则押注了一条更激进的多平台路线。他们宣布将在Google Cloud上部署多达100万块TPU，总价值高达数百亿美元，并计划在2026年带来超过1吉瓦的电力容量。
Anthropic明确表示，选择TPU是看中了其在价格性能比、能效以及自身在TPU上训练和推理的经验。
更重要的是，他们采取了“多元化”策略，同时使用Google的TPU、亚马逊的Trainium和英伟达的GPU。这种策略虽然增加了软件栈的复杂性，但极大地增强了其在面对加速器短缺、价格波动和地缘政治风险时的议价能力和韧性。这也暗示Anthropic内部必然有一套能抽象或适配多种异构硬件后端的推理/训练软件栈。
云巨头的生意经：如何把加速器包装成Token卖给企业
AWS、Google Cloud和Azure这三大云巨头，在销售大模型推理服务时，本质上在同时兜售三样东西：
第一，是对稀缺加速器资源的抽象访问，让客户无需关心底层硬件采购和运维；
第二，是围绕AI服务的企业级治理能力，包括身份认证、网络隔离、日志审计、内容安全和合规性；
第三，是与整个云原生生态的无缝集成，让AI服务能像S3、RDS一样，成为企业IT架构中的标准组件。
AWS的Bedrock提供了清晰的分层定价：标准按需、优先级（Premium）提供SLA保障、Flex模式用于成本敏感型负载，以及50%折扣的批处理模式。它还通过推理画像（Inference Profile）产品化了多区域路由能力，让客户能在数据驻留合规性和全球性能之间做出权衡。
Google的Vertex AI则强调其“预留吞吐量”（Provisioned Throughput）产品，客户通过购买GSU单位来锁定确定性的算力，系统甚至会在请求入口处就预估输出Token数量，以决定是走预留通道还是按需通道。
Azure的策略则更为直接，通过Azure OpenAI Service提供OpenAI模型的Azure托管版本，并通过Foundry Models计划扩展到更广泛的第三方模型目录。其三大模式——标准、预留（PTU）和批处理——与行业趋势完全一致。值得注意的是，Azure明确指出缓存不会在不同订阅之间共享，这凸显了其对多租户隔离和企业合规性的重视。
总而言之，云厂商的竞争，已经从单纯的模型能力，扩展到了整个AI服务交付栈的完整性和成熟度。
客户如何选择：模型质量、成本、合规性与工程负担的多维博弈
企业在选择大模型服务时，很少只看一个指标，而是在多个约束条件下寻找最优解。模型质量与功能表面是首要考量，前沿实验室通常在模型能力、工具调用语义、安全行为等方面有独特优势。
但在成本方面，对于交互式应用，每输出Token的成本是关键，而这直接取决于服务栈在高并发下维持高吞吐和低尾部延迟的能力。
需求形态也至关重要：
流量尖峰不定的业务适合按需池；稳定高并发的生产服务则青睐预留吞吐；
离线或对延迟不敏感的任务则可利用批处理的50%折扣。
数据驻留、隔离和合规性要求，正推动云厂商提供更细粒度的部署选项，如Azure的全球、数据区（EU/US）和区域部署。工程与运维负担是另一个核心维度，自托管开源模型意味着要承担从模型升级、量化到集群扩缩容的全生命周期责任，而“按Token付费”的API则将这些负担转移给了云厂商，但也带来了供应商锁定的风险。
最后，API兼容性正成为降低切换成本的关键，OpenAI兼容的API已成为事实上的行业标准，vLLM、SGLang、Ollama等项目都积极拥抱这一标准，使得客户可以在不同后端之间进行“供应商套利”。
价值链的演变：引擎层在商品化，但效率仍是护城河
从整个AI基础设施价值链来看，几个关键动态正在上演。开源推理引擎层正面临巨大的商品化压力。
vLLM、TGI、SGLang等项目快速实现了连续批处理、前缀缓存、推测解码等高级特性，这使得任何试图单纯通过托管开源模型来盈利的服务都面临利润挤压。
然而，引擎层的价值并未消失，因为哪怕是在Token/秒/GPU上做出微小的效率提升，乘以海量的请求规模后，都能带来巨大的成本优势；同时，稳定可靠的尾部延迟表现，需要深厚的系统工程功底，难以被简单复制。
按Token定价本身，与其说是一种计费方式，不如说是一种精妙的容量管理工具。
对缓存Token、批处理作业的折扣，本质上是在引导客户行为，使之与提供商的资源利用率周期相匹配。
预留吞吐量产品的出现，则是对多租户环境中性能波动问题的直接回应，它让提供商能以可预测的利润率销售保障性容量，也让客户能规避限流风险。
最后，硬件策略本身也成了竞争变量。Anthropic对多平台（TPU、Trainium、GPU）的押注，展现了其试图通过硬件套利来降低成本、增强韧性的野心，而OpenAI与Azure/NVIDIA生态的深度绑定，则反映了另一种追求极致单点优化的路径。
最终，谁能在这场涉及模型、硬件、软件和商业模型的多维竞争中胜出，将取决于谁能最好地将高度可变、有状态、内存密集型的推理过程，转化为可预测、可定价、高效率的容量切片。