去年帮一个团队做算力选型时，看到一沓需求文档上写着相近的硬性条件：单颗 AI 算力卡 FP16 算力不低于 280TFLOPs，FP32 算力不低于 7TFLOPs，整机至少 8 颗加速卡，最好还能支持 FP8 推理加速。按这个标准筛下来，能选的设备并不少，但真正部署起来后才发现，算力卡堆得越高，卡与卡之间、节点与节点之间的协作问题就越刺眼。

这其实是 AI 芯片行业正在经历的转换期：单卡的峰值浮点性能不再是唯一可靠的评价标准，更关键的变量变成了“系统级算力效率”。市面上讨论热度很高的“RSI”方向，我倾向于把它理解为一种强调可重构系统互连与资源调度机制的架构思想统称。它不算一个已成定论的官方名词，却代表了一条正在发生的技术路线：通过重新设计计算单元、存储层级和互连拓扑，把分布式训练和推理中的损耗压到最低，从而真正重塑算力格局。

这篇文章会把 AI 芯片架构拆开来看，重点讨论 RSI 这类架构思路为什么值得关注，以及落到真实业务中时，我们应该怎样判断算力方案是否合适。

1. 算力评价的切换期：从单卡浮点值到真实利用率

1.1 峰值算力为什么曾经是最有用的指标

早期看 GPU 或 AI 加速卡，最直观的参数确实是 FP16、FP32 或者 TFLOPS。那时模型规模不大，通常单卡就能完成训练。场景简单时，峰值算力高基本等于跑得快，用这个指标做选型没有太大问题。

比如做视觉模型微调，输入是固定尺寸的图像，batch size 也能控制，单卡显存够用，计算单元能稳定跑满。这种场景下，FP16 算力 280TFLOPs 和 200TFLOPs 的差别，基本能直接换算成训练时间差。

这也是为什么很多算力采购需求书仍以单卡浮点性能为门槛，因为它足够简单，也方便横向比较。只要场景没有跨出单卡边界，这套方法就仍然有效。

1.2 单卡峰值不等于集群有效算力

问题从多卡并行开始放大。当模型参数超过单卡显存，或者训练数据量太大需要缩短训练周期时，就必然走上分布式训练这条路。此时影响吞吐的短板变成了显存交换、梯度同步、通信带宽和数据加载速度。

一个常见现象是：买回来的 8 卡服务器，标称算力很高，但跑起大模型训练时，GPU 利用率长期停留在 40% 到 70%。监听工具看，瓶颈往往出现在节点间通信等待上，训练进程大部分时间都在等梯度同步完成。

这就能解释一个反直觉现象：某些加速卡峰值算力不高，但通过更好的互连设计和显存调度，在真实分布式场景下的 MFU（Model FLOPS Utilization）反而更高。真正决定你能用上多少算力的，不只是一颗芯片能算多快，而是整机、整个集群能把多少时间真正花在计算上。

1.3 更需要关注的三个算力指标：MFU、有效计算时间、单位算力成本

选型时除了看 FP16、FP8 等浮点理论值，我更建议同时关注下面三个维度：

• MFU（模型浮点利用率） ：训练时模型实际达到的算力占理论峰值算力的比例。不同框架、不同并行策略下差异很大。如果厂商只能给出单卡峰值，却给不出多卡扩展效率，就还需要自己做压测。
• 有效计算时间 ：一个训练任务里，GPU 真正执行计算的时间占比。数据加载慢、通信等待久、算子调度差都会拉低这个值。它比理论峰值更接近真实体验。
• 单位算力成本 ：不仅是采购单价，还要摊上机柜、电力、散热、存储和运维。FP8、FP16 算力跑得再高，如果实际产出低，单位成本就不划算。

如果只看单卡浮点值，很容易出现“算力账算得过，但任务跑不下来”的情况。把 MFU、有效计算时间和单位成本放在一起看，才算进入系统级评价框架。

2. 拆开 AI 芯片架构：计算单元、存储和互连各自决定什么

2.1 计算单元：GPU、NPU、ASIC 的路线差异

要理解 RSI 类架构思想为什么值得关注，先得从芯片本身的组成说起。

