LLM分布式推理终极方案——以GPU为中心的云原生架构

当前LLM推理部署的核心挑战

目前主流的LLM推理服务多以KV Cache为核心设计，结合L3缓存架构：

• L1：HBM（高带宽内存），作为GPU自带的高速缓存具备极高的吞吐，例如H20的容量为96GB，吞吐可达2TB/s，延迟仅~100+ ns；
• L2：本地内存（Local DDR，常用DDR5），目前旗舰服务器基本配置2TB，吞吐约500GB/s，延迟约80ns。结合vLLM的页注意力（Page Attention）和SGLang的基数树注意力（Radix Attention）技术，可将HBM中的次热点数据从HBM换出至DDR，或从DDR换入至HBM，避免重复计算；
• L3：远端存储（remote storage），如mooncake和hf3fs，依托分布式存储集群提供大容量存储，可实现更大规模的数据缓存；

这三级缓存架构依然遵循“速度越快，单位成本越高，容量越小”的金字塔型结构。例如，NVMe的性能远低于DDR，但1TB内存的成本约为NVMe的30～100倍，因此这也是工程实践中“正确的折中”。

基于该三级缓存架构实现数据缓存，SGLang模型网关（SGLang Model Gateway）及其他同类组件可提供良好支持，通过基数树（Radix Tree）方式在分布式层面实现前缀匹配，大幅提升KV缓存的命中率。从目前主流模型即服务（MaaS）厂商的定价来看，KV缓存是否命中会导致成本相差10倍；从技术角度而言，KV缓存命中可避免大量预填充（Prefill）计算，提升硬件利用率。

以KV Cache为中心的架构并非完美，仍面临以下几方面问题：

• 缓存与调度的冲突：在大容量本地DDR缓存方案下，若扩容新节点，新节点上必然不存在KV缓存，后续处理的请求将面临缓存零命中；若缩容存量节点，节点上的缓存会丢失，导致KV缓存失效，该方案严重限制了业务的自动化扩缩容能力。数据中心中通常同时运行多个业务，不同业务存在用户量的增减，同一业务也常出现波峰与波谷.服务的弹性伸缩能力直接决定集群的平均资源利用率，也是这个技术方案的上限。
• 性能的不可预期性：SGLang模型网关虽能大幅提升KV缓存的命中率，但也间接说明命中率存在高低波动。尤其在以KV缓存命中率为优先、结合负载均衡策略的共同作用下，命中率属于区间变量。而在对数据中心大规模分布式业务进行优化时，这类不确定性问题往往最难解决——我们在分析、解决问题的时候，总是希望业务的性能指标能够被尽量精确地度量，进而开展优化、重新度量并论证优化效果。
• 内存与数据冗余压力：L2缓存对本地内存依赖度高，且多个推理节点之间存在重复的KV Cache数据，造成资源浪费。同时，AI业务的爆发式增长也推动业界存储价格大幅上涨。
• 状态管理复杂且脆弱：SGLang Model Gateway在内存中记录请求序列与服务节点的映射关系，一旦映射关系丢失，需重新构建。在K8S/无状态服务主导数据中心的当下，这类脆弱的组件已不符合主流在线业务的需求。
• 成本的不透明性：KV缓存是否命中会导致输入Token的成本相差10倍，而命中率具有不确定性，其高低与后端优化能力、访问顺序（如A和B发起相同请求，后发起请求者可实现缓存命中）、访问间隔（如A两次访问间隔较近时缓存未被淘汰，间隔较远时缓存已淘汰），甚至缓存命中判断逻辑的准确性均相关。

LLM无状态化推理的分布式终极架构

互联网后端架构变革的经验

互联网后端架构历经二十二年的发展，其演进路径为LLM无状态化推理提供了重要参考：

