AICon上海演讲精华回顾：《GMI Cloud 全球化高性能分布式推理服务构建实践》

AI 应用全球化浪潮下，推理效率与算力供给成为破局关键。AICon2025 上海站，GMI Cloud 资深架构师 Frank Lee 登台演讲，在题为《GMI Cloud 全球化高性能分布式推理服务构建实践》的分享中以 GMI Cloud Inference Engine 为锚点，拆解其高并发、低延迟、动态扩缩容能力如何支撑全球 AI 业务爆发，深度分享 GMI Cloud 自研推理平台的架构设计、跨区域合规部署及软硬协同优化实践，揭秘其实现推理成本、指数级效率提升的关键路径。

1 快速认识一下 GMI Cloud

我们是一家全球化 AI Native Cloud 服务商，主要为全球 AI 应用提供高性能的 GPU 云服务。我们是英伟达全球 Top10 的 NCP，这就使得我们在英伟达最新 GPU 资源的获取上有一些优势。我们在亚太区有优先的 GPU 分配权，能稳定地拿到英伟达最优芯片。

同时我们的产品基于 GPU 集群对外提供 IaaS 层和 MaaS 层的服务。IaaS 层是以 GPU 计算为核心的计算、存储、网络三大件，其中计算部分的核心是以 GPU 为主的，形态主要以云上裸金属，GPU、云容器，还有云上托管的 K8s 集群为主。MaaS 层我们提供两种类型的服务，一种类型针对自有模型客户，他们有模型部署需求的，我们会提供推理平台，给客户提供一系列推理优化能力；另外一种是提供我们集成的开源最新最强的模型，这样的模型会以 API 调用的服务来提供给客户，这就是我们的业务整体构成。

我们现在在全球总共有 10 多个可用区，主要集中在北美和亚太区，欧洲也有少量节点，北美和亚和亚太这两个区里我们中国的 AI 出海企业比较集中，也是他们的用户量和收入比较多的地方。亚太部分最近比较火的有新加坡和日本，是非常热的热点。

2 AI 应用全球化爆发的趋势与挑战

接下来我分享一下我们看到的一些关于 AI 应用及中国 AI 应用出海的趋势，以及他们面对的在推理服务部署方面所遇到的一些问题。

首先我们看一下全球整体情况，这里有个数据统计了过去一年，全球 AI 应用的总访问量趋势。我们可以看到从访问量上来说，数据从去年 1 月开始差不多是 36 亿，到去年 12 月底到了 76 亿，基本上翻倍的增长，从收入和下载量来说也是有比较大的增长。

图片

这个数据目前只统计到了去年 12 月，如果再统计到今年的 1~4 月，数据的增长应该会更高一些。也是因为 DeepSeek 在春节期间的出圈，把 AI 整体的渗透率提升了很多，像春节期间家里的长辈都在使用 AI 产品了。

所以整个 AI 应用的部分从去年开始加速爆发，我们作为 GPU 云服务商来说，从今年开始接到了很多客户的需求都以推理为主，以应用客户为主，训练的部分明显减少了。

我们再来看中国 AI 出海的情况，这里也有数据，就是中国规模以上 AI 产品的数量大概在 300 多个，其中出海 AI 产品在 156 个，是截止 4 月份的数据。所谓规模以上就是月活在 5 万以上的的应用。

图片

这个数据在去年 1 月份时是 35 个，也就是说在上个月时已经增长到了 156 个，300% 以上的增长。同时过去两三个月，每个月基本上是以 10~20 个的数据再增长，所以中国出海产品数量和用户规模都在不断增大，这也说明海外 AI 推理的算力需求将会不断增大，算力需求的持续供应在 25 年会是比较重点的事情。

图片

