实验结果 (M5 / 32GB RAM)#

测试模型：Gemma4-26B-A4B-it-nvfp4（4-bit 量化，激活权重 ~3.85GB）。

场景 基线 调优后 提升 瓶颈分析
短文本生成 (256 tok) 38.18 tok/s 39.75 tok/s +4.1% 带宽瓶颈：已达硬件理论极限
长文本重复查询 (11k tok) 14.59s 2.27s +540% IO 瓶颈：Hot Cache 消除磁盘加载

瓶颈逻辑：为什么我把 39.7 tok/s 当作接近上限的参考值？#

Decode 阶段性能由内存带宽决定：每生成一个 token，都要把激活权重从内存完整读一遍。

  • MoE 激活：Gemma4-26B-A4B 单步仅激活 4B 专家参数，约 3.85 GB（nvfp4 量化后）。
  • 硬件带宽：M5 标准版 153 GB/s。
  • 理论上限：153 GB/s ÷ 3.85 GB ≈ 39.7 tok/s

这次实测到 39.75 tok/s，已经很接近按带宽估出来的上限。至少在这组测试条件下，软件层面的调参看起来不太容易明显越过这条线。

优化策略 (针对 32GB 机型)#

1. 内存硬锁定# 

sudo sysctl iogpu.wired_limit_mb=26000

确保 ~13.5GB 权重与 KV Cache 全部常驻物理内存，避免 macOS 换出（Swap）导致的延迟波动。

2. 内存热缓存 (Hot Cache)# 

--hot-cache-max-size 4GB

将最近使用的 Prefix Cache 从磁盘（SSD）搬进内存。按这次实验结果看，这是 6.4 倍加速 里最主要的因素，让重复查询的 PreFill 耗时降至毫秒级。

3. 调度优化#

  • --max-concurrent-requests 2：降低单人场景下的内存碎片。
  • --initial-cache-blocks 1024：预分配支持 16k token 的 Paged Attention 缓存块，消除运行时动态申请内存的开销。

跨机型 decode 上限参考#

同一模型（Gemma4-26B-A4B，激活 ~3.85 GB），带宽直接决定理论上限：

芯片 带宽 理论上限
M1 标准版 68.3 GB/s ~17.7 tok/s
M5 标准版 153 GB/s ~39.7 tok/s
M5 Pro 307 GB/s ~79.7 tok/s
M3 Max 409 GB/s ~106.2 tok/s

如果还想明显提高 decode，通常还是得看更高带宽的芯片；至少在我这次测试里，单靠软件调优暂时没观察到太大空间。

链接#