先分清任务的数据流形态
讨论AI芯片架构，容易一上来就比算力数字，但真正决定实际表现的是数据怎么流动。可以先把任务按数据流形态分成几类：一类是权重固定、输入不断变化的推理型负载，数据流以单向流为主；一类是训练型负载，需要频繁读写梯度与中间激活值；还有一类是带时序依赖的负载，前后步骤之间存在强耦合。不同形态对片上缓存容量、访存带宽、并行粒度的要求完全不同。选型时先问一句：这个任务每一步计算需要复用多少数据、复用距离有多远。复用距离短、局部性强的负载，适合把更多资源放在近计算存储上；复用距离长、依赖全局同步的负载，则更依赖互联与显存带宽。把数据流形态画成一张草图，标注输入、权重、中间结果、输出的流向与体积，比看任何规格表都更能暴露瓶颈。
存储层级与互联是隐性成本
架构评估里最容易被低估的是存储层级。计算单元再快，数据供不上就只能空转。可以按“容量—带宽—延迟”三个维度做一张分层表：近计算的小容量高速存储、片上的中等容量缓存、片外的高带宽存储、以及跨芯片的互联通道。逐层估算每一层需要承载的数据体积与访问频次，找出哪一层会成为反复搬运的枢纽。互联同样关键，多芯片协同时，同步开销、通信拓扑、带宽收敛比会直接改变有效算力。判断框架可以这样用：先假设计算资源无限，看数据搬运需要多少时间；再假设带宽无限，看计算需要多少时间；两者取较大者，就是粗略的实际上限。这个上限与标称算力的差距，往往就是架构选型真正要解决的问题。
用可复现的小基准替代大而全的评测
工具选型思路上，不建议追求覆盖全部场景的通用评测，而是构造几个小而可复现的基准：一个访存密集型、一个计算密集型、一个通信密集型。每个基准都记录输入规模、精度设置、批大小与重复次数，并固定软件栈版本。观察指标不只看吞吐，还要看利用率曲线随批大小变化的拐点、长尾延迟、以及资源占用随时间的稳定性。拐点出现得早，说明并行度或缓存不足；长尾明显，说明调度或同步存在争用。把这些曲线留档，形成自己的架构画像，后续换型时可以直接对比，而不必依赖外部结论。检查清单可以包括：数据流草图是否完成、存储分层表是否量化、互联假设是否写明、基准是否可复现、指标是否包含拐点与长尾、软件栈版本是否锁定、结论是否标注适用边界。凡是无法复现的评测结果，都只作为线索，不作为决策依据。
