从工作负载反推架构需求
讨论芯片架构，容易从参数表开始，但参数只在特定负载下才有意义。正确顺序是先刻画工作负载：计算密集型还是访存密集型、批处理规模分布如何、序列长度或输入尺寸的典型区间是什么、延迟敏感还是吞吐优先。不同负载对架构的要求截然相反，一个为高吞吐设计的宽并行结构，在低延迟小批量场景下可能大量空转。
刻画负载时建议用分布而非单点：给出典型区间和长尾情况，观察架构在长尾处是否崩溃。很多架构在平均情况下表现良好，在极端输入下出现存储溢出或调度失衡。评估时把长尾作为独立场景，比只看峰值指标更有参考价值。
存储层次与互联是真正的分水岭
算力单元的数量相对容易堆叠，难的是让数据及时到达。评估存储层次要看四点：片上缓存的容量与带宽是否匹配计算单元的消耗速率；层次间的数据搬移是否有足够的重叠能力；访存模式变化时是否会出现严重的利用率下降；外部存储的带宽与容量是否与整体吞吐匹配。任何一环成为瓶颈，算力数字都会失去意义。
互联同样关键。多单元协同时，通信开销会随规模上升而放大，评估时要看拓扑结构对常见通信模式的适配度、同步机制的代价、扩展后效率的衰减曲线。一个在少量单元时效率很高的设计，扩展到更大规模后可能因通信占比上升而收益递减。评估互联不应只看峰值带宽，而要看在真实通信模式下的有效利用率。
验证路径与工程可行性
架构评估不能只看理论效率，还要看工程可行性。软件栈的成熟度决定开发者的迁移成本；编译与调度能力决定实际性能能达到理论值的几成；调试与可观测手段决定问题定位效率。这些因素在早期容易被忽略，却往往是落地阶段的主要障碍。
验证建议分三步：先用代表性负载做仿真，观察瓶颈分布；再用小规模原型验证关键假设，尤其是存储与互联的假设；最后用端到端场景检验整体效率，包括数据准备、调度、后处理等环节。每一步都要设定明确的否决条件，避免在错误方向上持续投入。架构方法论的核心不是追求单项最优，而是在算力、存储、互联、软件之间找到与目标负载匹配的平衡点，并清楚知道这个平衡点在什么条件下会失效。
