无服务器(Serverless)架构下的Token级按需扩容

无服务器(Serverless)架构下的大语言模型Token级按需扩容与调度机制深度研究报告

引言：大语言模型时代无服务器架构的范式转移

在现代云计算的演进历程中，无服务器（Serverless）架构凭借其按需扩展、缩容到零以及按使用量计费的核心优势，早已成为微服务、事件驱动型应用以及无状态后端处理的标准范式。然而，当这种建立在快速启停与无状态假设之上的架构体系，遭遇以生成式预训练大语言模型（Large Language Models, LLMs）为代表的现代人工智能推理需求时，传统的资源调度与容器级扩容机制暴露出严重的性能瓶颈与极端的成本浪费。

大型语言模型的推理本质上是一个高度状态化且对计算和显存资源需求极度不对称的复杂过程。每一次LLM推理请求都被严格划分为两个阶段：计算密集型的预填充（Prefill）阶段和访存带宽密集型的解码（Decode）阶段。如果云平台继续沿用传统的按“请求（Request）”进行微服务调度的模式，长短不一的生成任务会导致严重的队头阻塞（Head-of-line blocking），使得极其昂贵的GPU算力大量闲置。更为严峻的是，随着模型上下文窗口从数千词元（Token）向百万级规模的指数级增长，运行时的注意力键值缓存（Key-Value Cache, KV Cache）体积往往远超模型权重本身。这使得在Serverless架构中进行节点间的动态请求迁移或冷启动变得极其沉重且不可预测。

为了彻底解决上述挑战，2025至2026年间的AI基础设施领域爆发了一场深刻的底层架构革命：系统调度的最小粒度正式从粗放的“请求（Request）”维度，下沉至最细微的“词元（Token）”维度。围绕Token级连续批处理（Continuous Batching）、预填充与解码的物理集群解耦（Prefill-Decode Disaggregation）、跨节点分布式KV Cache池化（KV Cache Pooling）机制，以及基于“Token流转速度（Token Velocity）”的前瞻性自动扩容算法，新一代无服务器LLM基础设施得以被彻底重塑。本报告将从调度机制、硬件拓扑重构、分布式显存管理、全栈多模型虚拟化以及顶级云厂商（AWS、Azure、GCP）的商业化战略等多个维度，深度剖析Serverless架构下大语言模型Token级按需扩容的演进路径与技术全貌。

1. 调度粒度的降维演进：从请求级到Token级的连续批处理

在传统的Web服务架构中，容量规划与资源分配通常以请求数（QPS）、CPU使用率或内存占用等指标作为核心考量。但对于LLM服务而言，这些宏观指标几乎完全失效。一个包含10个Token输出的简短分类请求与一个生成上千个Token的复杂代码编写请求，其占据GPU的时间跨度和资源消耗模式有着天壤之别。这种请求内部深度的不可预测性，宣告了传统静态调度策略在LLM推理领域的终结。

1.1 静态与动态批处理导致的算力空转危机

在早期的深度学习模型推理（如图像分类或传统自然语言处理）中，系统多采用静态批处理（Static Batching）。这种机制要求系统必须等待固定数量的请求在队列中汇聚后，才将它们组合成一个统一的张量，送入模型执行单一的前向传播。由于图像分类等任务的输出大小是固定的，这种批处理非常高效。然而，在自然语言生成任务中，输出序列的长度差异巨大。在静态批处理框架下，即使批次中某个请求仅需生成15个Token便输出了结束符（EOS），它也必须锁定在GPU内存中，等待同批次中需要生成800个Token的最长请求执行完毕。在长达785个迭代的漫长时间里，该短请求占据的GPU计算槽位处于完全闲置的“填充（Padding）”状态，导致GPU的实际有效利用率常常跌至30%至60%的低谷，企业却必须为这种算力空转支付全额费用。