GPU 路线的核心是通用并行计算。它在矩阵乘、卷积这类张量运算上有天然优势，配合编程框架能覆盖从训练到推理的多种任务。NPU 和 AI ASIC 则更强调针对特定算子做硬化，把神经网络中高频使用的矩阵运算、激活函数、量化逻辑直接固化成专用电路，从而获得更高的能效比。

从趋势看，计算单元本身不再只是堆核心数和频率。AI 工作负载中真正耗时的部分，往往不只是计算。数据从显存搬到寄存器、从寄存器送回显存，这个过程也在占用总线时间。芯片架构设计开始转向“让计算单元一直有数据可算”，这也是 RSI 类路线强调资源调度的原因。

2.2 存储：带宽和容量是算力的隐形天花板

模型参数快速增长，显存容量不够，就会触发 offload 或重计算。显存带宽不够，算子执行时就会频繁等待访存。这两点在选型时容易被忽略，但在真实训练场景里感受很深。

高带宽存储（比如 HBM）能显著提升访存速度，但它也带来更高的成本和更复杂的封装。为了在有限带宽下提高数据复用率，很多芯片开始增加片上 SRAM 容量，或引入更细粒度的数据调度机制。这个方向和 RSI 类架构关心的问题一致：让数据在靠近计算单元的地方多留一会儿，减少和外部存储之间的重复搬运。

如果只看算力卡的 FP16 峰值，而不看显存带宽和片上缓存设计，很容易低估存储因素带来的影响。真实算力密度往往取决于大规模矩阵乘法中的数据复用效率，而不是单纯的核心计算速度。

2.3 互连：RSI 类架构关注的核心战场

互连是 RSI 类架构最关键的部分。它分为几层：同一颗芯片内部计算核心和缓存之间的互连，同一块主板上多颗加速卡之间的互连，以及跨节点之间的网络互连。

传统方案里，多卡通信可能依赖 PCIe，数据经过 CPU 再分发到各卡，延迟和带宽都不理想。高端方案则会在卡与卡之间建立更直接的直连通道，让梯度同步和模型并行时的通信效率大幅提升。RSI 类架构思想的核心，就是把这些互连资源做成可重构、可调度的系统能力，而不是让用户自己费力配置。

一个直接的例子是：数据并行时，每张卡算完梯度后需要做全局 AllReduce。如果互连拓扑设计得好，AllReduce 可以在更低的通信成本下完成，训练吞吐自然更高。这不是靠软件调参能完全弥补的，必须从硬件架构层面设计进去。

2.4 “架构决定算力上限”不是一句宏大口号

过去两年，很多团队意识到一件事：单卡性能提升已经很接近物理上限，但系统级架构的优化空间还很大。GPU 之间如何互连，存储一致性怎么保证，算子调度如何适应不同模型结构，这些细节决定了集群在真实负载下的表现。

RSI 类架构的吸引力，在于它不把芯片看成孤立计算节点，而是把整台服务器、整个集群看成一个可以协同调度的算力系统。它在设计阶段就要处理碎片化、通信瓶颈、资源隔离等问题。虽然现在还没有一个统一的官方定义，但从技术方向上看，它代表了对“算力效率”的系统性重构。

3. 从单机 8 卡到集群组网：能跑满的算力才算数

3.1 算力卡规格中常见参数如何影响选型

在各式采购需求书里，经常能看到类似配置：单颗 AI 算力卡 FP16 算力不低于 280TFLOPs，FP32 算力不低于 7TFLOPs，支持 FP8 加速。这些参数本身没有错，但选型时很容易掉进“只看峰值”的坑。

实际操作中，我更建议把参数和业务场景对应起来：

• FP32 算力 ：更多影响传统科学计算、某些数值精度要求高的算子，以及部分框架默认精度下的表现。如果模型已经采用混合精度训练，FP32 峰值就不应占过高的决策权重。
• FP16 算力 ：直接影响大多数训练和推理任务的下限。但要注意，FP16 是否真的跑满，还取决于算子是否在硬件上做了充分优化。
• FP8 算力 ：偏推理场景。新一代加速卡把 FP8 作为卖点，但模型量化到 FP8 后是否稳定，需要实际验证。不要因为支持 FP8 就默认所有模型都能无损迁移。

