单点堆资源的时代正在收尾。GPU 卡数、链路带宽、存储 IOPS 各自翻番，业务侧却未必感受到等比例的体验提升。原因不复杂：这三类资源在真实负载下互相牵制，任何一环拖后腿，另外两环的投入都会打折。
一个直观的账：智算中心里最贵的资产是算力设备，而存储吞吐和网络时延决定了这些设备有多少时间在真正干活。存储拉不动数据、网络一抖，GPU 就空转。这种浪费不冒烟、不报警，却持续烧钱。算网存协同要解决的正是这件事——把三类资源放进同一个目标函数里优化，而不是各自刷自己的指标。
单点优化的收益为什么在衰减
过去十年基础设施的主线是分工做大：算力追 FLOPS，网络追带宽和时延，存储追容量和 IOPS。需求高速增长期，这套打法有效，因为每类资源都有独立的瓶颈要突破。
业务形态变了之后，逻辑也跟着变。大模型训练、实时推理、数据湖分析、边缘智能，这些负载对三类资源同时提出要求，且要求之间强耦合。木桶效应在算网存体系里格外明显：一块高性能 GPU 被慢速存储或拥塞链路卡住，利用率可能掉到一半以下；一条低时延链路如果两端算力调度节奏对不上，也换不来业务体验的改善。
所以协同不是概念包装，是从性能竞赛转向效率竞赛的必然结果。核心命题就一句：让每份算力都被喂饱，让每次数据流动尽量短、尽量稳。
调度器看不见的那部分，才是真问题
算力调度、网络调度、存储调度长期各管一摊。算力平台盯任务排队和配额，网络盯路由和带宽分配，存储盯副本、分层和一致性。三者之间没有统一资源视图，也没有联合优化目标。
典型翻车场景：训练任务要从存储拉海量数据到算力节点。调度器只看到”算力空闲”，看不到存储出口带宽已经接近上限，也看不到跨域链路正在抖动，于是做出一个看似合理、实际低效的决策。协同的前提是可见性，而跨域可见性恰恰是当前最大的盲区。
要让调度器”看得见”，得先把资源隔离和指标采集做扎实。Linux cgroup v2 提供了可用的抓手，比如给训练进程组同时限制 IO 带宽和绑定 CPU 核：
# 创建 cgroup 并限制块设备读写带宽（单位 bytes/s）
mkdir /sys/fs/cgroup/train-a
echo "8:16 rbps=524288000 wbps=524288000" > /sys/fs/cgroup/train-a/io.max
# 绑定 CPU 核，避免与推理任务争抢
echo "0-31" > /sys/fs/cgroup/train-a/cpuset.cpus
echo 1 > /sys/fs/cgroup/train-a/cpuset.cpus.partition
配合 node_exporter 采集 node_disk_io_time_seconds_total 与网卡 node_network_transmit_bytes_total，把存储出口带宽和链路吞吐纳入调度器的实时输入，才谈得上联合决策。没有这层可观测性，任何智能调度都是盲调。
无损网络：抖动的高发地带
原文泛泛提到”网络抖动”，落到智算场景，高频踩坑点其实是 RoCEv2 无损网络。PFC 阈值和 ECN 配置不当，轻则吞吐骤降，重则 PFC 风暴扩散到整台交换机，业务侧表现为训练任务集体卡顿。
根因通常是两类：一是 PFC 死锁，某优先级队列反复触发 pause 帧形成循环等待；二是 ECN 标记阈值设得过低或过高，前者导致过度降速，后者让拥塞无法及时反馈。排查时先看交换机 PFC 计数：
# 查看网卡 PFC 统计（以 Mellanox 为例）
ethtool -S ens1f0 | grep -i pfc
# 查看 ECN 标记计数
ethtool -S ens1f0 | grep -i ecn
若 pause 帧计数持续高速增长而业务吞吐不升，基本可判定 PFC 风暴。调优方向是收紧 ECN 的 min/max 阈值、确认 PFC 只开在必要优先级、并检查交换机 buffer 分配。这类问题不解决，算力调度做得再精细也会被网络拖垮。
接口不统一，协同成本被放大
不同厂商的算力平台、网络控制器、存储系统各有接口和语义。即便都提供 API，字段含义、粒度、时序也可能对不上。每做一次跨域协同就要定制适配，项目制能交付，产品化很难复制。
标准化是协同从项目走向产品的关键瓶颈。短期别指望统一标准实现，务实做法是在自己可控范围内先定义内部资源抽象层，把算力、网络、存储的关键指标映射成统一语义，再对外适配。这样至少内部调度逻辑不用反复重写。
利益机制：最容易被技术讨论盖住的一层
算网存往往分属不同运营主体或部门，KPI 各不相同。算力方要利用率，网络方要稳定性，存储方要控成本。全局最优的调度策略，可能让某一方短期吃亏。
没有成本分摊和收益分配机制，协同只能停在演示阶段。很多联合方案在 PoC 里数据漂亮，进不了生产环境，根子就在这里。技术难题可以逐步攻克，利益机制不解决，协同走不远。
这里需要明确方案的适用边界。单集群内部的算存联动、跨域训练的算网联合优化，因为主体相对单一、结算简单，实现可行性高。而跨主体、跨域的全局统一调度，在缺乏清晰结算机制时不宜强行推进，否则容易变成谁都不愿承担成本的僵局。
三个可以动手的切入点
以业务体验为锚，别以资源为中心。协同目标不是把三类资源都跑满，而是让业务目标达成。大模型推理看首 token 时延和单位 token 成本，数据分析看扫描效率。把业务 SLO 翻译成算网存的联合约束，才不至于为了协同而协同。
可观测性先行。调度算法之前，先解决”看得见”。统一指标体系、建资源抽象层，让调度器基于实时状态决策。上面 cgroup 和指标采集的例子就是最小可行起点。
从封闭方案走向开放生态。单一厂商包揽算网存不现实也不经济。更可行的路径是在接口、数据模型、调度策略上形成开放约定，让不同主体在统一框架下各司其职。这需要产业组织、标准机构和头部用户一起推。
节奏判断与两种要警惕的倾向
算网存协同正从可选项变成必选项，但成熟节奏会比预期慢。它本质上是系统重构，涉及技术栈、组织边界和商业模式同步调整，不是一次技术升级。
短期内更可能出现的是局部场景的深度协同——智算中心内部的算存联动、跨域训练的算网联合优化，而不是全局统一的大协同。
两种倾向要警惕：一是把协同当营销话术，用联合方案包装既有产品；二是过度追求全局最优，忽视各参与方的现实约束。有价值的协同，应该在不改变各方核心利益的前提下，先解决一两个可量化的效率问题，再逐步扩边界。
当下最务实的动作不是等统一标准，而是把自己的资源可观测性做扎实，把业务 SLO 定义清楚。能被度量、被约束、被优化的资源，才有资格进入协同体系。终局不是三张网简单合并，而是让算力、网络与存储在同一目标函数下运行——价值不在概念多新，而在能否把被浪费的算力真正释放出来。
ID:6788
