端侧模型部署与硬件适配

端侧部署的第一个判断不是「这个模型好不好」，而是这台机器的内存带宽和显存够不够。参数量只决定权重占多大，真正决定体验的是每生成一个 token 要把多少字节从内存搬到计算单元。

按顺序定下四个量，顺序反过来就会返工：

1. 量化档位。先看权重压到几 bit 还不塌，再决定 KV cache 和推测解码的草稿输出头要不要单独定精度。Ollama v0.32.4 修的正是 MoE 专家精度不一致导致的解码问题——「整个模型一个档位」这种想法在混合结构上已经不成立。
2. 运行时。llama.cpp / MLX / vLLM 各自吃不同的硬件路径：Apple 芯片上要走 MLX 才拿得到 GPU，消费级 N 卡走 CUDA，纯 CPU 只能靠小模型和低比特硬扛。运行时选错，再好的芯片也是闲着。
3. 卸载与上下文。放不下就得决定哪几层留在显存、上下文开多长。上下文长度直接吃 KV cache，它常常比权重更早把显存打满。
4. 验收指标。用首 token 延迟和稳态 tokens/s 两个数收尾，并且必须在目标设备上实测：同一份模型在 M5 Max 和一台四年前的笔记本上是两个产品。

三个常见误判：

• 拿「跑起来了」当「跑得动」。 交换到磁盘也能出字，但每秒一个 token 的助手没人会用第二次。
• 只测短提示。 长上下文下显存占用和延迟都是另一条曲线，短提示的漂亮数字骗不了真实使用。
• 把端侧当成免费。 省下的是 API 费用，换来的是分发、升级和一堆设备型号的适配成本——这笔账要和「本地与云混合推理架构」一起算。

这项能力的边界很清楚：它止于单机。一旦要为多人同时提供服务，问题就变成排队、批处理和副本数，交给「推理服务容量规划」。