推理拐点：从训练军备竞赛走向效率对决
在当下的生成式人工智能行业中，各大科技巨头和初创企业突然掀起了一场前所未有的“造芯大战”。OpenAI率先亮出了其体积极大、甚至“比脸还大”的首枚定制推理芯片；谷歌（Google）计划将Gemini架构直接以硬编码或深度优化形式写入硅片；与此同时，Anthropic、智谱AI、DeepSeek等海内外前沿人工智能实验室，也相继传出了正在进行相关硬件芯片布局或软硬协同设计的消息。
这些顶尖的AI企业不约而同地将目光投向了推理加速（Inference Acceleration: 提升大模型前向传播计算与生成速度的技术），其背后的商业与技术逻辑非常直接：当AI模型之间的竞争全面进入应用部署与商业化落地阶段，如何让模型更快、更便宜地跑起来，已经变成了决定生死存亡的最重要事项。这意味着，“推理的拐点已经到来”。
然而，重造一颗芯片的门槛极高，并不是每家公司都有动辄数十亿美元的资金和数年的时间去从头研发并制造一块属于自己的物理芯片体系。在这样的背景下，一个曾经隐秘但如今异常火热的万亿级市场正在引发全球资本和科技巨头的疯狂关注——这就是AI Infra（AI Infrastructure: 人工智能基础设施层，涵盖用于支持大模型训练与推理的硬件、编译器、算子、调度及软件框架的集合）。
AI Infra的核心商业逻辑是，在既有的、已经部署好的数据中心和昂贵的GPU物理集群之上，通过极度精细的软件工程与算法调度，释放出这些硬件本身被闲置或浪费的巨大优化空间。这个赛道正爆发出令人瞠目的商业价值。
作为AI推理平台代表的Baseten在短短一年时间内收入增长了20倍，估值从21亿美元暴涨到了130亿美元；同赛道的Fireworks在七个月内估值翻了四倍，达到了175亿美元，其年化营收迅速突破了10亿美元。最近，这个赛道还迎来了一股极其强劲的开源势力——开源推理引擎的“双子星”vLLM（基于PagedAttention技术的高吞吐大模型推理引擎）与SGLang（由加州大学伯克利分校等机构发起的高性能结构化大模型推理引擎），其背后团队的前后脚商业化创业在种子轮融资中都轻松超过了一亿美元。这笔资金的背后，几乎聚齐了全球AI产业中所有的顶级芯片巨头、云厂商以及最老牌风投的名字，拉开了AI底层效率强强对决的大幕。
由此，“GPU的利用率”正式成为了硅谷最核心的最新关键词，也带出了一个崭新的千亿级市场。在此背景下，由SGLang开源引擎孵化出来的RadixArk团队联合创始人与核心成员、以及多位数据中心专家，共同探讨了AI Infra的四层架构，揭示了行业如何将“硅”的潜力榨到物理极限的路径，并展示了正在发生的效率革命。
在理解如何提升效率之前，我们必须认识到大模型的重心从训练走向推理之后，对底层的算力提出了与以往完全不同的系统性要求。训练（Training: 利用海量数据更新模型参数的过程）虽然成本极高，但它是一个一次性或阶段性的任务，任务结束后GPU集群就可以暂时告一段落。
然而，推理（Inference: 模型接收输入并生成输出的过程）则完全不同。无论是目前火热的Chatbot（聊天机器人）还是自动执行复杂任务的Agent（智能体），只要AI应用在持续运行，GPU就必须无休止地处理来自全球各地用户的并发请求。这些请求是完全随机、不间断且对延迟高度敏感的。随着全球开发者与企业不断地拓展人工智能模型的能力边界，推理算力的需求呈现出爆发性增长，甚至大到了市面上的算力卡“一片难求”的地步。每一家人工智能企业、不论大小，当前面临的最大瓶颈就是“缺卡”。
对于有钱的科技巨头而言，解决这一瓶颈最直接的方法似乎是简单粗暴的“钞能力”：继续投资建设更庞大的数据中心，并采购更多的GPU。包括Meta、Google、微软（Microsoft）在内的科技巨头持续提高资本开支，今年预计总额将超过1万亿美元，而英伟达CEO黄仁勋更是预测，到2030年，全球AI基础设施的年投资规模将达到惊人的4万亿美元。
然而，华尔街的金融分析师们对此却充满了深切的担忧。这种担忧并非没有前车之鉴。回看二十多年前互联网时代的泡沫破灭，当时大量资金被疯狂投入到光纤网络建设和早期的互联网创业公司中，虽然从长期来看，这些基础设施确实实现了它们的社会价值，但在短期内却因为需求未达预期而出现了灾难性的资金断裂与市场崩盘。因此，如果不能在短时间内通过物理手段大规模增加算力，唯一的自救与突破方法，就是提高GPU的利用率。
系统建模：AI Infra的四层架构与GPU空转之谜
为了真正理解GPU利用率的优化空间，我们首先需要打破一个普遍的认知误区：你以为GPU在数据中心里一直在拼命工作吗？事实上，大多数时间GPU都处于极度“闲置”的状态。
GPU本身并不是一个孤立的计算器件，它只是庞大的AI分布式系统中的普通一环。当一条用户请求从前端输入系统开始，它需要经过漫长的网络传输、系统的资源调度、大模型的动态加载、显存（GPU Memory: 显卡内存）管理，再到最终在计算核心中完成前向传播计算、并将结果返回给用户。在这条极其冗长的处理链路当中，任何一个环节出现一丁点的延迟或瓶颈，GPU就必须立刻停下来进行等待。
卡内基梅隆大学（CMU）最近对数据中心里的756块GPU进行了长达31天的细粒度遥测研究。这项研究覆盖了从老一代的A100、H100到最新架构B200在内的六代英伟达产品。遥测结果得出了一个令人震惊的结论：很多时候，GPU都在经历一种被称为“执行时空转”（execution-idle: GPU计算单元虽然处于运行状态，但在白白消耗能耗等待数据输入，并未进行有效算力输出）的状态。
这种“看似繁忙、实则空转”的现象严重到了什么程度？在他们观测的工业级GPU集群中，整体上有近20%的执行时间以及大约11%的物理能耗被白白浪费在了无意义的等待上。如果具体到对延迟极其敏感的推理场景，情况则更加糟糕——在Azure Code生成这类对即时性要求极高的代码补全负载中，有高达65%的能耗消耗在了GPU的空转上；而OpenAI的Chat类对话请求中，也有52%的能耗被浪费在等待中。
那么，究竟为什么如此昂贵的GPU会被跑不满呢？我们可以通过AI Infra的四层架构模型来进行系统性的解构，这四层中的每一层都紧密决定着GPU的最终利用率：
- 第一层：能源基础设施（Power Infrastructure）。这一层对应的是最底层的电力供给、变压器和数据中心散热系统。它决定了GPU能不能获得持续、稳定、足额的电流支持。
- 第二层：计算硬件（Compute Hardware）。这一层包括了GPU芯片本身、高带宽存储（High Bandwidth Memory: 简称 HBM，提供极高传输速率的显存技术）、NVLink高速互联总线以及CPU等。它决定了整个系统在理论上能够提供的计算上限。
- 第三层：系统软件（System Software）。这一层包括了NVIDIA的CUDA平台、编译器、通信库（如NCCL）、显存管理工具以及底层的高性能算子库（如FlashAttention）。它决定了每一次具体的计算任务能不能被执行到硬件的最底层物理极限。
- 第四层：服务编排（Service Orchestration）。这一层负责在宏观上协调GPU集群的算力资源，决定哪些任务优先运行、如何切分显存，以及处理不同业务请求之间的动态调度。推理引擎、训练框架、请求路由等都处于这一层。这也是近年来技术创新与商业竞争最密集、最火热的板块。
当这四层架构中的任何一层出现瓶颈，都会导致GPU的利用率大幅下滑。例如，如果电力或散热跟不上，GPU为了防止芯片烧毁会主动采取“降频”运行；如果硬件互联（NVLink）带宽不足，GPU就需要花大量的时间在等待数据传输上；如果系统软件优化不够，每一次计算就无法触及芯片的理论浮点运算极限；而如果服务编排层的请求调度不当，则会导致本来可以合并的计算任务被拆得稀碎，或者导致已经算出来的结果被反复重算。
虽然这四层都会影响效率，但它们的优化性质却完全不同。下面两层（电力、散热和芯片硬件）属于“硬”问题，其改造周期以年为单位，物理极限也正在逼近硅的材料上限；而上面两层（系统软件与服务编排）则属于典型的“软”问题，本质上是工程设计与算法调度的艺术。通过软件和编排层的优化，往往能在不改变任何硬件的前提下，带来数倍的性能飞跃。因此，行业的注意力正在快速地往软件和服务编排层转移。
让我们来算一笔具体的商业账：一台由英伟达GB200 NVL72组成的超算机柜，其采购成本大约在400万美元左右。如果它的软件调度栈没有做好优化，使得GPU的实际利用率只有50%，这就相当于有一半的硬件投资（即200万美元）以多余的电费、折旧和机会成本的形式被白白浪费了。反之，如果通过软件层面的极致调度，将实际利用率从50%提升到90%以上，其效果就相当于开发者在没有任何硬件采购支出的情况下，凭空多出了一台价值400万美元的机柜。
这就是为什么软件层的每一次微小优化，在硬件成本极度高企的今天，都会直接转化为巨大的商业利润。不久前，有网友研究了AI巨头Anthropic的员工构成，发现其中占比最大的岗位既不是基础算法研究员，也不是数据标注员，而是AI Infra工程师。这背后逻辑正是因为极度趋于稳定的Infra和极致的成本控制，直接推动了Anthropic能够在极其高昂的算力压力下快速迈向盈利。
对于没有雄厚资金在公司内部构建庞大Infra团队的中小型模型企业或开发者来说，开源推理引擎双子星——SGLang和vLLM，就成为了他们部署AI服务时的底层支柱。
计算省税：RadixAttention与前缀缓存复用
为了将GPU的性能榨干，当前的推理引擎优化主要围绕着四个核心技术追问展开：哪些计算不用重新做？哪些等待可以被消除？哪些算力没有吃满？以及哪些资源没有实现协同？
首先，我们来解决“哪些计算不用重新做”的效率问题。在大模型的实际运行中，存在一个极其低效的工程事实：当同一段长文本（如系统提示词或上下文背景）被不同的用户或在不同的时间反复发给模型时，模型在每一次前向传播中都必须从头计算一遍。
在AI Agent（智能体）的工作流中，这种浪费被放大了数十倍——同一个Agent可能需要反复调用同一个工具的英文描述，或者在长对话中不断追问，而每一次对话，系统都需要将整段历史记录重新进行一次计算。业界将这种因为无意义的重复计算带来的显存与算力浪费，形象地称为推理税（Inference Tax: 指在大模型多轮对话或多任务交互中，由于没有保存历史状态而导致对相同前缀进行重复计算所产生的额外算力与时间成本）。
为了省下这笔昂贵的“推理税”，Anthropic此前曾推出过一项优化方案，直接将部分高频长文本场景的推理成本砍掉了90%。这背后依赖的最核心思路就是KV cache复用（Key-Value Cache Reuse: 键值缓存复用技术）。
大模型（Transformer架构）在执行生成解码的过程中，每一层的自注意力机制都会将历史的token（词元）映射成键（Key）和值（Value）的张量，合称KV张量。在第一次处理用户输入的预填充（Prefill: 接收Prompt并计算其所有token的KV张量的过程）阶段，系统会把这些K/V张量保存在显存的缓存中。当后续模型进入解码（Decode: 逐字生成新token的过程）阶段时，系统就无需重新计算历史所有token的KV，而是可以直接复用这些缓存，仅计算最新生成的单个token的KV并追加到缓存末尾。
尽管KV Cache极大地降低了解码阶段的计算量，缩短了用户获取首字的时间，即首字延迟（Time to First Token: 简称 TTFT），但它也带来了另一个致命的弱点——极度消耗显存。在长上下文和高并发用户请求的情况下，显存很快就会被海量的KV Cache彻底占满。一旦显存告急，系统就无法再继续提高并发处理量，推理速度也会随之断崖式下跌。
针对这一瓶颈，SGLang引擎提出了一项极具前瞻性的核心专利级技术——RadixAttention（基数树注意力机制）。
RadixAttention的核心设计是使用一种在计算机科学中经典的基数树（Radix Tree: 一种多路搜索树，用于高效存储和检索具有公共前缀的键值数据）结构，来在显存中组织和管理海量的KV Cache。我们可以将它形象地理解为一棵共享前缀的“家族树”：
- 所有拥有相同开头（例如相同的Shared System Prompt）的请求，在显存中都会指向并共同使用同一段“树干”的KV Cache。
- 只有当对话内容开始发生分叉（即不同的User Prompt或后续追问）时，系统才会从主干上延伸出各自独立的“树枝”。
这种设计在智能体（Agentic）应用大爆发的今天展现出了惊人的价值。例如在智能体编程（Agentic Coding）中，开发者会频繁地修改代码并运行测试，而在同一个系统提示词和同一段代码库的上下文之下，由于RadixAttention在底层实现了跨请求、甚至跨机器的KV Cache共享和复用，使得原本需要消耗巨额显存和算力的重复前缀被瞬间免除，极大地释放了硬件的承载能力。
然而，在分布式集群的工程实践中，仅有静态的树状缓存结构是远远不够的，系统还必须拥有一个高度聪明的“调度器”（Scheduler）来与之配合。如果调度器没有“缓存感知”能力，把带有相同前缀的请求随机分配给不同的GPU卡或在不同的时间段运行，那么即使某张卡上存有该缓存，也会因为请求被发到了别的卡上而完全无法命中。
为了解决这个问题，SGLang设计了一整套精密的调度与管理策略：
- 缓存感知调度（Cache-aware scheduling）：这就像餐厅后厨的并单操作。如果后厨连续收到三份麻辣香锅的订单，大厨可以一次性准备相同的底料和配菜，效率会极高；但如果订单顺序是杂乱的“麻辣香锅、寿司、牛排、麻辣香锅、披萨”，大厨就必须频繁地洗锅、换工具，效率会大打折扣。SGLang的调度器会主动分析请求的前缀特征，将前缀相似的请求聚拢并发送到同一张GPU上靠近处理，从而大幅提升缓存的命中率。
- 缓存淘汰机制（Eviction mechanism）：当多并发导致显存占满时，系统需要决定扔掉谁的缓存。SGLang引入了类似于手机内存管理的算法，保留高频使用的系统提示词、RAG（检索增强生成）高频参考文档以及最近被频繁访问的对话前缀，而优先淘汰掉那些很久没有被访问、复用价值较低的冷数据缓存。
- 分布式缓存感知负载均衡器（Distributed cache-aware load balancer）：在拥有多张GPU的集群中，当一个新的请求到来时，负载均衡器会精准地将其路由到那个已经在本地显存中写好“该前缀笔记”的特定GPU上，避免了由于跨卡传输或重复计算带来的开销。
通过这些软硬件层面的协同配合，推理引擎成功地省掉了大模型推理中最沉重的一笔“税收”。
等待消除与算力榨取：连续批处理与投机采样
在解决了计算重算的问题后，优化的下一个靶心指向了“哪些等待可以被消除”。在当下的硬件供应链中，大容量高端显存缺货严重，但很多时候，抢到手的GPU却有接近一半的时间处于“干等”状态。这种等待主要源于两个维度：请求之间的等待和计算阶段之间的等待。
在早期的推理引擎设计中，系统采用的是简单的“排队制”或“固定批处理”（Batching）模式。然而，由于不同用户提出的问题长短不一，模型生成的回答长度也天差地别。在固定批处理中，短文本请求的用户往往必须等待同批次中最长请求运行完毕，才能一同“下车”返回结果，这导致短请求用户的TTFT和整体体验极差。
为了消除这种由于请求长度不一致带来的空转等待，当前行业普遍采用了连续批处理（Continuous Batching: 动态批处理技术，允许新请求在迭代间隙随时加入批次，已完成的请求随时退出）。这就像一辆不需要等所有乘客坐满才出发、且在运行途中随时允许乘客上下车的动态公交车。只要有新请求进来，它在下一个计算步骤中就能直接插入当前的GPU计算流；一旦某个请求生成结束，它就能立刻被释放并返回给用户，从而让GPU始终处于高负载的满载计算状态。这一项技术改造就直接将GPU的实际吞吐量提升了2到4倍。
另一个更深层次的等待发生在大模型推理的两个核心计算阶段之间：预填充（Prefill）阶段和解码（Decode）阶段。
- 预填充阶段需要一次性读入并处理大量的用户提示词，这一阶段是典型的计算密集型（Compute-bound）任务，对GPU的Tensor Core算力要求极高。
- 解码阶段则需要逐字往外生成内容，每次只计算一个新token。然而，为了写出这一个字，模型每一层都需要把之前所有的KV Cache从显存读取到计算核心中，这导致该阶段成为了典型的访存限制型（Memory-bandwidth bound）任务，对显存带宽极其敏感，算力核心大部分时间都在等待数据从显存搬运过来。
在传统的单卡运行模式下，这两个阶段被混合在同一张GPU上交替执行。这就导致当GPU在全力进行Prefill“读题”时，Decode任务必须停下等待；而当GPU在为Decode任务搬运显存数据时，强大的Tensor Core计算核心则只能闲置空转。
为了彻底打破这种相互拖累的僵局，行业演进出了PD分离（Prefill/Decode Separation: 动静分离/预填充与解码物理分离架构）。例如，DeepSeek等前沿团队就将这两个阶段物理拆分到不同的GPU集群上：
- 使用一组计算能力极强的GPU专门负责处理Prefill“读题”任务，32张卡组成一个紧密的最小计算单元。
- 一旦预填充完成，系统通过极高速的内部网络将生成的中间结果（KV Cache等）传输给另一组专门配置了超高显存带宽的GPU，由它们接手并心无旁骛地进行“逐字作答”的解码工作。
这种两拨卡各司其职、互不打扰的PD分离架构，已经成为了当前分布式推理引擎最核心的演进方向，并且在英伟达最新推出的分布式推理框架Dynamo中被放在了核心的架构位置。
在消除了等待之后，第三个核心问题是“如何让剩余的算力吃得更满”。当英伟达发布H100芯片时，其Tensor Core算力相比前代A100提升了数倍，但很多团队在实测中却发现推理吞吐并没有得到同等比例的飞跃。为了解决这个问题，行业开辟了两个主要的软硬件协同方向：
首先是低精度计算（Low-precision Computing: 使用低比特数值格式如FP8、INT4等进行存储与计算的技术）。大模型运行时的显存主要被模型权重、激活值和KV Cache三部分占据。通过在保证模型输出精度的前提下，将这三部分中的某一部分或全部转化为FP8甚至更低精度的数值格式，不仅能将显存占用减半，还能直接激活GPU内部速度极快的低精度专有计算单元，从而在合适的场景下凭空多释放出一倍的算力空间。
另一个方向则是投机采样（Speculative Decoding: 投机解码）。其核心思路是引入一个参数量极小、运行速度极快的“草稿模型”（Draft Model），让它去快速“猜测”接下来的几个可能单词；随后，将这一串猜测出来的草稿一次性喂给参数量巨大的“目标大模型”（Target Model）进行并行验证。
我们可以用学校里的“教授与助教”来做类比：大模型是学术造诣极高但时间极度宝贵的教授，小模型是思维敏捷、动作迅速的助教。在传统模式下，学生每写一个字都要向教授请教一次，教授确认后再写下一个字，这显然极度浪费教授的时间。而在投机采样模式下，助教先帮学生快速写出一段草稿（例如5个字），教授只需花一次抬眼的时间，就能并行核对并判断这5个字是否正确。如果前3个字是对的，第4个字错了，则前3个字直接通过，系统从第4个字开始重新生成。在最佳的概率匹配下，这种投机验证方式能将模型的整体生成速度提升2到3倍。
而推理引擎在此处扮演的角色，正是要在第一时间将这些低精度算子和投机采样框架，完美地集成并打通到AI Infra的四层架构中，让每一次软件调度的优化都能与底层的物理芯片达成最默契的配合。
推训协同与未来展望：Miles框架与操作系统的诞生
随着强化学习（Reinforcement Learning: 简称 RL，通过奖励机制引导模型进行自主探索与对齐的训练方法）成为以OpenAI o1、DeepSeek R1为代表的新一代推理大模型的核心训练手段，AI Infra所面临的挑战也悄然发生了根本性的变化。
传统的模型预训练或微调是一个相对单一的过程，GPU集群只需执行“喂入数据-前向计算损失-反向传播更新参数”的循环，计算负载高度均一。但在强化学习中，系统需要把在线推理（生成大量候选回答）、评估打分（Reward Model运行）以及参数更新（主模型训练）这三种计算特征完全不同的任务揉在同一个循环里交替运行：
- 推理生成阶段需要高显存带宽、低延迟以及前述的各类推理引擎优化。
- 训练更新阶段则需要高浮点计算力、大规模梯度同步以及高速的显卡间通信。
如果直接套用传统的训练框架去跑强化学习，推理和训练任务会在同一个GPU集群中发生严重的资源争抢。在模型疯狂进行样本生成时，负责训练更新的算力只能干等；而在训练更新权重时，生成端又陷入停滞。这种阶段切换和相互等待造成了算力的极大浪费。
为了解决推训一体化过程中的协同效率问题，RadixArk团队在SGLang推理引擎的基础上，推出了面向大模型后训练（Post-training）的开源训练框架——Miles。
Miles框架最核心的突破在于它彻底打破了“推理”与“训练”的软件壁垒，将二者置于同一个系统级调度器中进行协同优化。当Miles与SGLang紧密配合时：
- SGLang作为高效的推理端，源源不断地以极高吞吐产出新样本。
- Miles作为训练端，实时接收样本并快速更新模型的参数权重。
- 更新后的模型权重立刻通过显存共享或极速网络，无缝对齐并应用到下一轮的SGLang生成中。
这种设计消除了推/训框架之间频繁切换所导致的显存拷贝和同步等待开销，构建起一个极其高效的后训练闭环。针对复杂的混合专家模型（Mixture of Experts: 简称 MoE，通过门控路由将输入分配给不同专家网络进行处理的稀疏激活架构），Miles还在内核级并行策略和路由机制上进行了深度优化，有效解决了训练与推理在并行策略、显存分布以及精度控制上的不一致性问题（Training-Inference Alignment: 推训一致性），极大地提升了长文本和智能体任务在后训练阶段的系统稳定性。
正因为Miles与SGLang在解决大模型底层效率问题上展现出了无与伦比的技术深度，在RadixArk团队进行首轮融资时，AI硬件与系统层的几乎所有关键巨头均赫然在列。不仅英伟达、AMD、联发科（MediaTek）、Databricks等企业级巨头悉数到齐，甚至还吸引了包括英特尔CEO陈立武、博通（Broadcom）CEO陈福阳以及OpenAI联合创始人John Schulman等半导体与AI界顶级领袖的个人战略投资。对于这些巨头而言，投资高性能推理引擎不仅是财务投资，更是一场关于AI算力生态入口的战略下注。他们需要借助这一层核心的基础设施，将更多的前沿模型、企业应用和Agent生态牢牢吸附在自己的硬件芯片与算力网络之上。
今天，随着开源大模型迭代速度的指数级加快，几乎每隔几周就会诞生性能更强的开源模型。但对于广大的开发者和企业而言，开源模型向社会开放的仅仅是静态的权重参数，而“权重并不会自动变成运行中的token”。任何团队想要将这些模型落地，依然必须独自面对复杂的部署、显存调优、吞吐吞吐量优化以及硬件调度等一系列工程难题。
这正是像SGLang这样的推理引擎坚持实现“Day-0支持”（即在新硬件发布当天或新模型开源当天，立刻提供开箱即用的最高性能适配支持）的深远意义所在。这使得推理引擎越来越像大模型时代的“操作系统”——它向下屏蔽了英伟达、AMD及各类新兴AI芯片复杂的物理硬件差异，向上为形形色色的大模型和Agent应用提供了统一、高效、极简的运行环境。
正如RadixArk团队所愿，AI Infra效率的极限释放，其最大的社会学与商业价值在于“消除前沿实验室（Frontier Lab）的绝对壁垒”。当最顶尖的推理加速与后训练技术不再是少数万亿巨头的独占资源，而是变成了任何一个有想法的初创团队都能随时调用的公共基础设施，人人皆可成为前沿实验室。这不仅能显著降低社会使用AI的物理成本门槛，更能让AGI以更民主、更多样、更迅猛的方式真正走近每一个人。