实测发现：Qwen MoE 模型用 llama.cpp 推理时，E 核反而比 P 核更快
Reddit 用户测试 RTX 5090 + Intel 270K Plus 跑 Qwen 3.5 122b a10b…
一名 Reddit 网友在 r/LocalLLaMA 板块分享了一次对比实验：他使用 RTX 5090 显卡搭配 Intel Ultra 7 270K Plus 处理器（8 个性能核 + 16 个能效核）和 128 GB DDR5-6000 内存，在 Ubuntu 26.04 系统下通过 Docker 运行 llama.cpp，加载 Qwen 3.5 122b a10b（MoE 架构）并开启 GPU+CPU 卸载，意外发现能效核（E-Core）的推理速度反而高于性能核（P-Core）。
测试配置
- 显卡：NVIDIA RTX 5090
- CPU：Intel 270K Plus（8 P-Core + 16 E-Core）
- 内存：128 GB DDR5-6000
- 系统：Ubuntu 26.04，Docker + CUDA 13
- 模型：Qwen 3.5 122b a10b（Unsloth Q6_K 量化）
- 关键参数：-fit on、-n 65536、-c 131072、-b 2048、-ub 2048、--reasoning on、--no-mmap、-t 12、--cache-type-v q8_0、--cache-type-k q8_0
- 核绑定方式：
docker update --cpuset-cpus "0-11" <container>
频率方面，P-Core 最高约 5400–5500 MHz，E-Core 最高约 4700 MHz。
实测结果
在生成 1000 个 token 后，三组配置的速度（t/s）如下：
- 全核 0–23（8 P + 16 E）：19.8 t/s
- 仅 E-Core 12–23：22.7 t/s
- 仅 P-Core + 部分 E-Core 0–11（8 P + 4 E）：15.6 t/s
也就是说，使用全部 12 个 E-Core 时速度最快，而启用 P-Core 后性能不升反降，尤其在 8 P + 4 E 的组合下速度最低。
原因分析与社区背景
楼主指出，CPU 卸载场景下内存带宽是主要瓶颈，因此理论上高频 P-Core 应该更快，但实测结果恰恰相反。社区此前对「是否需要将 llama.cpp 绑定到 P-Core」存在分歧：部分人建议绑定以提升性能，另一些人则认为现代版本已无需手动设置。
可能的原因推测包括：
- P-Core 频率虽高，但核数较少，可能在 MoE 模型路由或权重调度时产生瓶颈；
- E-Core 数量更多，有利于并行处理 MoE 专家激活时的调度开销；
- llama.cpp 的 CPU 卸载路径对核间调度与缓存亲和性敏感，P-Core 的环形总线占用反而拖慢整体吞吐。
小结
此次实验仅来自单一用户、单一硬件组合，结论尚不能直接推广到所有 MoE 模型或所有混合架构 CPU，但提示了一个反直觉的现象：对于 llama.cpp + MoE + GPU+CPU 卸载的组合，单纯追求高频 P-Core 不一定带来最佳推理速度，核数与调度开销可能更值得关注。后续还需更多平台与模型维度的对照测试加以验证。