面向GPU集群的无状态LLM推理架构演进

在AI大模型浪潮席卷各行各业的当下，大语言模型（LLM）推理的性能、扩展性与资源利用率，已成为企业落地过程中的核心痛点。回顾互联网后端架构的演进历程，我们不难发现，“无状态化”始终是破解大规模分布式部署难题的关键思路。今天，我们就来探讨如何将这一成熟思路迁移至GPU集群场景，探索无状态LLM推理架构的演进与落地之路。

互联网后端架构的演进脉络

互联网后端架构的演进，是一部与业务规模共成长、与技术革新同频共振的迭代史。从早期应对简单交互的单体架构，到支撑海量并发的分布式架构，再到云原生时代的弹性架构，每一步升级都围绕“更高效、更稳定、更低成本”的核心目标展开。在这一漫长演进历程中，“无状态化”理念从萌芽逐步走向成熟，最终成为破解大规模部署难题的关键抓手。梳理这段脉络，不仅能清晰洞察技术迭代的内在逻辑，更能为当下AI场景的架构创新提供宝贵借鉴。接下来，我们将按时间维度，拆解互联网后端架构的四次关键演进跃迁。

1. 2000-2005年：LAMP黄金时代的单体困境

这一时期的互联网应用以静态页面与简单动态交互为主，业务复杂度较低，基于Linux、Apache、MySQL、PHP/Perl/Python组成的LAMP开源技术栈成为绝对主流，这一术语最早由德国计算机杂志作者Michael Kunze在1998年提出，随后被O'Reilly等机构推广普及，成为开源软件对抗商业软件的重要代表。LAMP架构的核心特点是“单体架构+共享一切”——应用代码、静态文件与数据库集中部署在少数几台物理服务器上，采用同步阻塞的运行模型，开发门槛低、部署简单的优势使其快速覆盖中小企业场景。

但随着互联网用户规模初步增长，该架构的性能瓶颈愈发凸显，典型问题便是C10K（一万并发连接）挑战——单台服务器的处理能力根本无法支撑大规模并发请求。此时的扩展方式以垂直扩展为主，即通过提升单台服务器的CPU、内存等硬件配置应对压力；水平扩展仅能通过HAProxy、硬件F5等负载均衡设备实现有限支持，且需手动配置服务器参数，扩展性与运维效率极差。这一阶段尚无明确的“无状态”概念，服务与状态深度耦合，一旦服务器宕机，极易导致数据丢失与服务中断。

2. 2005-2010年：分布式转型与无状态萌芽

随着电商、社交等复杂互联网业务崛起，用户规模与数据量呈爆发式增长，LAMP单体架构的局限性彻底暴露，后端栈开始向分布式、专业化方向演进。这一阶段的核心变革是“解耦”：数据库层率先实现读写分离，通过“一主多从”架构分摊读压力，同时分库分表技术解决数据量激增问题；缓存层崛起，Memcached、Redis等工具将热点数据加载至内存，大幅降低数据库访问压力；Nginx以其高性能、高并发的优势取代Apache成为主流Web服务器，配合LVS等四层负载均衡形成多级负载分发体系。

AWS等云服务厂商的出现，推动虚拟化技术加速落地，让服务器资源调度更灵活，为水平扩展奠定了基础支撑。正是在这一背景下，“服务无状态化”理念开始萌芽：开发者逐步将用户会话、业务配置等状态数据从服务实例中剥离，统一卸载至缓存或数据库，使服务本身成为无状态组件。这种设计让新增服务实例无需同步历史状态，可直接接入集群承担负载，大幅提升了水平扩展能力；而异步消息队列的应用，进一步解决了分布式环境下的通信与解耦问题，为大规模部署提供了关键保障。

3. 2010-2020年：Docker与K8s引领的无状态成熟时代

2010年后，互联网业务进入精细化运营阶段，多环境部署不一致、服务扩容效率低、资源利用率不足等新矛盾凸显，Docker的出现打破了这一僵局。Docker通过容器化技术将应用及其依赖环境打包为统一镜像，实现“构建一次，处处运行”的特性，Dockerfile则标准化了镜像构建流程，从根本上解决了环境一致性问题。随后，Kubernetes（K8s）从众多容器编排系统中脱颖而出，通过自动化调度、弹性伸缩、故障自愈等核心能力，解决了大规模容器集群的管理难题，将无状态架构推向全面成熟阶段。