为了缓解这一问题，推理系统引入了请求级动态批处理（Dynamic Batching），即设定一个极短的时间窗口（例如50毫秒），将窗口内到达的所有请求打包处理以降低准入延迟。但在批次层面的执行逻辑并未改变：一旦批次窗口关闭并开始执行，该批次依然必须作为一个整体运行直至最后一个序列结束，资源闲置与利用率低下的根本痛点仍未得到解决。

1.2 连续批处理（Continuous Batching）的核心机制

为了彻底打破批次锁定带来的算力浪费，连续批处理（也称为In-flight Batching或迭代级调度）应运而生，并迅速成为vLLM、TensorRT-LLM、SGLang等现代高性能推理引擎的标准基础设施。连续批处理从根本上改变了调度范式，将调度决策点从“请求边界”下移到了“Token边界”。

在模型前向传播的每一个迭代（即生成每一个Token的微观周期）结束后，调度器会即时扫描当前运行的批次状态。若某个序列成功发射了结束符（EOS Token），系统会立即将其KV Cache显存块释放。紧接着，调度器会从等待队列中拉取足够数量的新请求来填补空缺的内存槽位。这些新请求与原本活跃的序列被串联成一个没有任何无用填充（Padding-free）的“超级序列（Compound Batch）”。结合FlashAttention等技术的变长内核（Variable-length kernels）支持，所有不同长度的序列能够在单个GPU内核调用中无缝并行计算，确保每一滴GPU算力（FLOP）都被用于真实的Token处理，极大地拉升了硬件的利用率基线。

1.3 分块预填充（Chunked Prefill）与动态抢占恢复策略

尽管连续批处理在解码阶段极大提升了吞吐量，但它引发了一个新的调度冲突：当一个新的超长上下文请求突然到达时，处理其庞大的预填充任务需要在单次前向传播中进行海量矩阵乘法运算。这会长时间霸占GPU算力，导致同一批次中正在进行解码的其他短请求被迫暂停，终端用户感知到的就是输出字符突然卡顿，跨Token延迟（Inter-Token Latency, ITL）出现灾难性的飙升。

为了在保持高吞吐的同时平衡系统响应平滑度，vLLM引擎在V1架构中默认启用了分块预填充（Chunked Prefill）技术。该机制将长提示词切分为较小的、可配置的Token区块（在最新版本中默认预算已上调至2048个Token），并将这些切片与活跃序列的解码操作在多个迭代周期中交错调度。解码请求被赋予最高调度优先级，确保在长上下文请求入场时，P50级别的延迟表现依然平稳，有效平衡了首Token延迟（Time-to-First-Token, TTFT）与ITL这一对核心服务等级协议（SLO）指标。

在高度动态的Serverless环境中，流量不可预测的激增会迅速耗尽用于存放中间状态的显存池。此时，推理引擎必须触发Token级的动态抢占（Preemption）机制以避免内存溢出崩溃。面对被驱逐的请求序列，系统通常提供两种恢复模式。第一种是显存交换（Swap），即把被抢占序列的物理显存块序列化并迁移至CPU的DRAM中。然而，对于如Llama-3-70B等大参数模型，通过PCIe 4.0 x16链路（约32 GB/s）进行数十GB缓存的回迁需要消耗数百毫秒，严重破坏了实时流式输出的体验。第二种是重计算（Recompute），即在请求重新准入时，直接丢弃原有KV Cache并从头执行预填充。在现代架构验证中，由于重计算的纯算力开销远低于PCIe慢速链路带来的数据搬运延迟（尤其在较小的显存块设置下，重计算开销从未超过交换延迟的20%），重计算已成为默认且更高效的抢占容错策略。

为了直观地反映不同批处理策略对系统资源的占用与效能差异，下表进行了系统的性能维度对比分析：

2. 架构的物理重构：预填充与解码的彻底解耦 (PD Disaggregation)

