【阅读原文】戳：作业帮基础架构负责人董晓聪：统一的算力网络是企业解决自身推理算力供需问题的最优解
本文整理自作业帮基础架构负责人董晓聪在「阿里云 AI 势能大会」中的分享：《作业帮算力网络的探索与实践：AI 时代的创新引擎》。
大家好！非常荣幸能够参加阿里云举办的 AI 势能大会。我是董晓聪，目前在作业帮担任基础架构负责人，主要负责架构研发、运维、DBA 及安全相关工作。今天，我想和大家分享的主题是“AI 时代的新引擎：作业帮算力网络的探索与实践”。这里的算力网络并非传统数据中心的硬件网络，而是我们在多机型、多地域探索构建的逻辑网络。
01. 作业帮的AIGC探索与技术挑战
作业帮成立于 2015 年，是一家教育科技公司，依托多年的教育资源积累和前沿技术的不断探索，公司业务覆盖 C 端和 B 端等多个学习场景。在 C 端我们推出了面向学生和家长的系列学习工具、智能学习硬件、素质教育课程等多款产品，创新性和专业性持续领先。在智能硬件方面，尤其是作业帮学习机，一经推出就受到学生和家长的喜爱，在近几个月的市场数据中已实现销量和销额的市占第一。在 B 端，我们通过科技手段持续赋能公立校教育，积极探索智慧教育解决方案，助力前沿科技在公立教育体系的落地。
作业帮在 2023 年推出了专注于 AI+ 教育领域的作业帮大模型，其核心能力涵盖解题、识图、语音等多项功能。在大模型的加持下，作业帮的所有产品进行了 AI 范式的重构，取得了显著成效。
例如，在 AI 解题方面，借助大模型，我们能够针对学生在不同维度、不同步骤提出的问题，提供更详尽、更具针对性的讲解；AI 写作可对学生的作文进行逐段逐句深度分析，并给出优化建议。
在 AI 推理爆发的时代，作业帮在技术层面也迎来了新的挑战，主要集中在供需两个层面。
需求侧：创新业务很难预估未来准确的用量，同时，业务方希望不断优化推理过程，在成本方面追求极致。
- 供给侧：当前单个 AZ（可用区）、单个 region（地域）、单一机型都难以提供充足的资源，给 GPU 推理服务在质量、安全、成本、效率等方面带来了更多挑战。
面对这些问题，我认为构建一套统一的算力网络是企业解决推理算力供需问题的最优解。
02. 统一算力网络的关键技术点
那么，如何构建统一的算力网络呢？大的架构可以分为资源层和应用层。资源层包含计算、存储、网络等 IaaS 能力，容器技术通过容器镜像、作业编排、资源调度和管理，使底层资源对上层应用变得透明。而上层业务应用若想跑得更快，还需一套微服务治理体系。
在统一算力网络中，三个关键核心点在于：
- IAAS 层如何构建可信网络；
- 容器层如何实现更优的资源调度；
- 应用层的流量调度。
1. 网络层：构建可信传输链路
首先，网络层的资源基建有多种跨 region 通信需求：
- 控制指令，如主机安全、远程登录以及运维命令通道的下发，其特点是流量低但复杂性高，涵盖多种四层和七层协议，改造难度较大；
- 大模型分发，大模型文件通常体积庞大，业务方希望尽快完成分发，因此峰值带宽用量较大；
- 服务调用，CPU 服务仍然部署在北京 region，但 GPU 资源有的部署在北京 region，有的在外地 region。访问外地 region 时就会产生跨地域服务通信调用，通信协议使用 HTTP + SSE，流量特点与业务流量正相关；
- 服务观测，包括 log（日志）、trace（追踪）、metric（指标）等，其流量特点也是和业务正相关。
在技术方案方面的选择有：
- 专线是最直接、最简单的选择，时延低、可靠性高、安全性强，但成本过高；
- IPSecVPN 方案是在公网上架设逻辑链路；
- TLS 则通过 TLS 协议在公网传输保证数据安全；
- SD-WAN 技术在此基础上增加了选路能力，但在数据中心之间的通信中意义不大。
综合考虑后，作业帮针对不同通信需求做出了选择：对于控制指令，采用专线和 IPSecVPN 的方式；模型分发后面再说；服务调用和服务观测则使用公网 TLS 方式，从而完成了可信网络的构建。
2. 容器层：资源调度&多 region 模型分发
1）资源调度优化
容器层的核心是资源调度，只有通过合理的资源调度，才能保证服务稳定并实现成本节省。在资源调度方面，我们的目标需求较多且存在冲突。例如，从稳定性角度，希望服务的不同 pod（容器）部署到不同 node（节点），以防单个 node 故障导致服务受影响；但从成本角度，又希望 node 上的碎片尽量少，服务尽量填满 node，以提升整体资源利用率。
首先，为满足这些需求我们自定义了 pod 的分配机制，技术实现上借助 K8S 的调度器插件机制。当待分配的 pod 从等待队列中取出后，先进行 filter 阶段，根据当前拓扑快照过滤掉不符合要求的 node。然后对剩余 node 进行打分，打分的目标函数基于目标需求，最终选择最优节点进行调度，并完成异步绑定及持久化过程。
然而，随着 pod 回收，node 上不可避免地会出现碎片。K8S 在回收环节未提供类似分配的调度器插件，我们通过自定义 KCM 的 pod 删除成本来实现预期的回收效果。
即便如此，随着时间推移，pod 碎片仍会不可避免地出现，此时需要重调度机制。我们定时分析集群拓扑，基于当前拓扑算出最优解，在不影响服务稳定性的情况下封锁相关 node，驱逐异常 pod，从而提升资源利用率。
在这一系列调度能力基础上，我们还构建了多种应用技术，如不同业务间的分时复用、将偏离线任务调度到在线集群实现离在线混部，以及使用 Serverless 实现资源的弹性伸缩。我们已经开始在使用阿里云 ACS 的 GPU 算力。通过这些技术优化，我们最终将集群平均资源利用率提升至 90% 以上，每月节省上千张卡的成本。
2）多 region 模型分发
模型文件与数据文件不同，不会随业务规模增加而扩大，更像是环境的一部分。因此我们采用容器镜像分发方式，但面对如此大文件的多 region 分发，仍需技术设计。虽然 P2P 技术可实现加速传输，但其复杂性偏高，我们最终选择通过阿里云对象存储 OSS 的跨区域复制功能将模型文件存储到 OSS。
我们的 CI/CD（持续集成持续交付）过程模型是：
- 经过复杂训练产出模型文件后，通过 CI 传输到权威镜像仓库 Habor，其底层存储采用阿里云文件存储 NAS，NAS 具备高可用性、高性能和高可扩展性。
- 模型镜像文件要投入使用，还需传输到各集群的 Docker Registry，每个集群的 Docker Registry 数据存储基于对象存储 OSS。
- 完成一个集群分发后，通过对象存储 OSS 的跨区域复制功能即可实现其他集群的传输，最终将镜像文件传至 ACK 集群，完成模型分发。
在此过程中，我们通过预加载等能力，将分发速度从数小时缩短 80%，百 GB 文件仅需 45 分钟即可完成多 region 分发。此外，为确保模型分发的端到端安全，我们在模型生产后，在 CD 环节通过 KMS 对核心文件加密，只有模型加载到内存后才解密，真正实现了 DevSecOps 流程。
3. 应用层：流量调度
流量调度涉及三个基础组件。我们的 CPU 服务部署在北京 region，可与其他微服务及数据存储通信。当需要访问大模型能力时，需通过 AI 网关。使用AI网关后，上层业务无需关心访问大模型能力是使用三方 API 还是自研模型。三方 API 可以使用阿里通义千问、DeepSeek 等，使用自研模型，也无需关心自研模型的具体版本和集群。
若涉及跨地域集群访问，还会用到 K8S Mesh 组件，其为作业帮自研的跨集群发现和通信组件，旨在不同集群间建立可信、高性能的传输通道。在实际访问大模型实例前，还有 LLM proxy 组件进行 pod 实例级别的负载均衡。
03. 未来展望
未来，我们将在推理技术方面持续探索，致力于降低成本、提升模型效果、保障服务稳定性。我们密切关注中心化 KVCache 技术，如阿里云的 IAAS 层 eRDMA、PaaS 的 Tair 等。另一方面，我们也在思考如何进一步将大模型能力应用于基础架构。未来，我们希望结合 Agent、MCP 的能力，从信息能力提升至行动能力。
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
