ExaServe：256节点3072副本，超算级LLM部署方案首次公开

现在大语言模型已经广泛融入各类科研计算工作流，从文献挖掘、智能体引导实验，到带评估环节的训练、交互式分析，单次任务往往要发起上千次推理请求。

不少科研人员都希望能在本地的超算中心部署开源或自定义微调的模型，既可以将敏感数据留在超算内部避免合规风险，又能直接复用超算的算力资源，还能匹配现有项目的资源分配规则。

但当前主流的云原生大语言模型服务框架，在适配顶级超算的架构时往往会遇到诸多工程难题，需要额外处理调度器对接、MPI启动、加速器选择、节点本地权重加载、平台专属补丁适配等一系列问题。

论文标题：ExaServe: Large-Scale LLM Serving on Exascale HPC Systems

论文链接：https://arxiv.org/pdf/2609.10812

研究背景

当前大语言模型服务和超算的技术栈是沿着两条不同的路径发展而来的。超算系统围绕批量调度、MPI启动、共享并行文件系统设计，核心负载是紧耦合的仿真任务，而非长生命周期的请求驱动服务。而vLLM、SGLang、Ray Serve等现代服务框架，都是为云场景的弹性伸缩设计，默认依赖Kubernetes风格的控制平面和外部负载均衡，这些组件在超算的批量资源分配环境中往往无法直接使用，也没有提供开箱即用的跨节点模型部署方案。

而且不同超算的软硬件配置存在明显异构性，调度器有Slurm、Flux、PBS等多种类型，计算加速卡覆盖NVIDIA、AMD、Intel等不同厂商的产品，现有的服务框架很难直接适配这类异构环境，导致科研人员要在超算上部署大规模大语言模型服务需要付出极高的适配成本。

ExaServe的核心设计

为了解决上述适配问题，来自芝加哥大学和阿贡国家实验室的研究团队开发了ExaServe，这是一个可以通过pip直接安装的框架，用户只需要编写一份声明式的YAML配置文件，框架就能自动生成适配超算环境的可复现大规模大语言模型服务部署方案。

ExaServe的架构围绕六个核心组件设计，覆盖了在超算批量分配资源内部署大语言模型端点的全流程：

• 批量作业渲染组件会读取配置生成对应超算调度器的提交脚本，自动完成资源分配、环境加载、MPI启动等流程；
• 模型分发组件会在头节点读取一次模型权重，通过MPI广播到所有计算节点的本地存储，避免所有节点同时读取共享文件系统导致的元数据服务器压力；
• 服务运行时组件会在每个节点启动Ray Serve应用，根据配置的张量并行、流水线并行参数自动规划副本放置策略，将推理引擎副本绑定到对应的加速卡上；
• 前端代理组件会在所有节点的服务就绪后，在头节点启动统一的对外服务端点，将请求路由到不同节点的副本；
• 测量插桩组件可以在不重新编译Ray的前提下，在Ray Serve控制器、代理、部署状态边界插入计时探针，方便性能排查；
• 站点兼容补丁层会在加载Ray或推理引擎前应用适配补丁，解决不同超算的软硬件适配问题。

针对参数规模较大、需要跨节点部署的大模型，ExaServe还设计了分片感知的流水线并行机制，只给每个节点分发它需要运行的流水线阶段对应的权重分片，避免节点本地存储无法容纳完整大模型权重的问题，同时通过统一的入口路由屏蔽多副本部署的差异，用户访问时和单副本部署的体验完全一致。

为了解决现有框架默认配置不适合超算大规模部署的问题，ExaServe设计了两层补丁系统：第一层是引擎无关的补丁，通过MPI广播替换Ray Serve的部分配置文件，将代理超时、健康检查阈值等云场景默认参数调大1到2个数量级，避免控制器误杀正常运行的代理进程；第二层是针对推理引擎和硬件的补丁，解决vLLM的XPU适配、分词器线程池大小设置等问题，所有补丁都可以通过环境变量独立开关，方便适配不同的超算环境。