伴随云原生生态持续完善，无状态架构的支撑体系愈发健全：coreDNS/consul实现服务发现自动化，Service Mesh将服务治理逻辑与业务代码解耦，负责流量控制、熔断降级等复杂运维能力，Prometheus+Grafana则构建起完善的可观测性体系，实现指标监控、日志收集与告警预警全覆盖。值得注意的是，K8s并非强制要求所有服务无状态，而是通过Deployment支持无状态服务高效部署，同时借助StatefulSet、PVC/PV等机制适配数据库、消息队列等有状态服务，形成“无状态为主、有状态适配”的合理架构模式。这一阶段，无状态化成为云原生架构的核心准则，弹性、可靠性等非功能性需求被下沉至基础设施层，让业务开发者可专注于核心逻辑开发，大幅提升研发效率。

K8s的核心优势恰好契合无状态架构的需求：通过DNS/IP实现服务发现与负载均衡，支持手动或自动水平扩缩容，具备灵活的存储编排能力，可实现容器的自动部署、回滚与智能装箱，甚至能通过插件扩展为基于GPU/HBM的调度，为后续AI场景的架构迁移埋下伏笔。

4. 2020-2025年：弹性计算和极致的成本

进入2020年后，互联网行业竞争迈入精细化运营阶段，成本控制成为企业核心竞争力之一，无状态架构的演进重心也随之转向“弹性计算深化与成本极致优化”。在线业务普遍存在天然的潮汐现象——例如电商促销大促、社交平台早晚高峰、视频平台晚间黄金档等场景，业务高峰期与低谷期的资源使用率差距显著，传统“按峰值配置资源”的模式导致大量资源闲置，成本浪费问题突出。

基于K8s成熟的弹性扩缩容能力，业界普遍落地了在线业务与离线业务的混合部署方案，实现资源的动态调度与高效复用。其核心逻辑是：通过K8s的优先级调度、资源配额等机制，为在线业务设置更高优先级，确保其性能不受影响；在在线业务波谷期，将闲置的计算资源动态出让给离线业务（如大数据分析、模型训练、日志处理等对实时性要求较低的任务）；而在波峰到来前，通过预设的弹性策略触发离线业务自动释放资源，将资源完整交还给在线业务。这种模式大幅提升了资源利用率，部分企业的集群资源利用率从传统的30%-40%提升至80%以上，显著降低了硬件采购与运维成本。

更进阶的实践是将资源复用与云计算商业模式深度结合：部分拥有大规模集群的企业或云厂商，会在在线业务波谷期将出让的闲置计算资源接入云计算平台，以“弹性算力”“竞价实例”等形式对外售卖，将闲置资源转化为实际收益。这一模式进一步推动弹性计算能力向更广泛的业务领域延伸。

AI场景下的资源与架构变革

当无状态架构在传统互联网后端大放异彩时，AI场景的崛起带来了全新挑战。与传统业务相比，AI场景下计算机求解问题的三要素发生了根本性变化：

资源维度：计算核心从CPU转向GPU，存储采用更快的NVMe设备与GPFS，网络升级为200Gbps/400Gbps高速网络并大规模应用RDMA；

数据维度：数据量从KB、MB级跃升至GB、TB级，对存储与传输能力提出更高要求；

程序维度：传统逻辑运算转变为模型的数据运算，计算密集型特征显著。

1. 计算能力的量级差异

CPU与GPU的计算性能差距悬殊。以AMD EPYC 9654 CPU和NVIDIA H100 SXM GPU为例，前者缺乏专用AI算力，FP64 FLOPS仅约1.42 TFLOPS；而后者AI算力（FP8）高达3958 TFLOPS，FP64和FP32 FLOPS也分别达到34 TFLOPS、67 TFLOPS。通常一台CPU服务器含2个NUMA节点，而一台GPU服务器可搭载8块GPU，单台服务器的计算性能相差多个数量级。在当前LLM业务模型下，数据中心的算力需求已向GPU/NPU大幅倾斜。

2. 存储设备的性能层级

AI场景的存储设备依然遵循“速度越快、容量越小、成本越高”的层级分布规律，从吞吐、延迟、容量三个核心指标来看具体差异如下：