在单节点层面的Token级调度机制逐渐完善后，企业在生产环境中很快遭遇了物理法则层面的第二堵高墙。无论是连续批处理还是分块预填充，当并发请求数达到成百上千的规模时，算力与显存争抢的零和博弈开始在单块GPU上凸显。

2.1 算力与显存带宽的深层物理冲突

LLM推理的两个阶段在硬件资源需求上呈现出完全对立的物理特征。预填充（Prefill）阶段需要一次性并行处理所有的输入Token，这要求极其庞大的矩阵乘法运算能力。该阶段是典型的计算密集型（Compute-bound）任务，能够让GPU的Tensor Core满载运转，但对显存带宽的压力相对可控。

相反，解码（Decode）阶段是自回归的，模型只能逐个Token顺序生成。每生成一个新的Token，系统都必须从高带宽内存（HBM）中完整读取数百GB的模型权重以及不断膨胀的历史KV Cache。因此，该阶段是绝对的显存带宽密集型（Memory-bandwidth-bound）任务。在解码过程中，GPU庞大的计算核心往往处于饥饿等待状态，仅仅是在等待数据从显存搬运至SRAM。

若强制将这两类特征迥异的工作负载捆绑在同一个计算节点内运行，系统必然陷入低效的妥协：昂贵的高算力芯片在解码时大量闲置，而大显存芯片在预填充时算力不足。正如研究者所比喻，这就如同在一个咖啡馆中，同一名员工既要处理大批量的咖啡豆研磨（耗时且阻塞），又要负责响应迅速的意式浓缩冲泡，单队列的阻塞不可避免。

2.2 DistServe、Splitwise与异构解耦部署

针对这一困境，前沿学术界与工业界在过去的18个月内共同推动了预填充-解码解耦（PD Disaggregation）架构的普及。DistServe系统首先在OSDI 2024会议上证明了将两阶段拆分至不同GPU池中独立扩展的巨大价值，能够依据各自的SLO（即TTFT和TPOT）动态分配资源，相较于混合部署取得了高达4.48倍的吞吐量提升和十倍以上的SLO合规率提升。

紧随其后的Splitwise等研究，则进一步将解耦理念推向了硬件异构化。在多供应商数据中心和云厂商的基础设施中，预填充阶段完全可以被分配给专为高算力设计的芯片（如NVIDIA B200或专用的Rubin CPX计算节点），而解码阶段则可以运行在专为极高带宽和内存容量优化的加速器（如Groq LPU或Intel Gaudi 3）上。通过异构硬件的结合，服务商在提供相同乃至更低延迟服务的同时，可将整体总拥有成本（TCO）大幅削减，使得百万Token级别的生成成本达到商业可行性。

为了清晰展示不同部署架构对硬件选型及性能瓶颈的影响，下表对比了聚合部署与解耦部署的核心差异：

2.3 Kubernetes云原生治理：KServe与llm-d编排引擎

当PD解耦架构走出实验室，走向生产级Kubernetes集群时，随之而来的是极度复杂的网络拓扑和生命周期管理难题。此时，KServe与 llm-d 的联合架构确立了企业级云原生AI基础设施的标准蓝图。

作为Kubernetes平台上的模型服务控制平面，KServe通过新引入的 LLMInferenceService 自定义资源定义（CRD），全面接管了生成式AI工作负载的编排管理。不同于基于CPU利用率的默认水平自动扩缩容（HPA），KServe深度集成了Knative Pod Autoscaler (KPA) 与KEDA，依托于实时的“并发请求数”、“Token吞吐率”和“队列深度”进行激进的扩缩容操作，并在流量低谷期完美支持“缩容到零（Scale-to-zero）”，从而显著压低了企业长期持有闲置GPU的账单。

