乘着OpenAI带来的新技术变革，AI产品出海掀起了新一轮全球化之路。PPIO派欧云联合创始人&CTO王闻宇，在 2024 AICon 全球人工智能开发与应用大会，结合AI推理云的跨地域服务实践，分享了PPIO派欧云在助力本地开发者全球化业务中的技术优化实践。为企业提供借鉴。

企业出海动因分析

越来越多AI产业企业选择出海。

海外市场ToC的泛联网AI应用(APP+网站）正在高速增长。即使在中美关系角力的今天，其中出海公司也占据了很大的份额。我身边创业圈的趋势也能明显看到，之前做本地ToC APP创业者，现在基本都在做出海的应用，APP或者网页，而且很多人都在做AI原生应用。

此外，相比本地市场，出海市场在某些领域能提供更加开放宽松的竞争环境，有助于企业自由发挥。另外，欧美地区的用户的付费意愿比较高，更容易收到钱，哪里有金子，就去哪里开拓，这也符合本地创业者精神。

另外还有工程师红利，勤劳务实的服务精神，也是推动AI企业出海的关键力量。本地工程师在海外市场中展现出了高效的工作能力和服务能力，不论在技术，产品创新还是服务，都不差于欧美本土的公司。

本地创业者进军全球市场的力量正在强势崛起，我们有理由相信，The Next China is Chinese！

出海之路面临的挑战

出海市场的征途中，除去科技领域的激烈博弈，这一不可忽视的影响因素。“人生地不熟”和“语言文化”问题也值得注意！

当企业决定进军海外市场时，他们往往面临一个全新的商业环境和文化背景。这意味着他们需要时间去了解并适应新的市场规则、商业惯例、法律法规以及消费者习惯。缺乏这种“地熟”可能会导致企业在决策时出现失误，进而带来不必要的风险和损失。

语言和文化差异也是出海的一大难题。在海外市场，特别是非英语国家，语言、文化障碍可能会导致沟通困难，进而影响业务的顺利推进。因此企业不仅需要确保与当地合作伙伴、供应商和客户之间的顺畅沟通，还需要考虑如何将产品和服务本地化，以更好地满足当地消费者的需求... ...

出海的所面临的问题固然很多，在一个高度不确定的市场下应该怎么做，我的看法是抓住需求的本质，找到不变的量，找到常常听说的“第一性原理”，然后在应对并逐一解决变化的量。

抓住不变的需求

PPIO派欧云是一家定位做分布式云的公司，更多是整合边缘节点，特殊用途的计算节点，非标异构的节点，并建立起统一的云服务。我们做得事情比较Infrastructure，主要解决的基础设施和算力的问题。所以我们更多是站在Infrastructure的角度看问题。

分布式云在AI里面的场景里面，比较适合的是做推理，而不是训练。因为训练需要大规模集群，需要NVLink/NVSwitch 甚至IB网络等技术把多张卡/多张机器，连起来形成纳秒级(低于0.000001秒)延迟的超高速内网，而且训练中要存储大量的中间状态，也需要非常高的SLA要求，而且集群要求很大的规模，且无法分散。

而推理则不一样，现在最大的模型经过优化后，单机甚至单卡就能独立完成，而且状态轻，不需要存储重要的信息，可以任意调度，没有集群的要求，且可以分散。因此分布式云适合做的就是做推理。

另外，训练是一次性的，一旦训练好之后，后续计算量不再需要，就好比视频的制作，推理是持续的，伴随用户使用的增加，而计算量增大，这就视频的分发和传输，看的人越多，带宽用得越多。

站在推理的角度，不难发现一个长期不变的事情，就是推理服务未来是持续增加的，甚至高速发展，10倍，100倍，1000倍等，我本人坚信AI推理将会持续爆发。

未来的单位计算的推理成本持续降低，10倍，100倍等。什么是单位计算的推理成本，不是说单单说算力，而是1张1080p图片生成成本，1M输入输出的大语言模型Token的成本。

越来越低的推理成本，会让更多人用得起AI，更多公司负担地起AI，反向地促进AI推理的爆发。

我们要做的事情，就是做时间的朋友，做复合趋势的事情，也就是不仅仅伴随，甚至主动推动AI推理成本的降低。

而且这对出海更为关键，因为海外做AI的新ToC应用走在前面，已经在高速增长了，越来越多的公司关注推理成本，这也是我们要赋能出海AI公司的原因。关于本地AI新应用的落地，我也非常乐观，但判断本地做AI的新ToC应用未来也会起来，但是会滞后海外1-2年，现在还主要是做训练做行业的时代。

但是，有个问题，AI推理的算力为什么很贵？会持续很贵吗？

我的回答，是的，原因几点。生产资料昂贵，直接说，英伟达的GPU很贵，电也很贵，还有场地，人员运维等；Scaling Law 在技术性能过剩之前，会长期持续有效，模型的参数参数还在越来越大，进一步推高算力的成本；GenAI（生成式AI）正在走向多模态，走向音视频，这样不仅仅意味着模型参数的增加，还有输入输出的序列的增加，这也变相地推高算力的成本。

还有，现在主流模型公司和科研人员，大部分精力都在模型效果上，对于模型的优化还做得比较浅。模型本身还有大量的优化和压缩的空间。这就好比音视频编解码，还在还停留在h262时代，距离大家刷抖音看到的h265视频，还隔了几代技术，压缩率至少提高了10倍。

怎么降低AI推理成本：成本优势+技术赋能

我们拆解一下这个问题，怎么降低AI推理成本。我看来主要2条路线，降低生产资料成本，技术手段。

降低生产资料，再拆解，主要是GPU成本，电费，其他。GPU虽然很贵，但是电和产地运维等就有很多文章可以做，我们的解决思路是发展分布式云的思路。

除了发展分布式云的思路以外，还有AI技术手段，通过实现推理加速，模型压缩等技术来做到，这个很神奇，模型还是这个模型，GPU还是这个GPU，但是通过软件优化，还真能降低一个数量级。

重点说说我们发展分布式云的思路和技术。

分布式云：发挥成本和资源优势

在出海项目中，不同地区生产资料成本的差异，这是一个重要的红利。例如，全球电价存在差异，本地的电价相对较低。如果我们进一步细分到美国的各个州，也会发现更多的成本差异。

因此，分布式云作为分布式云，在生产资料上，我们的目标是寻找这些成本洼地，通过减少各种成本如生产资料、电费、场地运维，来初步降低推理成本。

其实，成本洼地不仅仅是因为电价便宜，在实际操作过程中，发现世界很多地方的能源政策都存在非市场化要素，不是简单的规模越大价格越低，有些地方甚至相反， 建设10000张GPU的集群，拿到的电价非常高；但是相反，建设500张GPU的集群，然后能拿到比较低的电价。这不仅仅是生产资料的问题，这是生产关系的问题。

但是，分布式云如果要做好，其实技术远远没有想象的简单：

AI推理需求所在地未必是成本洼地算力的所在地，甚至可以跨国服务（符合各国法律，并且数据合规要求前提下），那么网络联通性就是一个难点了，因此我们实现了全球网络加速技术来解决这个问题。

分布云因为节点多，且还可能不在一个地方，不在一个集群，如何管理和整合这些节点，给开发者提供一个简单易用，上层模型透明的平台就是非常关键，因为我们采用Serverless技术来解决这个问题。

下面我分别介绍一下我们这2个关键的技术优化。

全球网络加速技术 ：跨国网络挑战及智能跨国加速解决方案

海底光缆是支撑全球互联网通信的重要基石，近年来，虽然中美、东南亚海缆都在不断升级迭代，容量得到扩充。但在跨国网络中，仍然面临着高丢包率、高延迟和速率限制等诸多挑战，严重影响了跨国网络的使用体验。

我们在助力开发者跨国提供服务的过程中，如何构建一个低延时、大带宽、低抖动、低成本的网络成为了我们推动业务的一个命题。为了应对这些挑战，我们需要在上层构造一个智能跨国加速网络。

经探索，我们实现 “动态最优路径选择 +  UDP 可靠传输 + 传输协议优化”的解决方案。通过该方案我们能够实现低延时、大带宽、低成本的网络连接。这使我们能够利用低成本的国家和地区的资源来服务高价值的市场，从而抹平价值差异。

动态最优路径选择

在网络通信中，我们根据实时的网络状况动态地选择最佳的数据传输路径。可以减少数据传输的延迟，提高带宽利用率，并降低网络抖动，从而优化网络性能。动态最优路径选择可能涉及以下几个要点：

1、KSP 最短路径

RouterCenter 依据转发服务上报的水位信息，使用KSP算法定期生成最短路径

2、分段路径下发

定期进行路径下发，将最优路径拆分并分别下发给加速网络

3、去中心化能力

加速网络拥有去中心化的能力，可以在RouterCenter 异常时正常服务

4、节点自治能力

节点间质量的自动探测，保证链路质量的可用性

加速服务Agent：加速网络的入口，所有待加速请求需经过Agent进入加速网络，Agent支持TCP/UDP协议、HTTP/WebScokets协议等协议接入，另外，也可以在Agent上配置一些分流策略(加速名单/加速链路等)。

上车点/下车点/中转服务：加速数据进入加速网络的第一跳称为上车点，最后一跳称为下车点，中间节点称为中转服务；一个服务既可以是上车点，也可以是下车点和中转服务，具体取决于当前的加速请求的位置。

如上图所示，各服务节点定期向路径规划中心(RouterCenter)上报水位信息和节点间质量统计信息(黄色线条)，路径规划中心依据上报的实时信息进行KSP最短路径规划，将最短路径分段下发(蓝色线条)到各服务节点。目前，一个目标区域最多规划n条路径(可配置)，在下发的分段路径中以权重表示，权重越高代表路径质量越好，被选中的概率越大。

因地制宜，实现可控的 UDP 传输

当前，其实已经有一些非常优秀的可靠UDP传输协议的实现，但是这些协议都不能满足出海网络的需求(高rtt/高丢包)；比如uTP不适合拥塞的网络，KCP不适合高延时和大流量的传输，QUIC实现比较复杂，性能开销大等等。

另外，我们也对AI推理涉及到的不同场景(大语言模型、音视频推理、模型下载)进行分析和总结，依据对延时、QPS、流量等方面的特性，分为API加速场景和大文件传输场景，针对不同场景使用不同的优化手段。

API加速场景：主要是指客户端向服务器发送的推理请求，尤其是大语言模型的推理请求，特点是数据量小、请求频率高、低延时要求。

大文件传输场景：主要是指模型和镜像文件的下载/上传，特点是数据量大、低请求频率、带宽消耗大。

最终，我们针对出海链路，实现了一个新的UDP可靠传输协议--ACNP 。它比QUIC更轻量，比KCP更健全。通过对大文件传输场景和API请求场景进行特定的优化(大带宽模式 和 低延时模式)，在大文件传输场景和API场景分别保持了最大的传输速度和最低的延时。

优化要点：

1、化繁为简：简化多路复用/多路传输、简化协议头

2、拥塞控制：低延时模式 vs 大带宽模式

3、ARQ：更高效和支持更大范围的 SACK，乱序度优化的 RACK

4、FEC：低延时模式下，利用空闲带宽发送 FEC，大带宽模式下，重传包使用 FEC

优化效果：

API加速场景(低延时):

下图是我们生产环境关于延时的真实数据(注：蓝色为QUIC，橙色为KCP，紫色为ACNP)，我们对不同的协议进行了A/B TEST，可以看到，ACNP协议在跨海链路上表现出了明显的优势(比QUIC，  延时降低 ↓ 40%；比 KCP，延时降低 ↓ 20%)。

大文件传输优化(大流量):

下图是不同协议在跨海链路上传输大文件的对比，ACNP(绿色) VS TCP(红色，开启BBR) VS KCP(蓝色)；可以看到，ACNP在跨海链路上传输速度更快更稳定；

下图是在跨海链路上进行大文件传输的对比，未开启加速(左侧) 和 开启加速(右侧)，大文件传输速度可以有50-100倍的提升；使用多线程工具下载，传输速度可以达到百MB/s级别；

讲完了全球网络加速，下面讲讲Serverless。

Serverless：高效整合多个分布式的节点

传统的 GPU 容器云解决了算力的使用问题，但没有解决算力的易用问题。在跨国服务过程中，节点众多、用户调用复杂，为给客户提供更好的用户体验，我们引入了一个交易层的技术，构建了Serverless架构，实现了弹性伸缩和按需付费。

提供 Serverless Inference Endpoint，客户直接访问 API，减少客户在业务无关层面上的投入，使客户更加聚焦业务。

Serverless 架构具有弹性伸缩（自动按需扩缩容，极高的弹性），按需付费（用多少资源就花多少钱，不用为闲置资源来买单），免运维（不需要管理底层资源，以及高度的自动化和自愈能力）三大优势。

这让我们不仅解决了使用问题，还解决了业务问题，使用户可以直接调用我们的service API进行快速部署。

然而，Serverless架构也给云服务提供方带来了一些挑战。首先，面对海量突发的流量请求，云平台需要高效的调度请求和扩缩容服务。其次，为了消除底层异构资源的差异，我们需要提供标准的统一容器环境。最后，由于资源全部由云服务托管，我们需要解决资源不足的问题，确保用户在需要时能够获得算力资源。那我们是如何解决这些挑战，成功实现 Serverless 架构，有以下4个要点：

弹性调度

我们实现了完全按需弹性的调度系统。当无使用时，不产生任何费用。该系统基于 FlashBoot 技术，确保首实例能够在秒级内启动。同时，具备故障自愈能力，异常请求会被重新调度。我们还对实例状态进行实时监测，实现自动负载均衡。

跨云扩容

为了满足不断增长的计算需求，我们实现了可弹性扩容至第三方云的功能。理论上，这种扩容能力是无限的。此外，基于多云实现容灾，进一步提高了系统的稳定性。在平衡稳定性与成本方面取得了显著的成效。

虚拟运行环境

我们的平台兼容四种常见的算力资源，并提供统一的虚拟运行环境。该环境遵循容器运行时规范，支持主动健康检查，确保任务的稳定运行。同时，我们还支持任务的快速切换，提高了整体运行效率。

推理加速+Serverless的效果

除Serverless构建，我们针对BPO相关的三要素——内存、算力和通信带宽需求，进行了深入研究和改进，采取了关键算子融合、虚拟显存管理、批调度优化、全链路量化、稀疏计算等多种策略来提升性能和效率，并取得显著成效。

通过对推理框架的深度优化，系统的整体计算效率、存储利用率和通信速度得到极大提升。同时，Serverless架构的弹性伸缩和按需付费特性确保了算力和显存资源的高效利用。以本地的产品 派欧算力云为例，在分布式Serverless推理平台中，网络性能和Serverless架构的优势相结合，带来了显著的效果提升。

我们适应全球范围内的业务需求，在大带宽、低延时和低抖动的加速网络和各项技术加持下，构建了分布式AI推理云，实现了高效的资源调度和计算能力的弹性扩展。这不仅提高了处理效率，还大大降低了运营成本。

推理加速：让AI推理，成本下降一个数量级

虽然生产资料的成本是能通过分布云的方式降低，但是下降空间都是有限的。其实降低推理成本，还有一个大杀器，用得好，其降本空间更大，这就是推理加速技术，其中也包含了模型压缩技术。

推理加速的本质在于解决制约性能的三要素：显存、算力和带宽。

想象一下，如果有一块固定的显存，能不能像打理家务一样精打细算，让这块显存存下更多的东西？这就是一个值得考虑的点。同样的，对于算力，我们是不是也能在运行时更精细地管理，让更多的计算任务同时跑起来呢？说到带宽，其实它就像是数据在GPU芯片和其他存储设备之间传递的“道路”。如果我们能想办法让数据减少在这条“道路”上的拥堵呢？比如降低通信量，那也是一种优化的思路。

我们对推理加速的做法主要分了2类，第一类是基础优化，我们采用了一些流行的算法，如融合注意力机制、虚拟内存管理、连续批处理等。每种方法都实现了数倍的推理加速。总体而言，我们相对于基线可以获得超过10倍的加速效果。

“通用”意味着这些优化仅依赖于Transformer结构，因此它们对经典的LLM模型非常通用。这些优化对多种模型都非常友好。

让我简单介绍一下这些方法：

1、融合注意力机制：这是将注意力块内部的多个操作符融合为一个大的操作符，从而减少内核启动时间和数据复制频率。结果是计算复杂度从N平方降低到线性N。这与FlashAttention算法非常相似。

2、虚拟内存管理：我们可以调用低级别的CUDA API，在虚拟地址空间中分配和释放GPU内存。内存管理系统使用块表将虚拟KV块映射到物理内存块，通过这种方法，可以提高GPU内存的使用效率。这意味着我们可以在有限的内存空间中输入更多的请求，总吞吐量也随之提高。

3、连续批处理：此方法旨在提高请求调度效率。当批处理中有许多长度不同的序列时，该方法可以避免无用的填充标记，并在一个序列完成后直接附加新序列。通过这种方法，系统可以并行处理更多的序列或请求，总吞吐量因此得到提高。

4、分块注意力：我们知道，提示输入通常非常长，需要更多时间进行上下文预填充。当系统在预填充阶段花费更多时间时，就没有时间解码输出标记，这对延迟不利。分块注意力尝试将大预填充上下文划分为许多小块，并将它们与解码工作负载一起调度。总体而言，调度效率提高，延迟降低。

还有一类是高级优化，与“通用优化”不同，高级优化非常针对特定的模型。这意味着我们需要对现有模型进行轻微的Post-Train(后训练)或Fine-tune(微调)，以提高推理性能。这些方法可能会导致一些精度损失，但我们有技术能力将精度损失控制在较小的范围内。根据我们的实践，我们可以在精度损失很小的情况下，将推理速度提高超过10倍。

1、模型量化：包括混合量化和FP8端到端量化。混合量化用于将权重或KV缓存数据转换为INT8或INT4类型，从而减少所需内存。在计算过程中，需要反量化，这会带来额外的工作量。因此，混合量化可以提高吞吐量，但对延迟没有帮助。另一方面，我们在支持FP8的GPU上做了基本全链路的FP8量化（如L40s，L20，还有RTX 4090等），FP8量化是一种非常出色的方法，通过将权重和中间数据转换为FP8，并使用FP8 TensorCore进行计算，可以避免额外的反量化。推理效率大大提高。

2、 稀疏计算：包括KV缓存稀疏和权重稀疏。两种方法都试图分析网络神经元的分布，并将其分为重要和次要。在推理过程中，只使用重要的KV数据或活跃神经元。总计算量大大减少。

关于更多推理加速各种详细方案，可以参考《PPIO CTO王闻宇：我们是怎么做到让AI推理成本下降数量级的》

后续优化思路：

当然，推理加速这一块的优化空间其实还有非常大。我们后面还会陆续尝试其他方法来持续提升推理速度，如果把握得好，在部分模型下可能还有十倍优化空间。

例如可以通过Transformer算法深度优化，比如线性注意力机制，优化 Softmax 算子，使用少量中间状态对全局注意力信息建模，复杂度降低到线性；又比如线性KVCache机制，优化 KVCache 存储算法，仅保存一层键值数据，将缓存空间复杂度降低到线性；再如共享注意力机制，针对显存优化，通过细粒度切分，让注意力数据更容易共享，提升显存利用率，等等。

例如我们还打算尝试 Speculative Sampling(投机采样)，采用Medusa机制（美杜莎机制），做到在隐藏层增加多个 Head，让其并行解码后面的内容，组合输出结果，提高效率。采用前瞻编码，将模型解码分成多个预测分支和一个验证分支，预测分支并行解码，最后交由验证分支统一输出，提高并行度和效率。采用多阶段投机解码，将草稿模型按重要性重构为树形结构，从而分阶段执行投机解码，提升解码有效性和总体效率。