分布式 AI 推理：电信服务提供商领导者须知

目前，每个电信服务提供商都在实施 AI。用例包括客户服务机器人、网络运营辅助系统，以及面向外部企业客户和其他方的托管式 AI 即服务（AIaaS）。 

棘手之处在于用例与商业案例之间的关联，其中关键因素在于 AI 加速器的成本——无论是图形处理单元（GPU）、张量处理单元（TPU）还是神经处理单元（NPU），皆是如此。每次推理的成本决定了这些 AI 加速器是会提升利润率还是会侵蚀利润率；在成本控制上，您选择的 AI 模型，与您如何跨多个地理位置、大规模分布式部署该模型并提供服务，两者同等重要。

在近期发布的一篇文章中，红帽员工将推理部署挑战视为一个受流量和规模影响的架构问题，而不仅仅是受模型大小影响的问题。这篇博客文章对他们的发现进行了总结。

每次推理成本如何影响盈亏

每个 AI 请求在同一硬件上都包含两个不同的作业： 

• 首先，它会读取提示/输入内容，无论是账单历史记录、故障工单、网络日志，还是其他需要处理的内容。 
• 然后，它会针对该输入生成响应，每次一个词元。

读取阶段决定了用户等待第一个字词出现的时间长短；生成阶段则决定了对话是流畅自然，还是频繁出现卡顿和间断。这两个阶段需要不同的资源配置文件和优化方案，并且当它们共享 AI 加速器资源时，会产生资源竞争。

在不同的 AI 用例和工作负载类型中，这种紧张关系对盈亏的影响各不相同。例如，在客户服务聊天机器人场景下，当机器人卡顿、会话升级至人工客服处理时，每次客户服务交互的成本就会上升。企业级 AI 产品若未达到延迟承诺，将面临服务水平协议（SLA）的罚款。当每次查询的成本超过合同定价时，企业对企业（B2B）AI 产品的利润空间就会被侵蚀。 

大多数部署错误都是权衡错误，通常发生在团队优化了与产品销售无关的指标时。通过分析 AI 创造收入的一些具体方式，可以阐明每种工作负载类型的正确部署方式。

客户服务

客户服务是最明显的例子。客户服务流量由成千上万个并发的短会话组成，每次通话都会重复使用相同的费率和政策前言。红帽员工根据红帽的 vLLM 基准测试，得出了以下结论：

• 针对此类流量模式，通过拆分读取和写入池并合理调整其大小，可将成本降低 25% 至 40%。
• 缓存感知路由（即开源项目 llm-d 实现的调度方法）在提示词重复使用率较高的情况下，使每个 GPU 生成的词元数量增加了 2-3 倍，每词元成本降低了 3-5 倍。

虽然生产系统不会达到这种程度的提升，但这一趋势在我们测量的所有工作负载中均得以体现。在每月数千万次的客户服务交互量下，即便推理成本仅降低几个百分点，所节省的资金也足以支撑下一个产品周期，而无需新增加速器资本支出（CapEx）。

网络运营

网络运营的情况则恰恰相反：用户数量很少，要处理的文档却非常长。事件分析过程中会不断地重复读取相同的 Runbook、拓扑记录和供应商手册，因此主要的成本控制手段是将已处理过的内容缓存起来。这样做的好处是缩短了诊断时间，并减少了需要升级至高级工程师处理的情况。

面向企业销售的托管式 AI

面向企业客户销售 AI，将会带来第三种截然不同的流量模式，它具有三个核心特征：多租户、分层服务水平协议（SLA）以及突发性需求。在这些场景下，有两种机制可以保障利润率：

• 模型级联：将常规查询发送至小型模型处理，并仅将复杂查询升级至更高层级处理，在简单查询占主导的情况下，可将集群成本降低 40% 至 60%。
• 与服务级别目标（SLO）关联的准入控制机制：拒绝可能违反 SLA 的请求，而非将其排入队列直至失败，从而在高负载下保障合同的可信度。

如表 1 所示，这三种用例可以共同作为金、银和铜定价等级的模型，而非迫使客户挤在同一个共享 AI 加速器池里凭运气抢占资源。不过，还有两个约束条件进一步完善了服务提供商的整体方案，并展示了根据具体客户的需求定制 AI 服务的方法。 

