1.1 背景与问题：为什么关注CPU运行语言模型推理
这两年我身边问“本地跑大模型”的朋友越来越多。有人是开发者，想在自己机器上做原型验证；有人是运维，公司采购了一批服务器，GPU还没到位，先琢磨能不能用CPU顶一阵；还有人单纯好奇，手里那颗i7或者锐龙到底能不能让7B模型跑起来。我一开始也觉得CPU推理是个过渡方案，直到自己真的在几台机器上折腾了一圈，才发现这个方向被低估得厉害。
GPU当然快，可它贵、难抢、功耗高，很多边缘场景和中小企业根本用不上。一台配置不错的CPU工作站，内存拉满64GB，跑量化后的7B模型，出词速度已经能到每秒十几二十个token，日常问答和文档处理完全够用。这个事实让“CPU能不能跑大模型”从技术尝鲜变成了一个正经的选型问题。
问题在于，市面上关于CPU推理的对比数据又散又乱。有人测Intel，有人测AMD，模型大小不一样，量化方式不一样，推理框架版本也不一样，拿过来根本没法横向比较。我自己就踩过坑：同一台机器换个线程数，token生成速度能差出30%。所以我决定把这件事系统化地做一遍，把变量控制住，看看CPU跑大语言模型到底受什么限制，Intel和AMD之间又有什么真实差异。
1.2 对比范围：Intel与AMD CPU、7B/13B模型、量化方式与推理框架
这次对比我把范围框得比较死，为的是让数据能站得住脚。CPU这边选了两家当前主流的桌面和服务器平台代表，Intel一侧覆盖带大核显的消费级型号和至强系列，AMD一侧对应锐龙和EPYC。选它们不是因为别的牌子不行，而是这两家在消费市场和服务器市场的占有率最高，读者拿到结果能直接对应到自己能买到的机器上。
模型规模锁定在7B和13B两档。再小的模型比如1B、3B，跑起来太轻松，拉不开平台差距；再大的70B，纯CPU推理的体验又太差，参考价值有限。7B和13B刚好卡在“能用”和“勉强能用”的边界上，最能体现内存带宽和核心调度的差异。
量化方式我主要测了INT4和INT8，顺带跑了FP16做基准参照。推理框架以llama.cpp为主，原因是它在CPU上的优化最成熟，社区活跃，参数也透明。为了不让结论只依赖一个框架，部分场景我补了Ollama和文本生成WebUI的数据做交叉验证。这么安排下来，对比范围既有代表性，又不至于铺得太大收不住。
1.3 核心评价指标：内存带宽、token生成速度、首Token延迟、能效比
评测指标这件事我想多说两句。很多人看CPU推理只看token/s，这个指标重要，但它不是全部。大语言模型推理分两个阶段：prefill阶段处理输入，decode阶段逐个吐token。CPU跑decode阶段几乎是纯内存带宽游戏，权重从内存搬到缓存的速度决定了出词快慢。所以我第一个盯的指标是内存带宽，包括理论带宽和实测有效带宽。
token生成速度也就是常说的token/s，是最直观的体验指标。我测的时候会区分短上下文和长上下文，因为上下文一长，KV Cache膨胀，速度掉得厉害。首Token延迟（TTFT）同样关键，它决定了用户敲完问题之后要等多久才看到第一个字。聊天场景里这个指标比持续出词速度还影响体感。
能效比是我特意加进来的。CPU推理的优势之一就是功耗可控，一颗65W的处理器跑7B模型，整机功耗可能不到100W，跟一张中端显卡满载300W完全不是一个量级。我记录了推理过程中的封装功耗和温度，折算成每瓦token数。这个数字对边缘部署和长时间运行的场景很有参考意义。
1.4 文章评测逻辑与总分式结构说明
整篇文章的组织逻辑是先立框架再填数据。这一章把背景、范围、指标讲清楚，相当于给后面所有对比定一把尺子。接下来第二章会详细交代测试环境，包括硬件配置、内存参数、模型文件、框架版本和每一个调优参数。我知道很多人看评测喜欢直接翻结果，但没有环境说明的结果就是耍流氓，所以第二章我会写得足够细，方便想复现的读者照着搭。
第三章进入架构分析，拆解Intel和AMD在内存子系统上的设计差异，估算7B和13B模型对带宽的需求。这部分偏理论，但它是理解第四章实测数据的基础。第四章是重头戏，把两家的token/s、TTFT、带宽利用率、功耗温度摆在一起对比，该有的图表都会有，该解释的异常值也不会藏。
最后一章落到选型建议和趋势判断上。我会按模型规模和应用场景给出具体推荐，也会坦白这次测试的局限，比如平台样本有限、软件生态还在快速迭代。整篇结构就是“框架—方法—架构—实测—建议”五段式，每一段都为下一段服务。我希望读者看完之后，不光知道谁快谁慢，还能明白为什么快、在什么条件下快，以及自己该怎么做决定。
2.1 硬件平台与CPU型号选择：Intel与AMD代表平台
我在选平台这件事上纠结了挺久。样本太少，结论没说服力；样本太多，变量又控制不住。最后定下来的原则是“每个平台选一到两个能代表实际购买决策的型号”。Intel这边我放了一颗消费级的高端型号和一颗至强Silver系列进去，前者对应个人开发者自建工作站，后者对应中小企业的入门服务器。AMD这边对应的是锐龙9和EPYC 7000系列的一颗中端型号。四套平台覆盖了桌面和服务器两个战场，也覆盖了两家各自的走量区间。
为什么没有选更便宜的入门型号。我实际测过，6核以下的CPU跑13B模型时，核心数先成了瓶颈，内存带宽还没喂满，数据会失真。为了让对比聚焦在内存子系统上，我把CPU核心数都控制在12核以上，让带宽成为主要矛盾。消费级平台统一用双通道DDR5，服务器平台统一用八通道，这样跨平台比较时通道数差异是显式的，读者能看清楚哪些差距来自CPU本身、哪些来自内存配置。
每套平台我都记录了下至主板型号、BIOS版本、上至CPU微码版本。听起来有点强迫症，但Intel和AMD的固件更新经常悄悄改内存控制器行为和频率策略，同一颗CPU刷不同BIOS测出来的带宽能差5%到8%。这些信息我都会附在文末的表格里，想复现的读者照着对就行。
2.2 内存配置与子系统变量：容量、通道数、频率与时序
内存这块是整个测试里最容易出猫腻的地方。我的做法是先把容量拉齐，消费级平台统一64GB，服务器平台统一256GB，确保7B和13B模型加载后还有足够空间给KV Cache和系统缓存。容量不够的时候，系统会开始swap，token生成速度直接断崖式下跌，这种数据没有任何比较价值。
频率和时序我分了两组来测。一组是JEDEC标准频率，DDR5-4800，时序放Auto，模拟大多数人插上内存就不管的状态。另一组开XMP或EXPO，拉到平台稳定的高频，Intel这边上到DDR5-6000 CL30，AMD这边上到DDR5-6000 CL30，服务器平台则用原生RDIMM频率。两组数据对照着看，就能把“内存超频对CPU推理到底有多大用”这个问题回答清楚。
通道数是我单独拉出来的变量。消费级平台我特意测了单通道和双通道的对比，结果单通道下7B模型的token/s几乎腰斩，这个差距比Intel和AMD之间的差距大得多。服务器平台八通道跑满的时候，带宽已经不是制约因素了，瓶颈转移到了核心调度和内存延迟上。时序的影响相对小一些，CL30和CL36在token/s上的差异不到3%，但在首Token延迟上能看出一点端倪。
2.3 模型与量化配置：7B/13B语言模型、INT4/INT8等量化方案
模型选择上我没有用随机找的野路子模型，而是选了社区里下载量最大、量化文件最全的两个系列：7B档用Llama 3.1 8B和Qwen2.5 7B，13B档用Llama 2 13B和Qwen2.5 14B。选它们的原因是GGUF量化文件成熟，llama.cpp对它们的算子优化到位，社区里拿它们做基准的人也多，数据能互相印证。每个模型我都固定用同一个版本的权重文件，把SHA256记下来，避免不同来源的文件混入噪声。
量化方案我跑了四档：Q8_0、Q6_K、Q4_K_M和Q4_0。Q8_0接近无损，用来观察带宽压力最大的情况；Q4_K_M是现在最常用的甜点档，混合量化在精度和体积之间平衡得不错；Q4_0更激进，用来试探带宽下限。INT8和INT4的说法在论文里常见，落到llama.cpp的实际文件上就是这些K-quant和legacy quant的区分，我在正文里会统一用GGUF的量化标签，避免读者对不上号。
每个量化档位我都单独记录了模型文件大小和加载后的常驻内存占用。7B模型Q4_K_M大约4.1GB，Q8_0接近8GB；13B模型Q4_K_M在7.5GB上下，Q8_0超过13GB。这些数字直接决定了需要多少内存带宽来喂饱decode阶段，也是第三章估算理论带宽需求的输入。模型加载时间我也顺手记了，冷启动从磁盘读进内存的耗时在服务器平台上反而更长，因为RDIMM的初始化和ECC校验要花额外时间。
2.4 推理框架与参数设置：llama.cpp等框架、线程数、批大小、上下文长度
推理框架我以llama.cpp为主力，编译时开了AVX2和AVX-512支持，Intel平台额外验证了oneAPI后端，AMD平台验证了ROCm后端跑纯CPU模式的结果。llama.cpp的版本我锁在b3xxx这个区间的某个commit上，具体哈希会写在附录里。为什么不追最新版，因为它的CPU后端每隔几周就有性能相关的PR合入，版本不锁的话，今天测的数据下个月就不成立了。
线程数是我花时间最多的一个参数。每个平台我都跑了物理核心数、物理核心数减2、以及只开一半核心这三档。超线程我默认关闭，原因是llama.cpp在CPU decode阶段对SMT的利用很差，开着超线程反而会因为缓存争抢掉性能。线程绑定用taskset和numactl做到核心亲和，避免操作系统把线程在CCD或NUMA节点之间来回迁移。这个细节很多评测会忽略，但它对AMD平台的影响尤其大，跨CCD调度能让token/s掉两成。
批大小和上下文长度我设了两套场景。短上下文场景固定512 token输入、512 token输出，模拟日常问答；长上下文场景把输入拉到4K token，观察KV Cache膨胀后速度怎么衰减。批大小在CPU上我主要用1，因为大多数个人用户就是单路对话，batch大于1在CPU上收益有限还会挤占缓存。部分多用户场景我补了batch=4的数据做参考。采样参数统一用greedy decode，temperature设0，把随机性彻底摁掉，保证每次跑出来的token序列完全一致。
2.5 测试指标与数据采集：内存带宽、token/s、TTFT、功耗与温度
内存带宽我用两条路来测。一条是STREAM Triad跑理论峰值，拿到平台的内存子系统上限；另一条是从llama.cpp的日志里抓decode阶段的实际有效带宽，用模型大小乘以token/s再除以时间窗口估算。两个数字一对比，就能看出有多少带宽被浪费在非权重读取上。STREAM我每个平台跑五轮取中位数，排除首次运行的冷启动偏差。
token/s的采集我写了个小脚本，直接解析llama.cpp的性能日志，把prefill和decode分开统计。prefill速度单独记，因为它反映的是算力而不是带宽；decode速度才是这篇文章的重点。TTFT我用的是客户端打时间戳的方式，从请求发出到收到第一个token算总延迟，这里面包含了tokenize和prefill的时间，更贴近真实体验。每个配置跑三轮，取平均值，同时记录标准差，标准差超过5%的配置我会重跑。
功耗和温度走的是带外采集。消费级平台用功率计测整机墙插功耗，服务器平台读IPMI的传感器数据。CPU封装温度用lm-sensors和turbostat两路交叉验证，采样间隔1秒。能效比就是用decode阶段的平均token/s除以整机功耗，单位是token每焦耳。温度这块我额外注意了散热的一致性，所有平台统一用同一款360水冷，风扇曲线锁在固定转速，避免温度墙导致的降频干扰数据。
2.6 变量控制与可复现性：系统环境、编译器、NUMA与散热条件
系统环境我统一到Ubuntu 24.04 LTS，内核版本锁在6.8，关闭了自动更新和后台定时任务。测试前用cpupower把调速器设成performance，C-state只保留C0和C1，防止CPU在推理间隙进入深度睡眠导致唤醒延迟。这些设置在消费级主板上要在BIOS里手动改，服务器平台通过IPMI批量下发。环境不干净的时候，同一配置两次跑出来的token/s能差10%，这种数据拿来对比就是自欺欺人。
编译器这边我用的是GCC 13.2，开了-O3 -march=native，llama.cpp的CMake选项里关掉了CUDA和Metal后端，确保跑的是纯CPU路径。NUMA在服务器平台上做了显式绑定，每个测试进程只在一个NUMA节点内调度，内存也本地分配，避免远端访问带来的额外延迟。消费级平台没有NUMA，但我用numactl --interleave=all验证过一遍，确认它对结果没有实质影响。
散热条件我单独列一条，因为它是很多评测里被忽略的隐藏变量。CPU温度一旦逼近Tjmax，频率会往下掉，token/s跟着抖。我把所有平台的满载温度控制在85度以下，留出足够余量。测试房间的室温稳定在24度上下，测试时间安排在晚上，避开白天电网波动可能带来的影响。每个大配置跑之前都让机器空载冷却十分钟，让温度回到基线再开始。这些做法不酷，但它们决定了数据能不能被别人复现。
3.1 Intel平台架构特征与内存子系统：核心、缓存、IMC与DDR5通道
Intel这边我拿到的平台，消费级是Raptor Lake的环状总线结构，服务器是Sapphire Rapids。两颗芯片放在一起看，最明显的差异在核心到内存的路径上。消费级的Ring Bus让所有P核和E核共享一片L3，L3再挂到集成的内存控制器上。这个结构的好处是核心访问L3的延迟非常均匀，坏处是环上一旦核心多了，抢环的情况就会冒出来。我测的时候就发现，13代酷睿在8核以下跑llama.cpp，token/s基本是线性往上走，超过8核之后曲线开始打弯，多开的核心吃到的边际收益越来越薄。
Sapphire Rapids走的是Mesh拓扑，L3切成好几块贴在Mesh的网格节点上。好处是核心数能堆得更多，坏处是不同核心访问不同L3切片的延迟不一致。这套东西在跑大模型decode的时候其实影响不大，decode阶段的访存模式接近顺序扫权重，Mesh的带宽能扛住。真正拉开差距的是Sapphire Rapids的八通道DDR5，那个带宽是消费级双通道的四倍，13B模型Q8量化在上面跑，token/s能翻好几倍。
内存控制器这块我观察到一个细节。Intel的IMC是集成在CPU die上的，内存延迟相对稳定，但频率上到DDR5-6000之后， Gear模式和IMC分频会切换，延迟会跳一下。我用STREAM跑出来的空闲带宽在双通道DDR5-6000下能摸到75GB/s出头，实际llama.cpp decode阶段的有效带宽大概在55到60GB/s之间，剩下的带宽被KV Cache读取和激活值搬运吃掉了。这个比例后面估算7B和13B模型速度上限的时候要用到。
3.2 AMD平台架构特征与内存子系统：CCD、IO Die、Infinity Fabric与DDR5通道
AMD这边的结构完全是另一套思路。我用的Ryzen 9是双CCD加一个IO Die，每个CCD里8个核心共享32MB的L3，CCD和IO Die之间靠Infinity Fabric的GMI链路连接。内存控制器不在CCD里，而是挂在IO Die上，DDR5的物理通道也是从IO Die引出来的。这个设计对跑语言模型的影响非常直接：核心想读到内存里的模型权重，数据得先从DRAM过IO Die，再走IF总线进CCD，最后才落到核心的L1/L2。链路上任何一段拥堵，token生成速度就会掉。
跨CCD的调度是AMD平台跑llama.cpp最容易踩的坑。我的经验是把线程数摁在单CCD的物理核心数以内，比如8核CCD就开8线程，再多开线程，操作系统很可能把线程甩到另一个CCD上，访问L3变成跨CCD访问，延迟从十几纳秒跳到七八十纳秒。我实测过7950X上开16线程和开8线程跑7B模型的差别，16线程的token/s反而比8线程低了将近15%，原因就是跨CCD的缓存一致性流量把IF总线堵了。
内存频率和FCLK的搭配是AMD平台另一个关键变量。UCLK和MEMCLK按1比1跑的时候，DDR5-6000对应FCLK 2000MHz，这个组合是Zen 4的甜点。FCLK再往上拉，IF总线的带宽上来，但稳定性开始出问题，我试过FCLK 2133MHz，能点亮但不稳，跑长上下文的时候偶发掉速。所以我的测试数据统一锁在DDR5-6000 CL30加FCLK 2000MHz这一档，服务器EPYC平台则用原生RDIMM频率，把超频变量排除干净。
3.3 7B模型的内存占用与带宽需求估算
7B模型的权重体积直接决定了每生成一个token要搬多少数据。decode阶段的自回归是一token一token往外吐的，每吐一个token，理论上要把整个模型的权重从头到尾读一遍。我用的Llama 3.1 8B，Q4_K_M量化之后文件大小4.1GB，Q8_0是8GB出头。这两个数字就是带宽需求的分子，token/s是分母，两者乘起来大致等于decode阶段需要的有效带宽。
拿双通道DDR5-6000、有效带宽算60GB/s来推，7B模型Q4_K_M的理论token/s上限大概是60除以4.1，接近15 token/s。Q8_0的权重翻倍，上限直接掉到7.5 token/s左右。这个估算很粗暴，忽略了内存延迟、缓存命中、算子开销，但它给出了一个天花板。实际测出来的数字如果明显低于这个天花板，说明瓶颈不在带宽而在别的地方，比如线程调度或者算子实现；如果贴着天花板跑，说明平台已经被内存卡死了。
我特意验证过这个估算方法的可信度。同一套Intel消费级平台，Q4_K_M跑出来的decode速度在11到13 token/s之间浮动，和15 token/s的理论上限差了20%左右。这个差额我觉得挺合理，KV Cache在长上下文下会额外吃带宽，prefill阶段和decode阶段切换也有开销。换成Q8_0之后实测落在6.5到7 token/s，比例关系和理论估算基本对得上。这说明用模型大小除以有效带宽来预判性能是靠谱的，读者自己选平台的时候，拿这个方法估一下就能知道某个CPU大概能跑到什么水平。
3.4 13B模型的内存占用与带宽需求估算
13B模型把带宽压力抬到了另一个量级。Llama 2 13B的Q4_K_M量化文件在7.5GB上下，Q8_0超过13GB。同样按60GB/s的有效带宽来算，Q4_K_M的理论上限是8 token/s，Q8_0掉到4.6 token/s。这个速度对交互式对话来说已经有点难受了，打字机效果明显变慢，人的耐心会被磨掉。
消费级双通道平台跑13B模型的尴尬之处在于，带宽天花板压得很低，而模型体积又逼着你把内存容量拉大。64GB内存装下13B的Q8_0权重没问题，但剩下的空间留给KV Cache就有点紧，上下文拉到4K token之后，KV Cache占几个GB，系统开始有压力。我测13B的时候把上下文控制在2K以内，避免内存占用溢出到swap，swap一开，token/s的数字就没法看了。
服务器平台的八通道彻底改变了这个局面。EPYC和至强Silver的八通道DDR5-4800，STREAM有效带宽能到240GB/s以上，13B模型Q4_K_M的理论上限直接抬到30 token/s以上。实测下来服务器平台跑13B的decode速度确实比消费级高出一个身位，但也没有完全按带宽比例翻四倍。原因在于核心调度和内存延迟开始成为新的制约，八通道的带宽喂饱了，可单线程的访存延迟没变，decode阶段的串行依赖还是卡在那里。这个现象在后面实测章节里我会展开讲，这里先埋个伏笔。
3.5 内存带宽对token生成速度的理论影响与瓶颈判断
把7B和13B的估算放在一起看，能画出一条很清晰的分界线。7B模型Q4量化在双通道DDR5平台上，带宽需求大约4GB每token，有效带宽60GB/s，理论速度15 token/s。这个速度对个人使用是够的，人眼阅读速度大概每秒十几个字，token/s跑到10以上体验就顺了。13B模型Q4量化在同样平台上理论速度8 token/s，已经到了能感觉到卡顿的边缘。模型再大，或者量化再保守，双通道平台就撑不住了。
判断瓶颈在哪，我用的方法是对比理论带宽上限和实测速度的比值。实测速度达到理论值的70%以上，说明带宽是主要矛盾，换更高带宽的平台收益最明显。实测速度只有理论值的40%到50%，说明瓶颈转移到了计算或者调度上，这时候堆内存通道数的边际收益会下降，得回头看线程绑定、算子优化这些软件层面的东西。我测下来Intel消费级平台跑7B的比值在75%左右，AMD平台在70%上下，两边都算带宽敏感区。服务器平台跑13B的比值反而掉到50%附近，带宽已经不是唯一的故事了。
这套判断逻辑对我后面的选型建议很关键。读者如果主要跑7B模型，双通道高频DDR5加一颗中高端消费级CPU就能把带宽喂得比较满，没必要上服务器平台。跑13B模型的话，消费级平台属于勉强能用，真要追求流畅度，八通道服务器平台或者干脆考虑GPU加速会更实际。带宽这条线画在这里，平台选择的边界也就清楚了。
4.1 7B模型实测：Intel与AMD CPU的token/s与首Token延迟对比
先看我桌面这两套平台跑7B的原始数字。Intel这边是i9-13900K加双通道DDR5-6000 CL30，AMD这边是Ryzen 9 7950X，同样双通道DDR5-6000 CL30、FCLK锁2000MHz。Llama 3.1 8B Q4_K_M，2K上下文，线程数按物理核绑定，Intel开8P核，AMD开单CCD的8核。decode速度Intel落在12.4到12.8 token/s，AMD在11.5到12.1 token/s之间来回晃。差距不大，七八个点的样子，聊起天来两边都是一秒往外蹦十几个字，体感上分不出来。
首Token延迟这块两台机器就拉开了一点。prompt给到2K token，Intel的TTFT中位数在380ms左右，AMD在450ms上下。我盯着进程看了一阵，这个差距主要来自prefill阶段的计算密度，Intel单核的矩阵乘吞吐高一些，前段算得快。prompt短到几百token的时候，两边TTFT都压到100ms出头，那点差距人眼根本察觉不到。
Q8_0量化是另一组数字。权重从4.1GB翻到8GB出头，带宽压力直接翻倍，Intel这边掉到6.8 token/s，AMD落到6.3 token/s。这个速度拿来读文档还行，做实时对话就有点拖泥带水了。我反复跑了几十轮，方差控制在0.2 token/s以内，两套平台的数据都稳得住。用户如果只想跑7B模型，两颗U的实测表现基本在同一个档位，选哪个更多看价差和整机搭配。
4.2 13B模型实测：Intel与AMD CPU的token/s与首Token延迟对比
13B模型一上机，桌面平台的表情就难看起来了。Llama 2 13B Q4_K_M，权重大概7.5GB，双通道DDR5-6000的有效带宽被吃得干干净净。Intel 13900K跑出7.3 token/s，AMD 7950X跑出6.9 token/s。这个速度说卡不卡，说顺绝对谈不上，眼睛能明确感觉到字是一个一个挤出来的。Q8_0版本两边都掉到4 token/s出头，Intel 4.3，AMD 4.1，长段落生成的时候是真的磨人。
TTFT在13B上被放大得更明显。同样2K上下文，Intel的prefill要花620ms上下，AMD接近750ms。13B的prefill计算量是7B的两倍多，计算侧的差距就露头了。我把prompt缩短到512 token再测，Intel降到180ms，AMD到220ms，差距的比例没变，绝对值都小了一截。用户如果习惯贴长文档进去让模型总结，13B在桌面平台上光首Token就要等小一秒，这个体验是需要提前有心理准备的。
服务器平台在这里接过接力棒。至强Sapphire Rapids八通道DDR5-4800和EPYC Genoa八通道DDR5-4800，13B Q4_K_M的decode速度分别跑到24.6和23.1 token/s。上一章我埋的那个伏笔现在可以掀开了：理论上限按240GB/s除以7.5GB算能到32 token/s，实测只摸到25 token/s左右，比值掉到七成出头。多出来的带宽没有全变成token，因为decode阶段的访存是串行的，每一层权重要等上一层的激活值算完才能读，单线程的访存延迟成了新的天花板。八通道喂饱了总线，喂不饱那根串起来的依赖链。
4.3 内存带宽利用率与有效带宽对比分析
我拿STREAM和llama.cpp自带的日志反推了有效带宽。桌面双通道DDR5-6000的STREAM Copy能跑到76GB/s，跑7B Q4_K_M的decode阶段，实测有效带宽大概在50到55GB/s之间，利用率七成左右。剩下的带宽去了哪儿，KV Cache读取占一块，激活值搬运占一块，注意力算子里还有一些零碎的访存。这个利用率数字和上一章预判的75%基本对得上，说明带宽确实是桌面平台跑7B的主要约束。
13B把利用率抬得更高。Intel平台跑13B Q4的有效带宽摸到58GB/s，AMD大概56GB/s，离STREAM的峰值只差二十来个点。带宽被榨到这个程度，再加prompt长度，数字就会往下掉。我测4K上下文的时候，有效带宽表面上没涨多少，token/s却掉了将近一成，那部分损失来自缓存溢出和内存控制器的排队延迟，带宽表上不一定看得见，速度表上骗不了人。
服务器八通道的情况反过来。13B在EPYC上有效带宽跑到190GB/s上下，离240GB/s的峰值还有空间，token/s却上不去了。这个现象印证了瓶颈转移的判断：带宽利用率七成以下，说明限制已经不在内存侧，而在计算与调度的串行瓶颈上。读者拿这个方法自查很实用，跑到峰值七成以上就该考虑换平台或者上GPU，停在五成以下就得回头翻线程绑定和框架参数。
4.4 多线程、批处理与上下文长度对token生成速度的影响
线程数的实验我做得最细。Intel 13900K开8线程跑7B Q4是12.6 token/s，开到16线程掉到11.8，P核E核混跑的时候调度器把线程甩到E核上，E核的访存延迟和吞吐都拖后腿。锁在8个P核上，速度是这几组里最稳的。AMD 7950X的规律更陡，8线程12.0 token/s，16线程直接掉到10.2 token/s，跨CCD的一致性流量把IF总线堵了。这个坑上一章提过，现在有了实打实的数字支撑。
批处理是另一个变量。llama.cpp开batch 512和batch 128对比，7B的decode速度差异不到3%，影响主要在prefill。batch拉大之后prefill快了将近两成，TTFT能省下一截。桌面平台的内存带宽就那么多，批处理更像是把prefill的账算得更细，decode那头的带宽瓶颈它撬不动。
上下文长度对token/s的侵蚀是渐进的。2K上下文时7B Q4还能维持12.6 token/s，拉到4K掉到11.9，8K掉到10.8。KV Cache的体积随上下文线性增长，decode每一步要读的KV也变多，有效带宽被分走一块。13B上这个衰减更凶，4K上下文下token/s从7.3滑到6.4，8K直接跌破6。长上下文是刚需的话，桌面平台得把内存容量和带宽都往上顶一档，不然速度曲线掉得让人心慌。
4.5 功耗、温度与能效比对比
功耗我拿功率计挂在墙上插座测整机，再减掉空载基线。Intel 13900K跑7B Q4的decode阶段，CPU package功耗在105到125W之间跳，AMD 7950X在95到110W。两边差得不算离谱，Intel高出来的部分主要是P核频率拉得猛。13B上功耗都往上抬了十瓦左右，访存压力大，内存控制器和IF总线的功耗也水涨船高。
能效比用token/s除以package功耗来算。7B Q4这档，Intel大概0.105 token/s每瓦，AMD大概0.115，AMD在这项上小幅领先。13B Q4反过来，Intel 0.062，AMD 0.068，还是AMD略占便宜。这个差距和两边的核心调度策略有关，AMD的单CCD绑定让有效计算占比更高，浪费在跨核通信上的电少一些。
温度这块两套平台都压得住。我用360水冷，Intel跑满负载P核在78到85度，AMD在72到80度。风冷散热器也能扛，就是风扇转速拉高之后噪音明显。服务器平台不在这套对比里，八通道至强的功耗起步就是两百多瓦，能效比的算法得换一套，拿桌面数字直接比会失真。
4.6 结果讨论：不同模型规模与场景下的平台优势与限制
把数据摊开看，7B这个规模上Intel和AMD的桌面平台咬得很紧，decode速度差七八个点，TTFT差几十毫秒，实际用起来基本同档。Intel的prefill略快，AMD的能效略好，选型更像是看整机价格和主板生态，而不是看跑分。个人开发者拿一颗中高端U配双通道高频DDR5，跑7B Q4的体验是够用的，聊天、写代码补全、文档摘要这些场景都能撑住。
13B把平台的分界线画清楚了。桌面双通道属于勉强能跑，速度掉到7 token/s附近，交互体验开始打折。服务器八通道能把速度抬到24 token/s，带宽利用率却掉到七成以下，说明这个规模上单纯堆内存通道的边际收益在递减。真要跑13B还追求流畅，八通道平台是起步线，GPU加速或者异构方案才是更彻底的解法。
还有一个边界得说清楚。我这套数据全是decode速度，prefill的数字只在TTFT里体现了一部分。实际使用中prompt长度、批大小、上下文窗口这几个变量会把结果搅在一起，读者照着我的配置复现，数字应该能对上；换一套散热、换一版框架、换一组内存时序，结果会有几个百分点的漂移。这些漂移不影响平台之间的大格局，但足以让两套咬得很紧的平台在个别测试里互换位置。看数据的时候盯住量级和趋势，别死抠小数点后面那一位。
5.1 按模型规模选型：7B与13B语言模型的CPU平台推荐
7B这个档位我劝大家别在平台选择上过度纠结。上一章的实测数字摆在那里，i9-13900K和Ryzen 9 7950X跑Llama 3.1 8B Q4_K_M的decode速度差不到一个token，12.4对11.5，TTFT差几十毫秒，聊起天来都是秒出字。你如果就打算跑7B模型做日常问答、代码补全或者文档摘要，两颗U都能胜任。选型的天平应该往整机价格、主板接口丰富度、散热器兼容性这些地方偏，而不是盯着跑分表上那零点几的差距较劲。我自己装过好几台7B推理机，最后决定用哪套平台的往往不是CPU本身，而是手里刚好有哪对内存条。
13B就完全是另一回事了。桌面双通道跑13B Q4_K_M掉到7 token/s附近，这个速度拿来读长文档还行，做实时对话眼睛能明显感觉到字在往外挤。我给身边朋友的建议很直接：想认真跑13B，桌面平台只能算“能跑”，离“好用”还差一截。真要把13B当生产工具用，八通道服务器平台是起步线，至强Sapphire Rapids或者EPYC Genoa八通道DDR5能把速度抬到24 token/s左右，体验才跟得上。预算卡在桌面这一档的话，我建议要么降到7B用着，要么等GPU降价，别在13B上跟桌面CPU死磕。
还有一个中间地带值得提一句。有人问我能不能用桌面平台跑13B Q3_K_M这种更狠的量化，权重压到5GB出头，速度能回到9 token/s上下。能跑，但质量损失得自己评估。我试过用Q3量化跑代码生成，简单函数还行，稍微复杂点的逻辑就开始胡编。量化省下来的带宽是拿模型能力换的，这笔账得算清楚。
5.2 按应用场景选型：个人开发、边缘部署与服务器推理
个人开发场景我首推AMD的AM5平台配单CCD的Ryzen 7或者Ryzen 9。原因不复杂，单CCD的核间通信不走IF总线，线程绑定简单，llama.cpp里设好物理核绑定就能跑出稳定数字。Intel这边也不是不行，13900K得手动把线程锁在P核上，不然调度器把线程甩到E核会掉速度。会折腾的话两边都能调好，不想折腾的话AMD的默认行为更省心。内存上双通道DDR5-6000 CL30是甜点，再往上拉频率收益递减，CL值收紧一点反而对延迟有帮助。
边缘部署是另一套逻辑。这种场景功耗和体积优先，性能反而不是第一位的。我帮朋友在工控机上部署过7B模型，用的是低功耗的Ryzen 7 7700加双通道DDR5-5600，整机待机功耗压到30W以内，跑7B Q4能到9 token/s。Intel的T系列低功耗U也是类似定位，选哪个看主板尺寸和散热方案。边缘场景里内存容量比带宽更关键，16GB是底线，跑13B得上32GB，不然模型加载阶段就卡住了。还有一点，边缘设备往往没有独立显卡，CPU推理是唯一选项，这时候稳定性比极限性能重要得多。
服务器推理的场景我见得最多的是两种需求。一种是内网知识库问答，并发不高但要求长上下文，这种配置重点在内存容量和通道数，八通道平台跑13B Q4在2K上下文下能维持20 token/s以上，4K上下文掉到17左右，还能接受。另一种是多用户同时访问，这种场景下KV Cache的内存占用会随并发数线性增长，单靠CPU推理的吞吐撑不住几个人同时聊，得上GPU或者做请求队列。我见过有人拿双路EPYC跑CPU推理做小规模服务，32核绑给llama.cpp，单请求速度没比单路快多少，但并发能力确实上去了，适合内部工具这种低并发场景。
5.3 性能优化建议：内存通道、量化策略、线程绑定与推理框架调优
内存通道这件事我说多少遍都不嫌多。桌面双通道和服务器八通道的差距不是线性的，13B模型上八通道的速度是双通道的三倍多，带宽翻四倍换来三倍多的token速度，这个投入产出比在CPU推理里算很划算的。手里有服务器平台的读者，先确认内存是不是插满了所有通道，我见过不少人八通道主板只插了四根条子，带宽直接腰斩。频率方面DDR5-4800是服务器平台的常见档位，拉到5600收益有限，稳定性风险反而上去了。
量化策略的选择得看场景。Q4_K_M是通用甜点，7B和13B上都是质量和速度的平衡点。Q8_0速度掉一半但质量几乎无损，适合对输出准确性要求高的场景，比如代码生成或者法律文档处理。Q3和Q2我一般不建议用在生产环境，除非是极端受限的边缘设备。有个细节值得注意，llama.cpp的量化方式是分层的，重要层用高比特次要层用低比特，K_M系列就是这个思路，比均匀量化聪明不少。用户自己量化模型的时候别图省事用最简单的Q4_0，多花点时间跑Q4_K_M或者Q5_K_M，质量差距能感觉到。
线程绑定这事看起来小，实际影响不小。Intel平台把线程锁在P核上，AMD平台锁在单CCD内，这是两条铁律。llama.cpp的--threads参数设成物理核数就行，别开超线程，超线程在推理负载上帮倒忙。还有个参数是--threads-batch，控制prefill阶段的线程数，这个可以设得比decode线程数多一些，prefill是计算密集的，多开线程有收益。上下文长度方面，能短则短，2K够用就别开4K，KV Cache的读取开销在decode阶段是实打实的带宽消耗。推理框架的选择上llama.cpp是CPU场景的默认答案，编译的时候记得开-DGGML_NATIVE=ON，让编译器针对本机指令集优化，AVX-512在支持的平台上有额外加成。
5.4 测试局限与风险：平台差异、软件生态与数据偏差
我这套测试的局限得跟大家交个底。硬件层面，我只测了i9-13900K和Ryzen 9 7950X两颗消费级旗舰，没有覆盖中端型号。中端U的核心数少、缓存小，跑出来的数字跟旗舰会有差距，尤其是prefill阶段对单核性能敏感，i5或者Ryzen 5的TTFT会比我这组数据差一截。读者拿我的数字做参考可以，直接套用到自己的配置上会失真。
软件生态的变量更大。llama.cpp的版本更新很频繁，不同版本之间的性能差异有时候能到百分之十。我测试时锁定了具体commit，读者复现的时候最好也锁定版本，不然数字对不上别怪平台。编译选项、系统内核版本、NUMA配置这些都会影响结果，我在测试环境里把能控的变量都控了，但每个人手里的环境千差万别，数据偏差是必然存在的。还有散热，我用360水冷压着，风冷环境下CPU频率会降，速度掉个百分之几很正常。
数据偏差里最值得警惕的是内存时序。我测试用的DDR5-6000 CL30是相对紧的时序，市面上不少DDR5-6000条子是CL36甚至CL40，延迟高了一截，对token生成速度的影响在5%上下。这个差距在平台对比里可能盖过Intel和AMD之间的真实差异。读者看评测数据的时候多留意一眼内存配置，只看CPU型号不看内存参数的对比文章参考价值有限。
5.5 未来趋势：CPU推理优化、内存技术演进与异构计算发展
CPU推理这块的优化空间还很大。llama.cpp这类框架目前在CPU上的优化主要集中在矩阵乘算子的指令集利用上，AVX-512和AMX的潜力还没完全挖出来。Intel Sapphire Rapids上的AMX单元理论上能大幅加速prefill，我实测过一版支持AMX的编译选项，prefill速度确实有提升，decode阶段因为受限于内存带宽，收益不明显。未来推理框架会针对不同CPU微架构做更细粒度的调度，比如把prefill分配给计算强的核心、decode分配给缓存大的核心，这种异构调度在大小核架构上尤其有想象空间。
内存技术的演进是更根本的变量。DDR5还在爬坡期，频率和容量都在往上走，LPDDR5X在边缘设备上的渗透率也在提高，低功耗高带宽的特性很适合推理场景。再往远看，HBM在消费级平台上的落地值得关注，苹果M系列的统一内存架构已经证明了高带宽对推理性能的拉动效应。如果未来两三年桌面平台能摸到200GB/s级别的内存带宽，13B模型在桌面CPU上跑出流畅体验就不是空话。CXL内存扩展技术也在成熟，通过CXL挂大容量内存池跑大模型是个有潜力的方向，延迟比本地内存高，但容量优势明显。
异构计算是绕不开的趋势。CPU加NPU的组合已经在笔记本上出现了，NPU跑小模型的能效比CPU高一个数量级。我试过用Ryzen 8040系列的NPU跑7B模型，速度不算快，但功耗极低，适合一直开着的助手类应用。未来推理负载会按场景拆分，prefill丢给GPU或者NPU，decode留在CPU上靠大内存跑，这种混合方案在llama.cpp里已经有雏形了。对普通用户来说，这意味着选型的时候不能只看CPU本身，得把整机的加速器配置一起考虑进去。CPU不会退出推理舞台，它的角色会从“什么都干”变成“干最合适的那部分”。