• 2000-2005年：LAMP黄金时代的单体困境。这一时期的互联网应用以静态页面与简单动态交互为主，业务复杂度较低，基于Linux、Apache、MySQL、PHP/Perl/Python组成的LAMP开源技术栈成为绝对主流。此时的扩展方式以垂直扩展为主，即通过提升单台服务器的CPU、内存等硬件配置应对业务压力；水平扩展仅能通过HAProxy、硬件F5等负载均衡设备实现有限支持，且需手动配置服务器参数，扩展性与运维效率较差。这一阶段尚无明确的“无状态”概念，服务与状态深度耦合，一旦服务器宕机，极易导致数据丢失与服务中断。
• 2005-2010年：分布式转型与无状态萌芽。随着电商、社交等复杂互联网业务崛起，用户规模与数据量呈爆发式增长，LAMP单体架构的局限性彻底暴露，后端技术栈开始向分布式、专业化方向演进。这一阶段的核心变革是“解耦”：数据库层率先实现读写分离，通过“一主多从”架构分摊读压力，同时分库分表技术解决数据量激增问题；缓存层快速崛起，Memcached、Redis等工具将热点数据加载至内存，大幅降低数据库访问压力；Nginx凭借其高性能、高并发的优势取代Apache成为主流Web服务器，配合LVS等四层负载均衡设备形成多级负载分发体系。
• 2010-2020年：Docker与K8s引领的无状态成熟时代。伴随云原生生态持续完善，无状态架构的支撑体系愈发健全，以K8s（ Kubernetes）为代表的无状态服务框架展现出显著优势：通过DNS/IP实现服务发现与负载均衡，支持手动或自动水平扩缩容，具备灵活的存储编排能力，可实现容器的自动部署、回滚与智能装箱等功能。
• 2020-2025年：弹性计算与成本极致优化。基于K8s成熟的弹性扩缩容能力，业界普遍落地在线业务与离线业务的混合部署方案，实现资源的动态调度与高效复用。其核心逻辑为：通过K8s的优先级调度、资源配额等机制，为在线业务设置更高优先级，确保其性能不受影响；在在线业务波谷期，将闲置的计算资源动态分配给离线业务（如大数据分析、模型训练、日志处理等对实时性要求较低的任务），部分场景下可对外售卖变现；在波峰到来前，通过预设的弹性策略触发离线业务自动释放资源，将资源完整交还给在线业务。该模式大幅提升了资源利用率，部分企业的集群资源利用率从传统的30%-40%提升至80%以上，显著降低了硬件采购与运维成本。

Kubernetes架构的成功，核心前提是业务的无状态化运行。可以预见，若LLM推理业务能够实现无状态化运行，K8s带来的资源利用率提升、运维简化等收益可以直接复现。因此，LLM无状态化推理是行业演进的重要方向，甚至是终极方案，当前的核心问题在于如何实现LLM无状态化推理。

GPU Direct Distributed File System

若LLM的KV缓存卸载与加载速度足够快，即可打破本地有状态数据对服务调度的限制，实现与Kubernetes的完美适配。这一目标的实现，需依托全新的高性能存储组件作为核心支撑。值得注意的是，LLM服务的KV缓存属于可重新计算的计算状态，因此“持久化”并非必选项，其核心诉求聚焦于“足够低的延迟”与“足够低的存储成本”。基于这一前提，我们研发了GD2FS（GPU Direct Distributed File System）——该系统深度融合GPU加速与高速网络能力，支持GPU直连远程直接内存访问（GPU Direct RDMA），同时兼容TCP多网卡、多流并发，从系统架构层面突破存储性能瓶颈。

在副本策略上，GD2FS采用弹性设计，充分契合KV Cache可重计算的特点，具体如下：

• 单副本：用于KV缓存存储，可实现更低的成本与更大的存储容量，采用回写（write back）方式实现极速写入，满足LLM推理的低延迟需求；
• 多副本：用于检查点（Checkpoint）、模型文件等需持久化的数据，采用经典三副本策略防止数据丢失；缓存层面支持1\-N副本弹性伸缩，可有效避免推理引擎启动风暴。

基于GD2FS，我们设计了全新的L2缓存架构，具体如下：

• L1：GPU自带的HBM，是GPU正式推理的KV Cache；
• L2：GD2FS分布式存储，替代传统本地DDR，数据直接在GD2FS与HBM之间交换，全程实现零拷贝；在400G网卡环境下，加载缓存的延迟比本地DDR略高50%左右。

FIO性能测试

测试硬件配置：英特尔（INTEL）PLATINUM 8563C；英伟达（NVIDIA）H20 96GB；迈络思（Mellanox）CX7 400Gbps；英特尔（INTEL）SSDPF2KX038T1。

在单400G网卡下，GD2FS读取1GB的延迟约等于Redis的1%；如果并发使用多网卡（同一个NUMA Node下的），那么GD2FS的性能基本可以做大线性扩展，比Redis快100倍以上。