在执行层面，由Google、NVIDIA、IBM等联合发起的开源项目 llm-d 为解耦后的集群注入了智能路由的大脑。llm-d 的核心是一个称为Envoy AI Gateway的高性能L7代理与端点选择器（EPP）。当一个请求抵达时，系统并非简单采用轮询算法，而是利用在线训练的轻量级XGBoost机器学习模型实时预测每个端点处理该请求的TTFT和TPOT。由于加速器的计算特性相对确定，该预测模型通过考量输入提示词长度、当前活动请求数、KV Cache命中率等特征，达到了惊人的5%以内平均绝对百分比误差（MAPE）。EPP会智能地将预填充任务派发至算力空闲节点，并随后将其附带特定请求头（Header）定向至解码节点进行持续生成，完美消除了人为设定启发式权重的不准确性。

2.4 网络层：NIXL与RDMA的微秒级跨节点数据交换

解耦架构引入了一个硬性的物理约束：由于预填充节点与解码节点分离，高达数十乃至上百GB的KV Cache必须在第一阶段计算完成后的毫秒级时间内跨越网络传输至目标节点，否则传输延迟将吞噬解耦带来的所有优势。

为了应对这一挑战，NVIDIA推出了推理传输核心库 NIXL (NVIDIA Inference Xfer Library)。该组件直接打通了异构底层传输硬件，封装了基于UCX协议的RDMA（远程直接数据存取）、InfiniBand与RoCE网络，以及针对AWS云环境优化的libfabric (EFA)。通过NIXL，解码节点可以直接利用单边RDMA READ指令，在绕过宿主机CPU与操作系统的零拷贝（Zero-copy）状态下，直接从预填充节点的GPU显存中拉取所需KV Cache块。这种级别的底层网络通信保障，是使得跨服务器PD解耦在延迟敏感的流式对话场景中能够真实落地的物理基石。

3. 分布式KV Cache池化与实时状态迁移：跨越Serverless状态墙

无服务器架构的最核心假设是计算实例必须是无状态的（Stateless），这赋予了系统秒级弹性扩张的能力。然而，大语言模型推理却是一个极为厚重的“有状态”过程。为了避免重复计算并实现自回归解码，每一层注意力机制产生的结果都被永久保存在GPU显存中形成KV Cache。随着提示词动辄数以万计，缓存体积急剧膨胀。这道横亘在“无状态弹性”与“有状态推理”之间的显存高墙，使得传统的Serverless缩放机制彻底失效。

3.1 实时迁移与重计算平衡：ServerlessLLM架构

当Serverless系统为了应对瞬时流量而启动新节点，或者因为负载均衡需要将进行多轮对话的用户请求重定向至其他GPU时，新节点面临的是缺乏任何历史上下文的冷状态。如果系统强制要求客户端重新上传海量的对话历史并从头执行数十秒的预填充，这无疑将造成服务中断级的用户体验滑坡。

为了实现状态在Serverless集群间的平滑游走，研究者在SOSP会议上发布了革命性的 ServerlessLLM 系统，首次在LLM服务中引入了实时迁移（Live Migration）机制。ServerlessLLM摒弃了将整个庞大的脏状态（数十GB的KV Cache）通过网络强行搬运的传统思路，它基于一个敏锐的系统洞察：利用GPU进行算力重计算的速度，远高于在拥挤数据中心网络中传输同等数据量的速度。

在进行请求迁移时，ServerlessLLM采用多轮迭代协议：源节点仅将极小的、已生成的数百KB的Token序列传输给目标节点。目标节点在接收到轻量级Token后，立刻启动内部GPU进行KV Cache的重计算同步。当目标节点的重计算进度即将追平源节点时，源节点停止推理，发送最后一批极少量Token并触发网络层的路由切换。该策略将网络传输负担降低了三个数量级，在实际Serverless环境（如Azure Trace工作负载下）中，使得首Token延迟实现了惊人的10倍至200倍的下降，平均启动延迟被压缩至亚秒级别。

3.2 走向显存池化：Mooncake、LMCache与全局缓存联邦

