2026年7月，我拿到一台搭载 Lunar Lake Core Ultra 7 258V 的轻薄本：64GB统一内存，NPU标称48 TOPS。目标是加载一个20B dense模型。第一次启动，进程直接OOM，系统日志里连交换空间都被打满。
这次失败比跑分更有用。20B模型能不能留在本地，先看三笔占用：权重、KV cache和运行时。它们装不下，48 TOPS没有发挥的机会。
48 TOPS解释不了内存账
《2026年的AI PC与NPU：它们真的能跑本地AI吗？》提醒了一个容易被宣传页掩盖的问题：本地推理经常卡在内存带宽，而不是峰值TOPS。
按这次测试记录，Lunar Lake的内存带宽约120 GB/s，NPU峰值为48 TOPS（INT8）。两者不是一回事。TOPS描述矩阵运算的理论上限，模型每生成一个token，仍要反复搬运权重和中间数据。
先算权重。20B参数压到INT4，理论占用约10GB；本次所用后端还有约5GB固定开销。KV cache继续往上叠：原测试配置中，上下文长度256时约2GB，512时约8GB。这个增幅受模型结构和后端实现影响，不能直接套到所有20B模型上，但足以解释16GB机型为什么容易撞线。
当模型远大于本次记录中的12MB NPU L2缓存后，内存搬运开始主导延迟。按这组数据估算，20B INT4更现实的吞吐是20—30 tokens/s，而不是100以上。
Intel新闻室公布的测试对象则是MiniCPM4-8B，不是20B。其公开页面列出两组数据：Core Ultra 7 258V的NPU搭配INT4-MIXED-CW-SYM时为1315.89和17.65，iGPU搭配INT4-MIXED-ASYM时为694.60和21.3。公开摘要没有带出列名，因此不能把1315.89直接写成tokens/s。能确认的是，8B模型可以利用NPU加速；它不能证明20B会按TOPS等比例放大。
INT4不是一个开关
我对比过Llama-3.3-20B的INT8和INT4版本。INT8占用约20GB，16GB统一内存无法容纳；INT4约10GB，但MMLU下降了2.3个百分点，代码生成和数学推理中的差异尤其明显。
继续压到2-bit，例如使用AQLM，内存可以降到6—7GB，代价是指令跟随明显变差。这次测试里，它已经不适合当作日常可用版本。
最后留下的是混合精度：大部分层使用INT4，对误差更敏感的层保留INT8。AutoGPTQ可以先从下面这组参数试起：
--group-size 128 --damp-percent 0.1 --sym True
这组参数不是所有模型的通用答案，但比直接套默认INT4更容易复现。量化完成后，仍要用自己的代码、数学和长文本任务做回归测试。INT4与INT8的进一步取舍，也可以对照《2026轻薄本实测：10B模型量化到哪一档最合适》。
模型加载成功，KV cache才开始吃内存
权重成功加载，只过了第一关。对话变长后再次OOM，通常要先查KV cache。
Intel已经公布AI PC端侧支持128K上下文窗口的结果，但“能开128K”不等于每个任务都值得开。上下文越长，KV cache越可能超过模型权重本身。
这次部署用了三种处理办法：
- 模型原生采用GQA时，KV数量已经减少，但长上下文仍要继续压缩。
- 将KV cache量化为INT8。llama.cpp和TensorRT-LLM都支持，本次任务中的精度损失很小。
- 主动限制上下文。任务不需要128K时，不要为了参数好看把窗口开满；4096或8192往往更实际。
把上下文限制到8K后，KV cache从6GB降到1.2GB，总内存占用由16GB降到11GB，模型才在16GB统一内存上稳定运行。这组数同样与具体模型和后端绑定，重点是测真实工作负载，不要只看最大上下文标签。
别让NPU独吞整个模型
Lunar Lake的NPU 5和Strix Point的XDNA 2适合处理矩阵乘法，但在这次OpenVINO、DirectML测试中，GELU、LayerNorm等算子没有全程留在NPU。强行把完整模型交给NPU，部分算子会回退到CPU，结果可能比合理分工更慢。
实际调度可以这样拆：
- 线性层和MatMul映射到NPU，使用其INT4计算单元。
- 注意力模块及MLP的其余部分交给iGPU。
- 输入输出、分词和简单后处理留给CPU。
三路并行时，短时吞吐曾达到30—40 tokens/s。不过这不是持续运行的保底值，计入散热和长时间负载后，稳定结果更接近25—30 tokens/s。
还有一个容易踩的坑：为了省电，在BIOS里关闭CPU的e-cores。这台机器关掉e-cores后反而更慢，因此不建议把关核当成默认调优手段。至于是否由DMA缓冲造成，仅凭这次日志还不能下定论，保持系统默认调度更稳妥。
十分钟后，散热开始决定速度
新浪收录的一份5月29日研报提到，宏碁可能推出面向消费级和商用级的新Copilot+ PC，并关注持续NPU负载下的散热管理。这不是无关紧要的产品描述。
在这台Lunar Lake轻薄本上连续进行10分钟batch推理，NPU温度从55°C升到85°C，随后触发降频，吞吐量接近腰斩。把batch设为1最稳；连续任务之间可以留出短暂停顿，同时提高风扇转速。散热架的作用也比单纯追求更高TOPS直接。
最后留下的配置
| 项目 | 设置 |
|---|---|
| 模型 | 20B dense，例如Qwen2.5-20B |
| 权重量化 | 大部分层INT4，关键层INT8 |
| KV cache | INT8 |
| 上下文 | 8192 |
| 调度 | OpenVINO下由NPU、iGPU和CPU分工 |
| Batch | 1 |
| 散热 | 风扇100%，或使用笔记本散热架 |
在本次测试中，这套配置的内存占用约12—13GB，持续吞吐为25—30 tokens/s。前面出现的30—40 tokens/s更接近短时峰值，不宜当作长期运行指标。
如果还要更长上下文或更高吞吐，64GB型号能增加余量，但不会自动解决算子兼容和调度问题。2-bit可以把模型压到6—7GB，不过这次测试中的指令跟随下降明显，不适合作为默认选择。内存压力的判断方法也可以对照《2026手机端侧3B模型实测》，只是20B把同一个问题放大了。
买AI PC跑本地20B模型，先问三个问题：INT4权重实际多大，常用上下文会生成多大的KV cache，后端能否把算子合理分给NPU、iGPU和CPU。三笔账算清之前，40—50 TOPS的标签回答不了模型能不能跑稳。