3.2 8 卡服务器的组网与并行训练效率

单机 8 卡是当前最常见的训练单元，但“有 8 张卡”和“8 张卡能高效协作”不是一回事。

卡间通信如果走 PCIe Switch，可能还能满足中等规模模型训练；如果模型大到需要张量并行，则卡间直连带宽会成为关键。很多高端算力服务器会为加速卡设计专用的高带宽互连拓扑，配合消息通信库能明显降低延迟。

判断一台 8 卡服务器的真实水平，不只看它装了多少张高 TFLOPS 加速卡，还要看卡间互连带宽、显存总容量以及配套驱动和通信库的兼容性。建议在正式选型时，用目标模型做一个多卡训练小样本压测，记录扩展效率。如果从单卡到 8 卡只能提升 3 倍，那说明通信或调度消耗过大。

这里提醒：不要一上来就把并行策略调得过于复杂。先用单卡确认模型能跑通，再用 2 卡、4 卡逐步看扩展趋势，最后再上 8 卡。这个顺序能帮你定位问题是出在模型、驱动、存储还是互连。

3.3 多机互联时最容易出现的瓶颈

单机 8 卡不够时，就进入多机集群阶段。此时通信要求从机内总线扩展到网络层，常见的做法包括 RDMA 网络、RoCE 或 InfiniBand。不同网络方案在延迟、带宽和成本上差异很大，需要根据训练任务的实际通信频率来选择。

很多集群训练速度慢，不是算力卡不行，而是网络拥塞。梯度同步需要频繁传输权重数据，如果网卡带宽低、交换机丢包率高、TCP 协议栈效率不足，GPU 就会长时间等待网络数据。现在部分组网方案开始强调无损网络和低延迟通信，目的就是降低通信等待。

在实际部署中，我还遇到过节点间时钟不同步、MTU 配置不一致、RDMA 网卡驱动版本不匹配等问题。这些问题看起来和“AI 芯片架构”无关，但都会直接影响算力利用率，恰恰说明系统级优化在真实工程中分量很重。

3.4 建议：先做组网压测，再决定大规模采购

落地到操作层面，可以按下面这个顺序来做：

1. 明确目标训练模型规模和数据量。
2. 搭建单机 8 卡环境，用真实模型跑一个短任务。
3. 记录单卡耗时、8 卡训练吞吐、扩展效率。
4. 如果扩展效率过低，优先检查数据加载、卡间互连和驱动日志。
5. 再扩展到 2 台或 4 台机器，观察网络是否存在瓶颈。
6. 跑通后再做长期稳定性测试，包括显存分配、通信异常重连、存储高并发读取。

这套流程会花掉一些时间，但比直接大批量采购后才发现算力浪费要划算得多。

4. 不同业务对算力的需求差异很大

4.1 大模型训练：显存、带宽、集群规模

大模型训练是当前最吃算力的场景。千亿参数模型一旦做全参数训练，单卡显存完全不够，需要复杂的模型并行、流水线并行和数据并行组合。

这类业务对芯片架构有明确要求：

• 显存带宽是否足够支撑大 batch size 下的参数读写。
• 多卡互连是否支持高效的 AllReduce 和 P2P 通信。
• 集群网络是否具备低延迟、高吞吐特性。
• 框架是否充分适配底层通信原语，比如 ring attention、sequence parallel 等新并行方式。

在这种场景下，RSI 类架构的价值尤其明显。它把互连和调度纳入整体设计，而不是等模型跑慢了再手动调通信参数。实际效果体现在：同样规模的集群，训练吞吐更稳定，GPU 利用率更高。

4.2 在线推理：延迟、吞吐、FP8 与 FP16 权衡

推理场景和训练关注点完全不同。训练追求长时间高吞吐，推理则对首 token 延迟和稳定吞吐有硬要求。

很多推理框架支持 FP8 量化，因为降低精度能显著提高算力卡的吞吐。但量化后模型效果是否可接受，需要结合具体业务判断。如果业务对精度要求高，宁可保持 FP16 或混合精度，也不要盲目追求 FP8。

在线推理还非常吃“并发控制”和“显存复用”。多路请求同时进来时，架构需要支持 continuous batching 和 KV cache 管理。很多纯 ASIC 架构会在这些细节上做深度优化，这就让推理场景的芯片选型比训练更复杂。