虽然ServerlessLLM解决了动态调度过程中的状态迁移难题，但在当前以检索增强生成（RAG）、智能企业Agent以及带有数百页PDF背景知识为特征的应用场景中，请求之间存在大量重叠的上下文提示词。如果每个独立的Pod都在自己的显存中孤立地重计算相同的系统提示，将造成灾难性的算力冗余。

为此，包括阿里、清华大学与Moonshot AI在内的联合团队在FAST 2025顶会上推出了具有分水岭意义的 Mooncake 分布式KV Cache池化存储引擎。该架构将缓存管理的视角从单个GPU实例上升到了整个数据中心网络层面，彻底打破了由进程或Pod所定义的缓存物理边界，构建了三级层次化存储体系：

Mooncake通过其底层的Transfer Engine利用RDMA在预填充与解码节点间高效流转数据，同时借助Mooncake Store管理横跨集群的分布状态。当一个新的包含长篇企业背景知识的RAG请求抵达某个刚启动的Serverless实例时，系统能够通过Hash比对，瞬间从全局L3网络池或相邻节点的L2 DRAM中将其前缀缓存精准“拉回”，彻底规避了冗长的重计算。在真实生产负载下（如每日处理数千亿Token的Kimi应用），这种以缓存为中心的解耦架构将首Token延迟（TTFT）缩减了惊人的14倍，在同等硬件算力下，实现了有效请求承载能力超过翻倍（107%~115%）的增长。同类型的生态技术（如AWS SageMaker上的Curvine方案与开源的LMCache）也在各自的版图中印证了这一三级显存联邦架构在降低推理系统总体拥有成本上的巨大潜力。

4. 前瞻性扩容与Token级多模型虚拟化池化

在具备了单机连续调度、集群解耦以及分布式显存网络后，Serverless LLM平台面临着最后一个维度的挑战：系统如何知道在何时该增加或销毁容器实例？

4.1 滞后指标的失效与TokenScale前瞻性扩容体系

在传统的云原生自动扩缩容机制中，调度器（如Kubernetes HPA）深度依赖GPU利用率、队列深度或吞吐量等指标。在LLM领域，这是一种极其危险的滞后指标（Lagging Indicators）。由于冷启动大型模型（加载百GB权重至显存）需要长达数十秒的物理时间，当系统观察到现有队列拥堵并触发扩容动作时，那些在等待队列中的请求早就突破了系统承诺的SLO上限。

为了彻底改变“亡羊补牢”式的扩容窘境，研究者提出了 TokenScale 自动扩容框架，引入了一个颠覆性的前瞻测量维度——Token速度（Token Velocity）。Token Velocity能够微观量化给定实例在当前瞬时资源分配下，各个处理管线的极限吞吐潜力。该指标将系统拆分为三大速度域：

1. 预填充速度 ($V_P$)：由GPU Tensor Core算力界定，反映处理海量输入Token的极限效率。
2. 网络速度 ($V_N$)：由RDMA/RoCE网卡带宽界定，反映跨节点倾泻KV Cache数据的极值。
3. 解码速度 ($V_D$)：由显存带宽主导，反映系统“排干（Drain）”正在生成的Token并释放资源的速率。

TokenScale的神经中枢实时监控瞬时输入流量与这三种Velocity的动态比例。当系统预判到预填充管线即将因流量激增而出现拥塞时，TokenScale利用其独创的可转换解码器（Convertible Decoders）机制展开自救。通过在毫秒级别内更改实例角色，将原本闲置的解码GPU转化为预填充工作站，构建出一层能够吸收流量洪峰的弹性缓冲带。这一微观变阵彻底绕过了请求云平台启动新虚拟机的数秒延迟，在真实部署（如应对Azure Conversation和Code工作负载骤增）中，将系统在极端压力下的SLO达标率从脆弱的50%-88%大幅拉升至极其稳健的80%-96%，同时还削减了最高达14%的硬件成本溢价。

4.2 Aegaeon：极致的Token级多模型虚拟化与混部

