文章回顾了Karpathy在2023年指出的本地LLM推理瓶颈：解码阶段受限于内存带宽，每次前向传播只生成一个token，使得推理速度存在硬上限。以M5芯片和4-bit Qwen3.5 9B为例，理论极限约29 token/s，llama.cpp和MLX接近该上限。开源推理引擎Uzu通过组合优化突破瓶颈：采用4-bit/8-bit整数量化降低内存流量，利用M5的int8硬件加速路径，在量化前应用块对角随机Hadamard变换抑制离群值误差，并通过推测解码一次性验证多达16个草稿token。实测Uzu在M5上达到92-117 token/s，显著超越llama.cpp和MLX。
文章系统讲解了 LLM 推理中四层常被混淆的缓存机制：KV cache 存储单次请求的注意力张量；Prefix caching 在服务端以 token ID 哈希链为键复用这些张量；Prompt caching 是服务商对该查找的计费版本；Semantic cache 则以嵌入向量的余弦相似度为键存储完整响应。前三层为精确匹配、不影响正确性，未命中只损失延迟和费用；第四层为模糊匹配，可能返回错误答案。文章基于 transformers v5 提供可运行代码示例，涵盖缓存增长、内存带宽瓶颈、GQA/MLA/量化等优化手段，以及阻碍缓存复用的五类常见问题。
作者在一台单通道 16GB 内存、无独显的 Ryzen 5 5600G 台式机上，使用 llama.cpp 官方版部署 Ling-3.0-tiny（Q4KM 量化），实测生成速度 21.70 tok/s，比配置更强的 64GB+3090 机器快近 4 倍。经排查，差异源于推理引擎版本而非硬件。文章还分析了该模型线性注意力架构带来的超低上下文内存开销（约 6.79 KiB/token），总结了思考模式、Windows 编码、线程设置三个实践坑，并给出三步部署教程，证明普通电脑即可流畅本地运行该模型。
本文从硬件原理出发，解释了GPU为何在运行大模型时算力利用率低的现象。核心在于计算与内存带宽之间的不对称：算术操作便宜，而数据搬运昂贵。GPU通过大量简单计算单元和线程级并行来掩盖内存延迟，但受限于内存带宽，导致实际token生成速度远低于理论算力。文章还介绍了warp、分支分歧、内存延迟隐藏等概念，并指出性能优化技巧（如量化、投机解码、连续批处理）的本质是减少数据移动。