这是中国 AI 出海比较头部的一些 APP 的下载量和收入按地区分配的情况。通过这个图我们可以得出几个结论，第一个结论是中国出海的这些 AI 应用，不是被某特定区域的用户使用，而是广泛的全球化用户在使用，但它会有一些侧重点。从下载量和收入上来说，它们的分布会有一些差异，比如从下载量上我们可以看到很多应用在印度的下载量比较大，但从付费情况来说是北美，具体是指美国的付费占比比较大。另外日本的付费比例也比较大，所以北美和日本这两个区域是出海的首选。

我们在过去 2~3 个月里经常会在社交平台上看到某个 AI 应用突然爆火，在朋友圈里刷屏，在短视频里到处都是，但我们一旦要使用它的时候，就会发现要么进入等待清单，要么就是服务繁忙的状态。这和 AI 应用整体的服务的能力，特别是算力服务能力跟不上有很大关系。所以如果我们能提供比较充足的算力服务，并且能及时扩容，对这些突然爆火的 AI 应用获得比较初始的用户规模，以及后续的用户留存也是非常关键的。

总结下来，在现在 AI 应用全球化增长的趋势下，如果要构建比较及时稳定的推理服务，主要面临几个问题。

图片

第一个问题是现在出海应用覆盖的区域比较广，所以它的推理服务也要覆盖各个区域。第二个是它的用户规模在不断增长，需要构建适应用户增长的推理服务，具备自动扩容的能力，以便及时接住这些突发流量。第三，在有限的资源情况下，需要优化推理服务的性能，以获得更好的 SLO 水平去服务用户。最后一个是比较老生常谈的问题，就是如何保证服务的稳定性。

3 GMI Cloud 高效稳定的推理服务架构解析

接下来介绍一下我们 GMI Cloud 在帮助用户构建这些推理服务时的一些实践经验。

图片

我们今年服务的大多数客户主要是推理需求的客户，我们也有这样的推理平台满足他的需求。推理平台是构建在我们整个 GMI Cloud 的云平台之上，我们会在这个平台上做一些帮助用户快速部署推理服务，提供稳定的服务以及推理性能优化的一些工作，并且把它逐步产品化，对外提供服务。

首先给大家分享我们在推理服务自动扩缩容方面的一些实践。自动扩缩容这个事情下面有三个子命题，分别是负载均衡、扩容的策略和冷启动。

关于扩容，是说在现有的资源、服务水平下，怎么让现有资源能够更均衡地对外提供服务，不会变成有的资源负载很高，有的负载很低，造成资源利用率不高的情况。

关于负载均衡，现在至少在语言模型方面，比较流行的是在 PD 分离的架构下做负载均衡。PD 分离架构下，P 负载和 D 负载是分开做负载感知和负载均衡的，相对来说 P 负载的均衡会比较容易一些，因为它基本上相当于无状态的处理过程。所以我们基本上是直接基于它的负载水平来做调度，就是调度到负载较低的 worker 上，同时也会做一些动态调度，比如说我们会把用户的 input 按照长度分成不同类型，调度在不同的 P worker 分区里。

D worker 的负载均衡相对复杂一些，因为它混合了 kv cache 的命中问题，所以这一块我们也做了一些比较细致的工作，也会参照一些行业现在开源的最佳实践。第一点，它的核心目标是我把 decoder 的任务调度在距离 kv cahce 命中率更高，并且负载更低的 worker 上。细节的部分，我们会做一些比如基于 prompt hash 或 input token ID 的前缀匹配的一些计算，去计算整个 kv cache 的命中得分，根据得分加上 GPU 负载，以及现在的队列长度去做综合权重得分，根据得分去匹配最高得分的 worker。

还有一些场景，比如说现在我们接触比较多的，像陪聊、拟人对话这样的场景，它的特点就是多轮对话。多轮对话的轮次非常长，并且对于对话中上下文的保持要求比较高，这时就会导致如果要使用上面提到这种调度，有可能会出现一些上下文缺失的情况。所以这种情况我们也给客户提供一些策略，就是基于 SessionID 的的保持，就是粘性调度的形式，同一个 SessionID 在同一个 D worker 上处理。