大规模部署性能表现

研究团队在阿贡国家实验室的Aurora超算上对ExaServe做了全面的性能测试，测试覆盖从1节点到256节点的规模，最多可同时运行3072个vLLM副本。

首先是集群启动性能，研究团队发现Ray Serve的控制平面存在O(N²)的性能瓶颈：控制器会把每个新副本的信息以名称而非句柄的形式通知到所有节点的代理，每个代理都要通过GCS（Ray的头节点元数据服务）查询所有副本的信息，随着节点规模扩大，查询量会呈平方级增长。256节点部署时，仅服务启动阶段就需要约30分钟，当规模扩大到512节点时，GCS会被大量的RPC请求占满，导致集群启动失败。

稳态服务的性能表现则分为两种不同的情况：非流式推理的吞吐量几乎可以线性扩展到256节点，单头节点部署HAProxy作为代理时，最高可以达到27.1k请求每秒，也就是3.8M词元每秒，全程零错误，和无代理的直接分发模式性能完全一致，说明代理层不会给非流式推理带来额外的性能损耗。

而流式推理的表现则完全不同，使用集中式代理时，吞吐量到约4.7k请求每秒就会达到瓶颈不再增长，256节点时SLO达标率几乎为0，但此时模型服务本身的性能仍然符合SLO要求，服务端首包时间仅为66ms，99分位词元间隔仅为28ms，性能瓶颈来自于集中式代理节点的网络IO，接近20万条SSE连接同时汇聚到头节点，导致TCP重传率大幅升高，而此时代理的CPU使用率还不到2%。如果改用无代理的节点级直接分发模式，256节点下流式推理的吞吐量可以达到18.1k请求每秒，SLO达标率为100%。

研究团队还对不同工作负载、不同模型、不同推理引擎的表现做了测试：长上下文、代码生成、聊天、摘要等低负载场景下，SLO达标率从单节点到64节点几乎没有下降；405B参数的大模型通过分片感知的流水线并行部署，也能实现接近线性的扩展；使用SGLang作为推理引擎时，缩放规律和vLLM完全一致，只是单节点吞吐量较低，集中式代理仍然是共同的性能瓶颈。

超算部署大语言模型服务的最佳实践

基于全面的性能测试，研究团队也总结出了一套超算部署大语言模型服务的最佳实践。如果只需要对外暴露一个统一的服务端点，选择在头节点部署HAProxy并使用最小连接负载均衡策略是最优方案，256节点下非流式推理可以跑满硬件性能且全程零错误。如果是大规模流式推理场景，不建议使用集中式代理，应该采用分布式的节点级服务端点，256节点下可以达到18.1k请求每秒的吞吐量，且SLO达标率为100%。

集群启动阶段，建议通过MPI广播将模型权重分发到节点本地存储，避免所有节点同时读取共享文件系统，仅这一项优化就能为256节点的Llama-3-8B部署减少超过10分钟的启动时间。128节点以上的部署需要应用补丁层的超时配置，避免Ray Serve的健康检查误杀正常的代理进程，同时要限制分词器的线程池大小，避免出现线程耗尽的问题。

性能测试阶段需要使用分布式的压测客户端，集中式客户端会存在CPU和端口上限，最多只能达到线性扩展性能的一半。Ray集群的规模建议控制在256节点以内，更大规模的部署需要使用GCS分片或者多个独立的Ray集群，避免控制平面成为性能瓶颈。

总结

ExaServe为在批量调度的超算系统上部署Ray Serve大语言模型推理服务提供了可复现的部署路径，解决了不同超算环境的适配难题，同时也暴露了当前大语言模型服务框架的两个核心架构瓶颈：集中式的词元分发机制和Ray Serve的集中式控制平面，这两个瓶颈也是未来百亿亿次AI系统需要解决的关键问题。对于需要在超算上部署大规模大语言模型服务的科研人员来说，ExaServe不仅提供了开箱即用的落地方案，其总结的最佳实践也能帮助用户避开不少部署过程中的坑。