4.3 边缘实时场景：以雷视融合为例

“雷视融合”这类边缘场景对算力的需求和大模型训练完全不一样。它需要把毫米波雷达数据、摄像头视频流和图像识别结果实时融合，通常要求低功耗、低延迟、小体积，并且有可能在无人设备或智能路口部署。

这类场景很少直接用千亿参数模型，而是用轻量化目标检测、多传感器融合算法。算力卡不需要太高的 FP16 峰值，但对视频编解码、图像前处理、多路数据接入有特殊要求。比如一个边缘盒子里需同时处理多路视频流，如果支持硬件级视频编解码，CPU 和 GPU 的压力就会小很多。

边缘算力还有一个实际问题：数据如何传到算力平台。以无人机无线图传为例，影像数据在移动端生成，但真正做分析推理的算力平台可能在云端。视频流需要经过编码、无线传输、解码，再进入推理框架。这个链路里每一步都有延迟积累，硬件再好，网络不稳定也会导致整体效果下降。因此在边缘场景，单看“单颗算力卡 FP16 算力”意义有限，整条数据链路才是核心。

4.4 算力云和私有化部署：成本和交付差异

不少团队会选择在线算力平台部署模型，例如把千亿参数模型跑到云厂商的无服务器训练集群上。这种方式能省去自建机房的运维成本，但也要考虑数据传输、租用费用和平台框架兼容性。

私有化部署则更强调数据隐私和定制能力。比如“算力云 + 私有化部署 + OCR 服务”这类组合，企业希望把关键数据留在内网，但又要利用云端算力做弹性扩展。落地时就要考虑怎么打通内网算力和云算力，有没有统一的调度平台，以及日志监控是否完整。

两类方案不是二选一的关系。很多团队先在线跑通实验，等模型和流程稳定后，再把核心服务私有化。这个过程中，真正决定 TCO（总拥有成本）的往往不是单卡价格，而是软件栈成熟度、运维复杂度和资源利用率。

5. 搭建算力中心之前，先做一次需求倒推

5.1 一个可复用的需求梳理框架

要避免算力浪费，建议从业务需求出发做倒推，而不是先买设备再看怎么用。这个框架可以适用于大多数场景：

1. 明确任务类型 ：训练、推理，还是两者兼顾。
2. 明确模型规模 ：参数数量、训练数据量、推理 QPS 要求。
3. 明确精度需求 ：FP32、FP16、FP8，还是混合精度。
4. 明确并行规模 ：单机 8 卡够不够，是否需要多机集群。
5. 明确网络条件 ：多机间通信是走普通以太网，还是需要 RDMA。
6. 明确运维边界 ：有没有专职算法工程师和运维，是否依赖成熟框架。
7. 明确预算口径 ：硬件采购、电力、机房、网络、软件授权、人力维护都要算。

这套框架的核心，是先搞清楚业务真正需要什么，再映射到芯片架构和组网方案上。很多算力中心“买完就后悔”的原因，往往就是需求倒推没做到位。

5.2 从业务目标反推开硬件配置

如果目标是训练百亿参数模型，通常至少需要多机多卡，对显存容量和卡间带宽都有较高要求。配置时优先考虑能效比和扩展效率，而不是单纯追求单卡 FP16 峰值。

如果目标主要是推理部署，芯片选型更适合从框架兼容性、量化支持度、并发能力和功耗出发。一张支持 FP8 且推理管线成熟的卡，可能比一张理论算力高但生态差的卡更实用。

从经验看，算力卡规格、显存、网络和存储应该作为一个整体来评估。只把 CPU、内存、GPU 堆高，但网卡带宽不够，训练集群依然快不起来。

5.3 算力中心成本估算的常见遗漏项

搭建算力中心需要多少钱，这个问题如果只算硬件设备，答案会非常失真。真正的成本结构通常包括：

• 算力卡和服务器的采购成本。
• 机房机柜、电力、散热和带宽费用。
• 高速网络交换机、网卡、光模块成本。
• 存储集群成本，尤其是大模型训练时的 checkpoint 存储。
• 软件授权、平台开发、运维人力成本。
• 设备折旧和故障更替成本。