显式KV缓存（Explicit KV Cache）管理

显式KV缓存（Explicit KV Cache）通过“控制信息与数据分离”的设计，可实现多轮会话KV缓存100%命中，有效解决了传统缓存命中率不稳定的问题。其核心示例如下：

"stored_kv_cache": [{
"token_start": 0,
"token_length": 8192,
"kv_uri": "gd2fs://cluster-01/session-97f1226c-...",
"kv_start": 0,
"kv_length": 134217728
}],
"fresh_kv_cache": [{
"token_start": 8192,
"token_length": 8192,
"kv_uri": "gd2fs://cluster-01/session-97f1226c-...",
"kv_start": 134217728,
"kv_length": 134217728
}]

在该示例中，stored_kv_cache代表已缓存的KV缓存，包含多段KV缓存的元信息；每一段元信息均包含对应Token的起始位置、长度，以及对应的KV缓存统一资源标识（KV URI）。fresh_kv_cache则代表待写入的KV缓存元信息。

显式KV缓存（Explicit KV Cache）的核心收益包括：

• 适配K8S：结合GD2FS可无缝接K8S系统，充分复用K8S的各项核心能力，在大规模部署场景中，能够显著提升集群整体计算资源的平均利用率，同时降低运维复杂度、提升运维效率。
• 主机内存占用可控：在典型应用场景下，SGLang进程的内存占用量低于4GB。较低的内存消耗不仅能大幅降低推理实例的部署成本，还能减少操作系统后台内存管理对进程运行的影响。
• 性能与成本可预期：借助显式KV缓存的元信息，可在会话启动前精准预估可调用的缓存Token数量，进而准确预测推理执行时间与成本，有效解决了传统L3缓存架构中性能与成本不可控的痛点。
• KV缓存生命周期可控：新会话启动时，系统会自动创建包含KV缓存统一资源标识（URI）的相关元信息；会话终止时，对应KV缓存会被及时清理。此外，可针对不同优先级用户，采用差异化策略管理KV缓存的保留时长，进一步提升资源利用效率。
• 支持显式共享：当多个会话的历史KV缓存存在相同片段时，可通过显式配置实现KV缓存共享。例如，不同用户针对同一篇论文提出不同问题时，可共享大部分前缀KV缓存数据。
• 预读分层缓存：当会话请求到达时，系统可主动提前加载用户相关的KV缓存（如从NVMe加载至内存）；预读完成后，再将会话请求路由至GPU节点进行推理处理。该机制可显著降低GPU因等待I/O操作产生的空闲延迟，提升GPU资源利用率。
• 副本数量动态可调：可根据会话内容的热门程度，动态调整KV缓存的存储副本数量。例如，针对热门论文相关的KV缓存，可适当增加副本数量，避免存储节点成为性能瓶颈，保障推理服务稳定性。
• 元信息数量可控：元信息的条目数量与会话轮次相关，且多轮会话之间可复用同一条目，对于GD2FS而言，仅需增长文件长度即可。与之相对的是L3架构下，采用哈希值（Hash）计算固定数量Token序列的方案，其键值对（Key-Value）数量与Token序列长度正相关，在超长上下文场景下会产生大量元信息。

L2架构的测试表现

测试环境

• 推理节点：4个，单节点含8张NVIDIA H800（80G VRAM）、8块200G网卡（ETH/RoCE）、64Core/1T RAM；
• 存储节点：2个，单节点含4块4T NVMe、8块200G网卡（ETH/RoCE）；
• 测试条件：模型为Qwen3-14B，输入5k-15k random token，输出1K * 8轮，32个推理实例共享GD2FS存储后端，采用无状态化推理。

核心性能表现

• 性能提升：在相近的首次令牌输出时间（TTFT）和Token输出时间（TPOT）指标下，所需资源约为非共享实例的三分之二。
• 动态扩缩容：16个推理引擎提供服务时，流量上涨后，平均TPOT、P95 TPOT指标会出现下降；基于DNS执行扩容后，性能可在分钟级恢复，弹性伸缩能力优异。
• 故障恢复：多次故障事件测试显示，架构具备快速恢复能力，能有效保障服务稳定性。
• 核心指标：TTFT、AVG TPOT、Max TPOT、P95 TPOT均达到预期标准，可满足LLM推理的低延迟需求。