GPU显存：吞吐可达16TB/s（8块GPU，单块2TB/s），延迟仅100+ns，但总容量有限（768G，8块×96G）；

DDR5内存：吞吐约300-600GB/s，延迟80+ns，容量1-2T，作为GPU显存的补充；

网卡：400Gbps×4配置下吞吐200GB/s，RDMA延迟约2us，是分布式通信的核心；

NVMe硬盘：4卡配置下，读吞吐达24GB/s（6GB/s×4）、写吞吐8GB/s（2GB/s×4），延迟20-80us，容量可达16T（4T×4），负责大容量及持久化数据存储。

3. 现有LLM推理优化方案的局限

为应对GPU显存瓶颈，业界涌现出vLLM、sglang等优化框架，核心思路均围绕页式显存管理与Host Offload（显存数据换入换出）展开：

vLLM的PagedAttention：将GPU物理显存划分为固定大小的物理块，通过逻辑块与块表维护映射关系，利用DDR作为交换介质；

sglang的RadixAttention：引入前缀缓存池维护Prompt到KV Cache的全局映射，采用分层缓存设计，同样依赖DDR作为交换介质，0.53版本后支持外部存储，但数据路径需经过本地DDR。

这些方案虽提升了显存利用率，却未实现真正的无状态化——KV Cache作为核心状态数据仍依赖本地或近邻节点存储，直接限制了GPU集群的弹性扩展能力。具体可通过多轮对话场景直观理解：某用户的多轮对话KV Cache存储在服务器A的缓存中，当下一轮会话请求发起时，若负载均衡将请求继续路由至服务器A，即可实现缓存命中，直接复用已有KV Cache；但如果请求被路由到其他服务器，就会出现缓存未命中，需重新进行预填充计算生成KV Cache。从当前主流MaaS（模型即服务）厂商的定价逻辑来看，缓存命中与未命中的服务成本相差高达十倍，这无疑会显著增加企业的LLM推理运营成本。

同时，为提升KV Cache命中率，现有方案还需在服务路由阶段感知KV Cache的分布情况，针对性地将请求路由到存储对应缓存的服务器。这种路由策略不仅会额外增加调度复杂度，还需预留缓存空间以避免冲突，导致服务器往往无法满负载运行，进一步降低了资源利用率。

无状态LLM推理架构的核心探索

实现无状态LLM推理的核心前提，是让推理过程中的核心状态能够高效Offload（卸载）至远端存储。在LLM推理场景中，核心状态即为KV Cache，单个会话的KV Cache大小通常在几百MB到几GB之间，其卸载延迟直接决定无状态架构能否满足实时推理需求。然而，传统Redis/Valkey等KV存储方案存在明显局限：一方面单个KV存储容量最大仅支持512MB，无法适配GB级KV Cache的存储需求；另一方面性能不足，64MB数据的存储延迟就高达约100ms，远超实时推理的可接受范围。基于此，我们（张量跃迁）需从传输协议、缓存设计、调度策略三个核心维度，构建一套适配LLM推理场景的全新技术体系，突破传统方案的瓶颈。

1. GD2FS：高性能分布式传输协议基石

GD2FS（GPU Direct Distributed File System）是无状态架构的核心传输协议，其设计理念是深度融合GPU加速与高速网络能力，支持GPU Direct RDMA——通过GPU与网卡的直接通信跳过CPU中转，实现数据高效传输，从底层降低KV Cache Offload的延迟；同时兼容TCP多网卡、多流并发模式，提升部署灵活性。

2. 高性能缓存设计：提升数据访问效率

GD2FS引擎采用了一系列优化的缓存设计策略：

用户态内存管理：支持Hugetlbfs的匿名映射与文件映射，避免系统颠簸；实现Zero Copy（零拷贝），提升传输效率。结合前文提及的AI场景存储性能层级可知，DDR5内存与RDMA网卡之间的带宽已无明显倍数关系，在AI workload下，任何一次不必要的内存复制都会带来显著延迟开销，甚至造成性能瓶颈，这种影响堪称“灾难性”。

