高通7月9日介绍HBC近存计算思路，将AI推理中的存储带宽和数据搬运作为架构设计重点。其基本方向，是让部分数据密集计算靠近存储执行，主加速器继续承担更灵活、复杂的工作，通过分工减少数据跨部件传输。
这个讨论所针对的，并不是所有任务都缺少算力。不同推理环节有不同约束，某些工作能够充分利用并行计算，另一些工作则需要频繁访问模型数据。只有先辨认瓶颈的位置，才有可能解释新架构究竟在改善什么。
数据供应如何影响计算单元的实际利用
模型运行需要将参数与上下文送到相应的计算位置。计算单元具备处理能力，并不代表所需数据总能及时到达。接口、存储组织和访问模式共同决定供应速度，因此单独比较处理器峰值，可能忽略系统等待数据的时间。
这里的带宽与容量也不能互相替代。容量说明能够保存多少信息，带宽则关系到数据移动的速度。一个部署可能同时需要足够空间和及时访问；提高其中一项，并不会自动消除另一项形成的约束。
近存计算改变的是部分工作的放置位置
HBC讨论的核心，是把合适的运算安排到靠近数据的地方，使部分中间处理不必反复跨越较长接口。是否适合这样组织，需要看任务的数据依赖和执行方式，不能简单理解为把所有计算搬进存储。
主加速器与近存部分还需要通过清楚的接口合作。任务如何划分、结果何时返回，以及数据状态怎样保持一致，都会影响实际效率。因此，近存设计既涉及器件组织，也涉及软件如何描述和调度工作。
一个系统可以同时存在不同类型的计算和存储资源。它们的价值在于互相补充，而不是仅凭距离更近就推断全面优于其他方案。架构比较需要落到具体工作负载，才能避免把设计方向误解为普遍性能保证。
从局部带宽走到整个平台仍有条件
若某项计算的数据往返减少，相关能耗和等待有望得到改善，但整体结果还受到其他环节影响。模型调度、输入准备、网络连接和结果处理都可能进入关键路径，局部改进需要放进完整流程重新测量。
对于运行中的服务，响应速度与吞吐量也需要一起观察。不同并发方式和上下文规模，会改变存储与计算之间的压力。只有说明测试条件，才能判断结果适用于何种应用，而不是把一次实验外推为所有部署的表现。
怎样为新存储路线建立有用的比较
天美mv天美更关注能够被复查的评价方法：使用什么模型、任务怎样组织、数据放在哪里，以及比较过程中是否保持相同的服务要求。这些问题比单纯收集峰值指标更接近架构实际要解决的困难。
软件和硬件的结合方式同样值得记录。若某项优化需要调整模型结构或运行流程，就应说明这种调整的适用范围。这样才能分清收益来自器件能力、任务组织，还是两者共同改变后的结果。
高通这篇技术文章为近存计算提供了一种设计解释，后续讨论仍需要围绕产品集成与完整系统展开。把计算放到更合适的位置，是一个明确方向；它能形成怎样的部署价值，则需要由有条件、有对照的工程结果继续回答。