在商业云平台（如阿里云模型服务）的实际运营中，另一个棘手的问题是多模型的碎片化管理。平台不仅需要支撑头部大模型的高并发，还必须托管数百个调用频次极不稳定的长尾微调模型或小模型。如果为每个模型单独预留常驻GPU，闲置成本将是一个天文数字。

针对此难题，SOSP 2025顶会上发布的 Aegaeon 系统在虚拟化粒度上完成了历史性突破。有别于NVIDIA MIG（多实例GPU）这种在硬件空间层面的死板物理切割，Aegaeon实现了跨模型的Token级别动态调度池化。其核心突破在于允许不同模型的请求在同一组GPU物理计算单元上，于相隔数毫秒的连续推理迭代中无缝交错执行。

Aegaeon将统一的GPU显存视为一个被精细切割的大型租户空间。它通过自主实现的极速Bump Allocation（碰撞内存分配）和Slab Allocation（厚板分配）机制接管了底层张量库的内存权限，彻底清除了深度学习框架内置垃圾回收（GC）机制导致的卡顿与长尾延迟。对于不同模型的调度：

• 在预填充阶段，执行分组先来先服务（Grouped FCFS），优先将同一模型请求打包计算，压低首Token延迟的波动。
• 在解码阶段，执行精密的加权轮询（Weighted Round-Robin），基于每个请求设定的生成截止时间（Deadline）分配微秒级的执行配额（Turns），确保高优模型和低优模型的Token生成过程平滑进行。

结合CUDA事件级细粒度控制的极速权重与缓存搬运，在阿里巴巴Model Studio的真实生产环境Beta测试中，Aegaeon展现出了令人惊叹的降本增效成果。在支撑同等规模、数十个异构LLM并存的复杂业务群落时，平台所需的物理GPU总量从庞大的1192张，崩塌式地缩减到了仅仅213张。这一高达82%的绝对算力缩减，以及逼近9倍的整体有效吞吐（Goodput）飙升，充分证明了在Serverless架构中进行Token级别细粒度虚拟化调度的不可替代性。

5. 公有云Serverless LLM的商业化路径与容量治理

学术界与开源社区在架构底座上的狂飙突进，最终在2025至2026年全面融入了全球顶级云厂商（AWS、Microsoft Azure、Google Cloud Platform）的商业级托管AI平台（AI Managed Services）体系。随着基础技术同质化程度加深，三大巨头针对Serverless LLM的容量扩展策略与流量计费模型演化出了高度成熟且特征鲜明的商业路径。

5.1 云厂商的定价模型与计费博弈

企业级客户在公有云上部署LLM应用时，当前主要面临两种截然不同的容量采购模型：以敏捷性见长的按需计费（On-demand / Serverless PAYG），以及以确定性见长的预置吞吐量（Provisioned Throughput / PTU）。

以下是主流云平台在不同定价机制下的特征与优势对比：

具体到各云厂商的策略：

• Microsoft Azure (Azure OpenAI)：Azure的策略高度聚焦于企业级稳定性和合规生态。对于运行GPT-4o或o1模型，Azure强烈推荐客户在生产环境跨越关键门槛后采用PTU。以GPT-4o为例，当企业月度消耗超过约20亿Token时，采用包月PTU的单位Token成本将比PAYG按需模式便宜30%到50%，同时彻底剥离了在业务高峰期触发平台共享流量熔断的风险。
• Amazon Web Services (Amazon Bedrock)：AWS通过Bedrock平台提供了一个极为宽广的异构模型中立市场（支持Anthropic, Meta, Mistral以及Amazon自研Titan系列）。Bedrock的Serverless扩容架构依托于极端细微的多维度额度系统：包括每分钟请求数（RPM）、每分钟词元数（TPM）以及每日最大词元数（TPD）。为了构建坚不可摧的成本防线，企业架构师通过将Bedrock API与AWS Step Functions工作流以及DynamoDB深度绑定，部署“前置型成本哨兵（Cost Sentry）”。该架构能够在中转层拦截并核算每一笔Token花销，确保在爆发性Agentic工作流失控引发天价账单前及时熔断服务。
• Google Cloud (Vertex AI)：GCP依托底层TPU芯片强大的规模化算力矩阵与海量带宽网络，在长文本与大通量场景中展现出极其粗犷的统治力。Gemini 1.5和2.0系列原生支持百万级别的超长上下文，为了平衡庞大的算力开销，Vertex AI不仅提供了标准的按需与预置管道，还巧妙设计了Flex PayGo（弹性按需计费）。它允许企业将海量对延迟不敏感的数据清洗或标注任务推入平台的低优队列，用更低的单位Token定价进一步榨干底层基础设施的闲散算力。