一旦整体负载都过高后就要扩容。扩容首先要涉及扩容策略的问题，什么时候扩容，以及扩容的条件要怎么设置？这个部分目前我们做了线性条件扩容的方法，会把所有集群的 worker 负载，以及现在的 SLO 水平，包括首次延迟、整体吞吐，以及整体的用户请求队列长度等，把这些指标全部收集起来后给客户调度编排器。编排器里面是线性条件的组合，当某一个条件和某一个条件达到一定水平，就选择扩容或缩容，并判断缩容和扩容的的副本数量是多少。

但我们现在也在同客户研究一些非线性方法，比如基于整体集群的数据以及客户未来流量的数据做一些预测，看这样的预测时机和这种条件触发的形式，哪一个会更准一些，对资源的利用率会更高一些。

一旦扩容条件触发后，还会涉及到一个问题就是扩容的服务副本怎样能够更快速上线，也就是冷启动如何做加速。这一块核心的瓶颈主要是两个，第一个是模型加载。我们知道大模型的模型权重一般小的几十 G，大的有几百 G，所以一般在云上用推理服务时，会去从远端对象存储下载模型，再加载的 GPU 实例里，再做推理服务，整个过程可能会耗时十几分钟。我们作为专门提供 GPU 云服务的厂商来说在这里会相对有一定优势，比较简单粗暴的方法就是给每 GPU 的集群配备高速文件存储，通过 RDMA 的形式和 GPU 集群相连，这样就从本地高级高速文件存储直接进到 GPU 显存，上百 G 的文件几秒钟就加载完了。同时，关于Runtime 初始化这部分，GMI Cloud 也会做一些提前优化，包括模型执行图的预编译， kv 缓存的预分配和通信结构复用的一些操作，总之就是一旦扩容条件触发后，我们去扩容新的副本时，能够在分钟级扩容起来提供服务。

另外，还有一些跨集群跨地区的自动扩容问题。大家都知道，很多客户的服务是多区域的，所以它的推理集群一般会分布在不同地方，大多都是会跨地区的。比如说有的在北美，有的在东南亚，这时我们也要去做整体多集群的负载均衡和自动扩容。

图片

第一层面的负载均衡是不同地区的负载均衡，GMI Cloud 是和 CDN 厂商合作，让本地用户访问本地集群获得推理服务。同时基于所有收集到的推理负载数据，我们按照上面的逻辑去做单个集群的负载均衡。自动扩容的编排计划也可以按照集群维度单独定制扩容计划。

还有一点，现在 PD 分离相关的技术比较火热，很多大模型的推理，如果要节省推理成本，实现所谓的工业红线，能够提供推理服务赚钱，这一步目前看是少不了的。但 PD 分离这个技术和场景是强相关的，不同场景的 input 和 output 的长度也不太相同，所以这一点要根据场景做很多定制和适配，我们有一些实践经验可以给大家分享一下。

第一点就是什么场景下适合做 PD 分离推理，什么场景下适合做 PD 融合的？目前看来，因为 AI 应用客户所使用的模型尺寸越来越小，大多数都是 10b 左右。这个时候就要看场景，有一些场景比如说很多 Agent 类的应用会拿一些小模型首先做意图识别或者是做 function calling 工具调用。这部分的 input 长度不会特别长，并且调用的频次也比较低，单卡就能放得下推理，去做 PD 分离需要更多资源，这个时候就不太划算了。

但有一些场景，比如说陪聊拟人对话的用户访问请求比较密集，调用频次较高，同时它由于多轮对话导致上下文比较长。还有一些 RAG 场景的 input 是特别长的，这时如果 PD 融合推理，prefill 会挤占 decode 资源，导致推理性能较差，所以这些场景是比较适合 PD 分离的。另外就是大尺寸模型，比如说 DeepSeek R1、V3 模型比较适合做 PD 分离。

