A
Member
在 ARM 开发板或迷你主机上跑本地小模型，大家第一反应是“再量化一档”或“换更小的参数量”。现场更常先撞上的是内存带宽和温度：刚开始 token/s 还像样，两三分钟后明显变慢，或一加长上下文就到交换分区。这和云上 A100 的体验不是同一类瓶颈。
先把测量拆开。记录预填充（prompt processing）和生成（decode）的速度、驻留内存、以及这两三分钟里 CPU/NPU 频率有没有掉下来。很多板子没有独立的高带宽显存，权重、KV cache 和操作系统页面缓存在抢同一条 DRAM。上下文一长，KV cache 膨胀，看起来像“模型变笨变慢”，其实是在挤内存。用能看频率和温度的接口对照时间轴，比只看平均 token/s 有用。
再看量化收益有没有被内存子系统吃掉。权重量化能缩小体积，但 decode 阶段往往是带宽墙；如果 KV 仍是较高精度、线程数又超过大核数量，多出来的小核只会让缓存更乱。大小核上把推理线程钉在大核，并避免同时跑下载、编译或浏览器，有时比再砍一档量化更明显。
建议把“模型名、量化、上下文、线程、开始一分钟和第五分钟的速度、温度和是否掉频”写成一张表再比较不同模型。只比较参数量，很容易把一块过热的板子判定成“这个模型不行”。
先把测量拆开。记录预填充（prompt processing）和生成（decode）的速度、驻留内存、以及这两三分钟里 CPU/NPU 频率有没有掉下来。很多板子没有独立的高带宽显存，权重、KV cache 和操作系统页面缓存在抢同一条 DRAM。上下文一长，KV cache 膨胀，看起来像“模型变笨变慢”，其实是在挤内存。用能看频率和温度的接口对照时间轴，比只看平均 token/s 有用。
再看量化收益有没有被内存子系统吃掉。权重量化能缩小体积，但 decode 阶段往往是带宽墙；如果 KV 仍是较高精度、线程数又超过大核数量，多出来的小核只会让缓存更乱。大小核上把推理线程钉在大核，并避免同时跑下载、编译或浏览器，有时比再砍一档量化更明显。
建议把“模型名、量化、上下文、线程、开始一分钟和第五分钟的速度、温度和是否掉频”写成一张表再比较不同模型。只比较参数量，很容易把一块过热的板子判定成“这个模型不行”。