5.2 细粒度网关与Token感知路由 (Token-Aware Gateway)

随着LLM生态向以大语言模型为核心执行大脑的Agentic应用演进，请求流量在平台侧变得愈发诡谲多变。基于HTTP连接数限制的传统API网关（如Nginx）已经无法透视并管理承载在JSON Payload中指数级波动的Token账单消耗。

在现代生产系统中，处于请求最前沿的 Token级感知网关（如Envoy AI Gateway扩展、Agentgateway与Fenic框架） 成为了不可或缺的基础设施组件。这类智能网关实施了基于Token计数的漏桶算法。它们不再单纯评估“每分钟多少次API调用”，而是精细到“在特定业务路由下，允许每分钟流过5000个Token”。当遇到瞬时激增（如用户突然上传了长达上千Token的系统级超大文档）且未超配额时，网关利用底层的“可转换解码器”等冗余架构平滑吞吐。而一旦识别出恶意消耗或超出预设的RPM/TPM限制，网关不会粗暴截断，而是无缝将超出阈值的高昂算力请求重定向（Failover）至廉价的降级模型（例如从庞大的Claude 3.5 Sonnet或GPT-4级降阶回滚至Claude Haiku或GPT-4o Mini）。这种在业务网关层的智能防抖转轨，不仅规避了Serverless调用失控导致的账单黑洞，同时从根本上确保了高并发场景下核心业务的连续可用性。

结论

无服务器架构下的大语言模型Token级按需扩容，代表了分布式系统工程在人工智能时代的一次伟大而彻底的底层重构。

这一转型的核心，在于对云计算资源颗粒度的重新认知与定义：Token，而非Request，才是大型语言模型时代的唯一通用计算货币。从vLLM引入分块预填充与连续批处理来消除GPU单节点内的显存填充浪费，到DistServe与KServe llm-d 彻底分离算力密集的预填充集群与带宽密集的解码集群；从Mooncake打破物理边界，构建跨越高速RDMA网络的全局三级KV Cache联邦池化体系，再到TokenScale与Aegaeon依托毫秒级状态同步实现的“以模型为客体、以Token为切片”的多模型极致混部虚拟化——全栈基础设施的疯狂演进都指向了一个清晰且唯一的终极目标：在极度不可预测的生成式推理任务浪潮中，彻底榨干每一滴硅晶片的有效吞吐量（Goodput）。

对于面向未来的企业级架构师与云基础设施工程师而言，AI平台的系统设计范式已发生根本性偏转。未来的推理网络不再是简单地将参数装入Linux容器并叠加粗放的水平扩容（HPA）。构建具备长期竞争力的前沿生成式AI架构，必须深度介入微观的显存分层、跨节点的单边网络传输协议（NIXL）、前瞻性的细粒度调度预测（Token Velocity）以及拥有Token感知能力的全局路由网关。唯有彻底击碎硬件孤岛的壁垒，实现状态缓存与算力执行的绝对解耦与液态化共享，现代云原生基础设施才能真正托举起正加速向我们走来的Agentic AI时代的磅礴算力狂澜。