PD 分离还涉及到 P 和 D 的比例问题，这个部分我们也自己做了一些实验，根据我们所接触到的一些客户场景所得到的经验数据给大家分享一下。

像通用性聊天用户，输入可能会比较短， input 在 512 token 以下的， P 和 D 的比例适合在 1:1。还有稍微长一点的输入场景，prompt 在 1k 以上，这时 prefill 的资源会加多一些， P 和 D 的比例在 2:1 比较合适。还有 RAG 的 input 都是特别长的，可能要几千甚至上万 token，这时 prefill 比例会更大一些，4:1 比较合适。还有一些比较特殊的场景，对于首词延迟要求比较高，要保证整体的服务流畅性，这时 decode 的比例多一点比较好。

有时候客户的资源并不是那么多，特别是创业公司的预算也比较有限，这时由于整个场景在动态变化，P 和 D 的比例也在变化，这时我们也也和客户一起合作，看怎样实现 P 和 D 的快速在线转换。还有一点是关于 kv 缓存池的问题，目前我们主要以 HBM 显存作为缓存核心。当整体场景比较大时，我们也会使用本机内存和本地的 SSD 硬盘来做整体的统一缓存池的管理，在 kv 命中算法和手段不变的情况下增大缓存池大小，能够非常有效地提升缓存命中。目前来看，把本地内存和 NvMe SSD 都利用上的话，把缓存命中率提升 50% 以上是比较容易的。

另外一个事情就是我们观察到很多 AI 应用，它在持续服务过程中的用户输入，我们观察到有 2/8 比例的现象，就是 20% 的 prompt 会被 80% 的用户输入，有一些高频 prompt 存在。这时我们也会做动作，对用户输入的 prompt 做一些频次统计，把高频的 20% prompt 统计出来，把这部分的 kv cache 持久化存储下来。这样处理推理请求时，就可以先做哈希比对，如果直接命中了，直接去从持久化存储里取这些 kv 就省去了前面的 prefill 阶段。

图片

目前 PD 分离的的技术基本上只能做到单集群内，因为 PD 之间的通信对通信网络的要求非常高。我们也是这样，但基于 kv 的持久化存储可以跨集群分享。虽说它服务的是不同地区的客户，用户的输入还是有比较高的相似度的，这时某集群的高频 prompt 的 kv 共享给另外的集群，也能提升另外一个集群的整体资源处理效率。

图片

另外我们在服务客户的过程中发现比较有趣的事情，就是我们在软件的层面去做 GPU 推理性能优化，做了很多工作，但是往往英伟达只要发一款新的 GPU，可能新的 GPU 所带来的性能优化效率，比在软件上做的性能优化效率要高很多。这是英伟达 3 月份发的数据，他们用 DeepSeek-FP4 的版本在 H200 和 B200 上跑了一下，可以看到在 B200 上跑的数据是在 H200 上跑的 25 倍以上，而现在 B200 的价格基本上是 H200 的价格两倍不到，所以性价比是极高的。

这个 FP4 的版本，他们也在 MMLU 上做了评测，相对于 FP8 的版本有 99% 得分，基本上没有什么性能折损。所以说尽快获取最新的 GPU 来做推理服务，可能是性价比最高最快的路径。

我们也是少有的现在能够拿到实际的 B200 资源的厂商。我们也拿 B200 的服务器做了一下整体测试。推理的部分我们还在测试中，但预训练的数据可以看到。我们这里是基于 Llama 7b、13b 和 34b 的模型跑了预训练，可以看到在不同的并行策略上，B200 比 H200、H100 的吞吐量至少有 50% 以上提升，高的可能有百分之七八十。

图片

所以 B200 提升还是比较可观的，我们接下来 B200 的的集群也会在日本上线。