很多团队在估算时只写了第一项，最后被后续运维成本压得很被动。建议在立项阶段就把 3 年 TCO 算清楚，这样才能判断“自建算力中心”和“租用在线算力平台”哪个更合适。

5.4 落地前的小规模验证和监控

无论多详细的规划，都要先做小规模验证。先在少量机器上跑通目标模型，记录训练吞吐和扩展效率，再看是否满足业务要求。

训练过程还需要监控整条链路：GPU 利用率、显存占用、功耗、温度、通信带宽、网络延迟、存储 IO。监控数据不是为了截图，而是为了发现瓶颈到底在哪一层。如果 GPU 利用率低，要先区分是计算、访存还是通信问题，再针对性地调参数或改架构。

这类问题通常不能只看硬件监控面板，还要结合训练框架日志、通信库日志和操作系统级指标一起判断。输入、权限、资源、版本，每一项都可能成为隐藏瓶颈。

6. 算力格局会如何被重塑：四个判断标准

6.1 算力密度：单位机房面积里的有效计算能力

未来评价一套算力方案，会越来越多地看“单位机柜内能跑出的有效训练吞吐”，而不是单卡 TFLOPS。算力密度越高，意味着同样面积的机房能承载更多业务。

这就把芯片架构、散热设计、供电方案和互连结构都纳入了考核范围。RSI 类架构通过优化数据流动和资源调度，有机会在同等物理约束下释放更高有效算力。

6.2 资源调度：架构能否处理碎片化算力

在真实集群里，算力往往是碎片化的：有的机器空闲，有的机器跑满；有的卡显存充足，有的卡显存紧张。如果架构不支持弹性调度，算力浪费是必然的。

更好的架构会把这些碎片化资源统一管理，让计算任务按需分配到最合适的位置。这一点在交互式推理、混合负载和高并发场景里尤为关键。

6.3 互连重构：数据移动成本能否被大幅降低

AI 计算中“数据搬运”的成本通常被低估。数据在“计算核心-缓存-显存-网卡”之间每移动一次，都会带来延迟和能耗。从长期看，互连架构创新带来的收益甚至可能大过计算单元本身的制程升级。

这也是 RSI 类架构真正重塑算力格局的地方：把互连从“辅助部件”变成“核心设计对象”。一旦数据能以更低成本流向计算单元，同样的芯片就能跑出更高有效算力。

6.4 软件生态和可编程性最终决定采用率

硬件架构再先进，也要通过软件栈交付给用户。框架、编译器、算子库、并行策略、监控工具是否好用，直接决定团队愿不愿意迁移。

很多自研 NPU 架构失败，不是因为芯片不行，而是软件生态不成熟，开发者完成不了从模型到硬件的全链路适配。未来 RSI 类架构如果只做硬件重构，不做配套软件工具链，很难真正落地。

6.5 RSI 类架构的现实边界

最后要泼一点冷水。RSI 类架构即使按“可重构系统互连与资源调度”的思路来理解，也还处在演进过程中，不是拿来即用的万能方案。

它的落地边界包括：

• 需要软硬件协同设计，周期长、投入大。
• 对用户团队的底层系统能力和并行优化能力要求高。
• 模型、框架和硬件之间存在强绑定，迁移成本不低。
• 不是所有业务都需要系统级互连重构。单卡能跑完的模型，直接把单卡性能调优可能更划算。

所以更合理的姿势是：先判断自己的业务是否真正被通信和调度瓶颈卡住。如果是，再关注 RSI 类架构和它带来的系统级优化能力；如果只是小规模推理或边缘轻量任务，完全不需要在架构层面追求极致。

回到最初的问题：AI 芯片架构是不是会重塑算力格局？我的判断是，会。但真正改变格局的不只是某一个具体 IP 或某张算力卡，而是整个行业从“看单卡数值”转向“看系统效率”的评价方式。RSI 类架构只是这个转向里一个比较有代表性的技术方向。

对普通开发团队来说，最务实的做法不是追着新架构跑，而是先建立一套需求倒推和压测验证的方法。先跑通，再优化，最后再评估要不要重架构。只有这样，当新一代架构真的落地时，你才有足够的数据和判断力去决定，它到底值不值得换。