具有云爆发能力的主权 AI

主权规则要求订阅者数据保留在其来源国家/地区。最能满足这一需求的模式是：以受监管的本地部署作为基线，并辅以能在非高峰时段保持冷备状态的云爆发能力。红帽 OpenShift AI 等单一控制平面可以使两个环境保持一致，因此合规性不再仅仅依赖于配置规范。

边缘计算

在涉及网络边缘的场景中，如果并发会话数大约为 100 个或更少时，正确的做法是每个加速器部署一个模型，而不采用任何复杂的池化策略。  复杂查询应通过回传进行升级处理，这样传输开销便与查询复杂度挂钩，而非与查询量挂钩。

表 1.各类工作负载如何带来切实的业务成果

以下是提供商在考虑这些用例时需要提出的问题：

• 客户服务：如今，一次完全自动化的客服对话成本是多少？哪一项改变对这一数字的影响最大？良好的回答应列出基于线上真实流量测得的单次客户服务交互成本，并包含一项经过测试的成本控制手段及其前后对比数据。
• 网络运营： 工程师需要等待多长时间才能从事件记录中获得有用的答案？是否每次都要重新处理相同的文档？良好的回答应能反映出从缓存中调用 Runbook 和站点记录的频率与重新读取 Runbook 和站点记录的频率，以及首次获得回答所需时间的趋势变化。
• B2B 服务：在峰值负载下，哪项企业级 SLA 会首先失效？解决方法是增加硬件还是优化路由？良好的回答应指出负载测试中出现故障的层级，并说明在提交购买请求之前已尝试过路由或准入控制方面的修复措施。
• 主权和峰值： 为了满足数据驻留规则，在高峰事件之间，有多少容量处于闲置状态？良好的回答应说明基线使用情况，并给出一个在等待期间无需任何成本的突发方案。
• 边缘和现场： 有多少比例的现场查询会被回传至中央集群？这种传输的成本是多少？良好的回答应提供每个站点的本地解决率，并确保只有现场模型无法处理的查询才会升级处理。

投资路径

一旦确定某个 AI 用例可行后，下一步就是以经济高效的方式进行构建和落地。执行的顺序比最终目标更重要。每个阶段均由实际测量结果（而非路线图上的日期）触发，并且每个阶段在进入下一阶段之前，都要先收回自身投入的成本：

1. 从单个节点开始：在真实的客户服务或网络流量上运行单个服务实例一周。该基线将成为后续所有决策的衡量标准；实验室模拟流量将会产生误导。
2. 添加智能路由：第二个副本的吞吐量通常达不到第一个副本的 1.8 倍。这种差距意味着，请求被分配到了错误的服务器，导致该服务器不得不重新读取另一台服务器已经处理过的上下文。这是路由资源的浪费，而非算力不足，因此在购买硬件之前应先解决这个问题。
3. 分离读取池和写入池：仅当测量数据表明，一个阶段对另一个阶段的资源挤占程度，足以抵消由此增加的运营复杂性时，才应采取此措施。
4. 采用多租户网格：当多个产品和 B2B 客户共享平台时，保护分层 SLA 的机制即便复杂，也是值得的。如果规模未达到此级别，做这些工作就是白费力气。

每一步都会重置基线；AI 推理策略是一系列经过衡量的决策，而非一次性确定的架构方案。服务提供商早已将此 Playbook 用于无线频谱：将容量分配给能产生投资回报（ROI）的产品，持续测量，并回收闲置资源。AI 加速器也应遵循同样的原则。

结语

分布式 AI 推理决定了服务提供商 AI 产品能否保住利润率。这篇博客文章中概述的任何内容都不需要您押上全部预算来做出承诺：每一种机制都是一个可衡量的步骤，在迈出下一步之前，它会在服务提供商的流量上证明自己的价值，而表 1 则指明了首先应关注的方向。

当您准备好为您的客户服务、网络运营或 B2B 产品组合推进这些策略时，请将您的流量数据提供给红帽客户团队。vLLM、llm-d 和红帽 OpenShift AI 是我们目前与服务提供商合作实施该模式的方式，而当讨论从您的实际需求出发，而非基于通用蓝图时，沟通效率最高。