除了刚刚提到的一些推理优化相关的工作外，我们还做了一些帮助客户快速部署和运维推理服务的工作，帮助客户在我们的平台上通过界面的形式快速构建镜像，用内置的一些推理模板快速的部署推理服务。同时推理服务的全面监控也以数据看板的形式为客户提供，推理服务的鉴权、服务的管理、计费的管理也为客户提供了比较完善的功能。

图片

推理服务的性能监控对于客户来说是强诉求，这一块我们基本上做到了全链可观测，从硬件的状态，包括 GPU 负载、GPU 温度、磁盘状态各方面，到系统的状态以及推理负载状态、推理运行框架状态，包括推理运行的 SLO，全部都以不同的可视化图表为用户呈现。

图片

同时基于这些主指标，我们也会为客户定义一些高级监控指标。比如说某些监控指标组合起来能够发现某些问题。特别是在故障监测这部分，我们积累了几十种故障监测策略，通过不同的指标综合判断是什么样的故障，它的故障等级是怎么样的。一旦发现这样的故障，我们也有一定的自动化策略去处理，同时首先会把这些故障的原始完整数据链条拉出来给客户，以告警的形式发给客户。同时我们会根据故障的等级不同而采取不同的措施，如果是 P0 等级的，我们立刻去把推理负载所用的 GPU 集群做物理隔离，同时快速取新的副本起来，维持整个服务的稳定性。

图片

后续我们会配合人工服务，基于整个故障日志所采集的故障信息，最终分析整体的故障原因给客户。同时分析出来的处理后内容又可以积累到我们故障感知、故障检测和故障处理的整个流程中。

总结一下 GMI Cloud Inference Engine 的特点，主要有 4 个：

• 弹性伸缩；
• 提供高效的推理部署工作流，让企业能够一键部署整个推理服务；
• 能够结合硬件给企业做整个推理性能的优化，为企业提供比较极致的推理性能；
• 通过全面的整体主动监控和故障监测与处理流程，以及我们线下的服务保障，给企业提供稳定的推理服务。

4 GMI Cloud 推理服务实践

GMI Cloud Inference Engine 会基于一些开源模型构建一些 API 服务，GMI Cloud 在里也做了很多推理性能的优化，目前推理服务的 API 已经上线我们的平台，整体价格会比行业水平低一些。整体 API 的调用也是遵循 OpenAI 的 API 格式，可以直接以 OpenAI 的 API 形式来快速调用，接入自己的应用中。

图片

过去，我们服务了一些图片生成和视频生成的客户，比如一个在北美的企业客户，他们的核心诉求就是弹性扩容。它的用户量在过去两个月有比较大的增长，出现过一天内需要快速弹性扩容一倍的情况，过去一个月它整体的扩容水平是增长了 8 倍。

图片

另外一个值得一提的是，欧洲的一家视频和音乐生成厂商，他们在我们平台上做了训练和推理两个部分。训练的部分，我们也有相应的服务帮他们做整体训练速度的提升，主要就是整体通信优化。推理的部分，他们目前也在用我们的“弹性推理”服务，因为欧洲的时间和北美用户的时间和亚太用户时间是相对比较错开的，所以我们会有一些闲置资源去支撑他们在欧洲时间的推理高峰。

图片

嘉宾介绍

Frank Lee，GMI Cloud 资深架构师，深耕人工智能领域 8 年。作为 AI 四小龙早期核心成员，深度参与企业从 0 到 1 的技术商业化突围，亲历 AI 算法从实验室走向规模化落地的全周期实战，对行业技术演进、市场需求匹配及商业闭环构建具有稀缺的早期开拓者视角。主导过 10 + 行业头部客户的 AI 解决方案落地，擅长从客户痛点出发，利用 “算法 + 算力 + 数据” 三位一体的端到端方案，将前沿技术转化为可规模化复制的商业产品的成熟方法论。国内首批投身 AI 与云原生融合的技术专家，深度理解 AI 模型训练、推理部署与云基础设施的协同优化，在容器化调度、分布式训练框架适配、资源弹性分配等领域积累了标杆级项目经验。