灵活的缓存策略：支持分布式FADV-WILLNEED（预读数据到缓存）与FADV-DONTNEED（精确释放缓存），可根据业务需求自定义缓存淘汰规则。同时，GD2FS引擎还支持基于LRU（最近最少使用）的缓存淘汰策略，能够智能筛选并保留高频访问的KV Cache数据，释放低频数据占用的缓存空间，进一步提升缓存资源的利用率，极大保证了数据传输的高性能。

从FIO性能测试数据来看，GD2FS优势显著：在400G网卡的RDMA模式下，GPU与GD2FS集群的64M数据读取延迟仅1.6ms，1G数据读取延迟25ms；即使在TCP模式下，DDR与GD2FS集群的64M数据读取延迟也仅5ms，1G数据读取延迟70ms，性能远优于传统KV存储。

正是凭借这样的高性能表现，GD2FS的传输速度足以满足AI场景下KV Cache状态卸载的严苛需求，这也从根本上让LLM推理服务具备了无状态化部署的可能，为后续架构落地验证奠定了核心技术基础。

基于K8s的LLM无状态推理

结合GD2FS高性能存储能力和K8s的容器编排能力，无状态LLM推理架构的部署方案已进入开发验证阶段。为验证架构可行性与性能优势，我们（张量跃迁）搭建了对比测试环境并完成测试，核心架构与测试细节如下：

本次测试设计了两种拓扑方案，分别验证无GD2FS分布式缓存与有GD2FS分布式缓存场景下的性能差异，具体拓扑结构如下：

// topoA（无GD2FS分布式缓存）
          +---------+         
          |benchmark|         
          +---------+         
              |               
    ----------+-----------    
   /      /       \       \   
+----+  +----+  +----+  +----+
|SGL0|  |SGL1|  |SGL2|  |SGL3|
+----+  +----+  +----+  +----+

// topoB（含GD2FS分布式缓存）
          +---------+           
          |benchmark|
          +---------+
              |
    ----------+-----------
   /      /       \       \
+----+  +----+  +----+  +----+ 
|SGL0|  |SGL1|  |SGL2|  |SGL3|
+----+  +----+  +----+  +----+
   \      \       /       /
    +---------+----------+
              |
    +--------------------+
    |   GD2FS Cluster    |
    +--------------------+

其中，topoA为基础对照方案，4个SGLang实例独立运行，无共享缓存；topoB为目标方案，4个SGLang实例通过GD2FS分布式集群实现KV缓存共享，这也是无状态LLM推理架构的核心验证场景。

topoB的核心创新点在于通过GD2FS分布式集群实现了SGLang实例间的KV缓存共享，使多轮会话过程中KV缓存命中率达到100%。这一机制从根源上消除了预填充重计算的开销，同时大幅降低了对TPOT（Time to First Token，首Token生成时间）的影响，完美契合无状态架构“状态高效共享、弹性扩展不损失性能”的核心目标。

对比topoA与topoB的测试数据，无状态架构（topoB）在核心性能指标上实现全面提升，具体结果如下：

QPS提升：topoB性能提升至原来的150%，并发处理能力显著增强；

TTFT（Time to First Token）优化：非首轮TTFT平均延迟降至topoA的50%，P95延迟降至40%，用户交互体验大幅改善；

TPOT（Time Per Output Token）优化：平均延迟降至topoA的75%，最大延迟更是降至20%，输出稳定性与效率双重提升。

需要注意的是，本次测试过程中，为实现SGLang实例与GD2FS分布式集群的适配，我们对sglang进行了相应改造。目前，这部分改造代码已在向sglang社区贡献中，测试所用数据集及相关工具也已同步提交至对应PR，具体可查看：https://github.com/sgl-project/sglang/pull/14994。

最后

全文梳理可见，从传统互联网后端的无状态演进，到AI场景下GPU集群推理的架构革新，每一次技术迭代都源于业务需求的驱动，以及行业对效率、成本的极致追求。当前，LLM推理架构正处于高速发展的黄金时期，技术探索方向百花齐放。

无状态化推理凭借弹性扩展、资源高效复用、成本优化等核心优势，为大规模LLM推理部署提供了极具潜力的解决方案，成为未来的重要发展可能之一。但行业的进步从不依赖单一技术的独领风骚，百花齐放才是春。相信在多元技术路径的碰撞与融合中，LLM推理架构将持续突破性能与成本的边界，更好地支撑AI技术在各行业的深度落地，绽放更大的产业价值。