1 处理器设计权衡要回答什么
面对 2 台服务器，甲的处理器标注 3.0 GHz、16 核，乙标注 3.6 GHz、12 核，能直接判断谁更快吗？还不能。频率描述时钟节奏，核心数描述可用的计算资源，实际完成任务的速度还受指令执行效率、缓存命中情况、内存供给和程序并行程度影响。本课要回答的是：在任务、机箱和用电条件已经明确时，哪些处理器特征值得优先选择，又需要为它们付出什么代价。
处理器设计同时面对面积、功耗、发热和制造成本约束。给缓存增加空间，会占用本可安排计算核心的芯片面积；增加核心，需要更多供电和数据通路；提高频率，可能要求更高电压与更强散热。设计者不能把每个指标都无限提高。服务器采购者虽然不直接设计芯片，却必须识别这些取舍如何影响自己的应用，否则很容易把纸面优势误写成业务承诺。
先固定任务的完成标准。例如，科学计算程序需要在 30 分钟内处理 1 组输入；文件服务器需要持续向 25 GbE 网卡提供数据；虚拟化宿主要在多台虚拟机同时活动时保持响应。这些目标分别关注完成时间、持续吞吐和共享资源下的表现。同样标为“高性能”的 CPU，在这些场景里可能得到不同排序。没有说明任务与负载的性能结论，通常无法迁移到另 1 台机器。
再把 CPU 放回整机：核心经缓存访问内存控制器和 DDR 内存，PCIe 连接 NVMe 存储与网卡，主板为它们提供插槽、供电和布线。即使处理器计算能力很强，只有 2 条内存通道被实际填充，也可能供不上数据；网卡只能协商到较低链路速率时，增加核心也不能突破网络上限。部件规格描述潜力，连接方式与软件使用方式决定这份潜力能否兑现。
还要看机器形态。1U 服务器高度有限，风扇与散热器要在密集风道里带走热量；2U 机箱通常能提供不同的散热和扩展空间，但也增加机架占用。双路服务器拥有 2 个处理器插槽，可能提供更多内存通道和 PCIe 连接，同时引入跨插槽访问的额外成本。这里的“更大”首先意味着资源与约束变化，性能仍然要由工作负载验证。
因此，本课用 3 类证据讨论选择：任务完成得怎样，处理器为什么会等待，整机付出了多少能耗与散热代价。先用直观模型理解方向，再用测量判断真实机器。流水线内部如何调度、缓存如何维持一致性，以及处理器的详细电路实现，都不在本课展开。入门阶段最有用的能力，是把“这个规格更高”改写成可以被测试推翻或支持的判断。
2 流水线、缓存与功耗
处理器执行指令可以粗略分成取指、理解指令、运算和写回结果等环节。流水线让不同指令在不同环节同时推进，类似多个工位连续加工。它提高的是稳定运行时单位时间完成的工作量，并不保证单条指令经历所有环节的时间缩短。若某条指令必须等前面的结果，后面的推进就会受影响；若程序改变执行方向，已经准备的部分工作也可能需要重做。
为提高时钟频率，设计者可以把某些环节划得更细，使每个时钟周期内完成的工作减少。但环节之间也需要保存状态，并承担控制成本。于是，频率增加并不必然带来同比例的性能增加。这里不需要记流水级数，更不要跨不同设计仅凭流水级数排名。只需记住：时钟走得快和有效工作推进得快有关联，却不是同 1 件事。
缓存用于把近期或经常访问的数据留在离核心更近的位置。L1、L2、L3 表示常见的缓存层级，但容量、共享范围和访问代价随设计而变。假设程序反复访问 24 MiB 的热点数据，较大的末级缓存可能保留更多内容；若程序只连续读取 100 GiB 文件且很少重用，增加几 MiB 缓存的收益可能有限。判断缓存价值，需要知道数据怎样被访问，而不只是数据总量。
缓存未命中表示所需内容没有在当前查询的缓存层找到，需要继续向下查找。最终访问 DDR 内存时，等待往往跨越许多个 CPU 时钟周期。真实处理器能让部分运算与等待重叠，因此不能把每次未命中的延迟简单相加当作实际运行时间。不过，当程序沿着“上个结果决定下个地址”的访问链前进时，可重叠的机会会减少，等待更容易主导完成时间。
功耗又把这些选择连接起来。动态开关功耗与电压平方、频率及活动程度有关，还存在漏电等其他消耗。提高频率常常伴随工作电压增加，因此实际功耗可能增长得比频率更快。芯片宣传中的功耗参数、平台设置的功率上限和插座电表读数含义不同；比较能效时应说明测量对象，不能把 CPU 的某个标称数值直接当作整机耗电。
温度与功率限制会改变可持续频率。短时间任务可能享受较高的自动加速频率，持续运行数分钟后则回到散热条件允许的水平。若风道堵塞、导热接触不良或机房进风温度升高，同 1 颗处理器也可能更早降低频率。表现可以是任务开始很快，随后吞吐下降，而机器没有报错；这与存储损坏导致的读取错误属于不同问题，需要不同证据。
所以应把频率、缓存和功耗连起来看：更高频率缩短可由时钟加速的计算时间，缓存影响需要等待多少次，供电和散热决定这种状态能维持多久。选择高频处理器之前，先确认应用确实在做可加速的计算，主板允许相应功率设置，机箱也能长期带走热量。只看到频率上限，会遗漏决定真实表现的另外几段路径。
3 单核与多核边界
单核性能影响难以拆分的工作，例如读取输入后按顺序计算的程序片段。多核性能依赖有多少任务可以同时运行，以及这些任务是否争用其他资源。把核心数从 8 增加到 16，并不会自动把每个程序都加速 2 倍。操作系统能把可运行线程分配到核心，但不能替程序消除结果依赖，也不能让本来只有 1 条执行线的计算凭空分成多份。
用理想模型说明边界：某任务有 20% 的时间必须串行，80% 可以均分给多个核心，且忽略分工成本。使用 4 核时，相对耗时为 0.20＋0.80÷4＝0.40，加速比是 2.5；使用 8 核时为 0.30，加速比约 3.33。核心翻倍，收益却逐渐减少。这个计算只是上界示意，真实程序还会增加线程管理、结果汇总和共享数据访问等成本。
另一类工作可以通过运行多个独立实例利用核心，例如同时压缩多个独立文件。单个文件的完成时间可能没有明显变化，总共每小时完成的文件数却增加。这说明延迟与吞吐要分别讨论。若用户等待的是某个大文件处理结束，增加并发实例未必改善体验；若后台有大量互不依赖的任务排队，多核则可能更有价值。
多核还要共享数据供给。假设持续内存带宽实测为 80 GB/s，每个工作单元需要从内存读取 2 GB，即便暂不考虑计算，吞吐上限也约为 40 个工作单元每秒。若 8 核已经接近这个带宽，增加到 16 核可能只是让更多核心一起等待。DDR 的标称传输率不等于应用实测带宽，通道数量、内存条配置和访问方式都会影响结果。
逻辑处理器数也不能直接等同于物理核心数。有些 CPU 让 1 个物理核心呈现多个硬件线程，使不同线程共享部分执行资源。当某线程等待时，另 1 个线程可能利用空闲机会；若它们同时争用同类资源，收益就可能很小。报告必须同时写物理核心、启用的硬件线程和应用线程数，避免把“系统显示 32 个处理器”误写成“32 个独立完整核心”。
服务器有多个处理器插槽时，内存通常分布在不同位置。核心访问本地连接的内存和访问另 1 个插槽附近的内存，延迟与可用带宽可能不同，这类特征常称为 NUMA。入门时先确认任务运行在哪些核心、数据主要放在哪里即可。若单路配置能满足容量和扩展需求，它也值得测试；不能仅根据插槽数预测应用结果，更不能把远端访问变慢误判为 CPU 损坏。
选型时先做线程扩展曲线：固定输入，分别运行 1、2、4、8、16 个线程，记录完成时间和吞吐。曲线在哪个位置变平，比最大核心数更能指导采购。再结合内存带宽和存储等待判断原因。若每加线程都明显改善，可以继续评估多核；若很早就没有收益，应先查串行部分和共享资源，再决定是否为更多核心付费。
4 动手：对照一次 IPC 与频率选择
IPC 是每个时钟周期平均完成的指令数。为了便于入门，本节把统计口径固定为已完成的指令数除以相应的核心周期数。它是某个程序在某种运行条件下的平均结果，并不是处理器永远不变的属性。对固定的程序路径，可用“完成时间≈指令数÷（IPC×频率）”连接这些量。若频率随时间变化，应用总耗时与硬件计数器提供的统计应配套解释。
先做可复现的纸面实验。准备同 1 个数据集、同 1 个程序构建和单线程执行条件，假设都需要完成 24 亿条指令。候选甲的实测平均 IPC 为 1.5，持续频率为 3.0 GHz；候选乙的实测平均 IPC 为 1.2，持续频率为 3.6 GHz。这里的频率是任务运行期间的观测值，不能用参数表上的最高自动加速频率代替。
甲每秒完成约 45 亿条指令，耗时约 0.533 s；乙每秒完成约 43.2 亿条指令，耗时约 0.556 s。乙的频率高 20%，却因 IPC 较低而稍慢。这并不说明“IPC 比频率更重要”，而是说明在指令数与执行条件可比时，两者共同决定计算推进速度。对于只有几个百分点的差异，真实测试还需要检查波动，不能凭 1 次结果下结论。
在 Linux 机器上，可以对已有的计算程序执行 perf stat -e instructions,cycles -- ./cpu_task input.bin，同时记录程序输出的处理量和墙上时间。cpu_task 代表你的实际测试程序，系统需要安装相应工具并允许访问性能计数器。命令中的指令与周期事件只是观察入口，不同平台的事件支持和计数口径可能不同，遇到不支持或权限限制应先记录原因。
使用计数结果时，先确认只比较目标任务的相同范围。多线程汇总周期数不能直接当作单核经历的时间；事件过多导致的复用、进程迁移和虚拟机环境也可能影响解释。无需在本课追踪每种计数器细节，但要保留工具版本、事件名称与异常提示。缺少某项证据时，可以照常比较相同任务的完成时间，只应收窄关于原因的结论。
正式测试前，让程序完成相同的初始化，并明确测量冷启动还是重复运行后的状态。数据是否已在内存、缓存是否已预热，会改变结果。单线程对照可将程序固定在相同类型的核心上，保持电源策略一致，并停止会干扰测试的后台批处理。若 2 台机器的内存容量和通道填充方式不同，应该写入记录，不能把整个平台差异全部归因于 CPU。
至少重复 5 次，保存每次时间，再看中位数和波动范围。若 1 台机器成绩散得很开，应检查后台活动、温度和频率变化；若较快机器偶尔输出错误，性能排名应暂停，先处理正确性。只有输出一致、测量范围一致，速度比较才有意义。对于完成时间超过数分钟的程序，还应覆盖足够长的持续负载，确认短时加速没有掩盖后续降频。
最后写出有限结论：“在该输入、单线程和当前平台设置下，甲的中位完成时间更短；计数结果与较高 IPC 相符。”不要写成“甲在所有任务上更快”。换程序后，指令数量可能变化；换编译设置后，某些指令可能完成更多数据运算。IPC 适合帮助解释同类执行条件下的现象，不能单独作为跨程序、跨指令集的统一评分。
5 吞吐与能效取舍
完成得快与耗电少是不同目标。吞吐可以写成每秒完成的压缩文件数、每秒处理的数据块数，能效则可写成每焦耳完成多少有效工作。对于固定任务，也常用总能耗比较：能耗约等于平均功率乘运行时间。1 W 等于每秒 1 J，因此 100 W 持续 10 s 约消耗 1000 J。只比较瞬时功率，会忽略运行时间这个同样重要的因素。
例如甲整机平均功率 160 W，完成固定任务需要 10 s，能耗约 1600 J；乙平均功率 220 W，耗时 6 s，能耗约 1320 J。乙运行时功率更高，这次任务的总能耗却更低。反过来，如果 220 W 只能把耗时降到 9 s，能耗就达到 1980 J。要得到哪种结果，必须实测，不能从频率高低或某个标称功耗直接推出。
对长期在线服务器，还要计入任务之间的空闲时段以及整机基础耗电。内存、网卡、存储和风扇都需要电，CPU 活跃时间缩短不代表服务器随后完全断电。如果大部分时间处于低负载，空闲功率与电源管理策略可能显著影响每天总能耗；如果长期满载，持续吞吐和满载能效更重要。测量时段必须与实际运行方式相符。
下面的滑块把总时间拆为计算时间和不可重叠的等效等待时间。它假设计算需要 12 亿个核心周期，每次等效内存等待为 40 ns。模型使用“等效串行等待次数”，刻意不把它当作真实缓存未命中计数；真实机器可能把多个请求重叠处理。调节频率和等待次数，可以看到等待占比越高，提高频率对总时间的帮助越小。
交互里的功率曲线也是教学假设，用于说明能耗可能出现取舍，不能据此预测具体芯片。实际选型应在平台允许的功率限制下，分别测量任务完成时间、整机平均功率与温度。若降低功率上限只损失少量吞吐，却显著减少能耗和风扇噪声，这个工作点就值得考虑；若任务有严格截止时间，则先确认它满足时限，再讨论节电收益。
机架还存在供电与散热容量边界。假设某组服务器可用的持续功率预算为 4 kW，就要按照整机实际功率安排数量，并留出运维规定的余量。单台机器最快，不保证相同机架功率下总吞吐最高。把单位任务能耗、单位机架吞吐和任务延迟并列记录，能避免采购只优化某张单机成绩表，却让部署密度或日常电费超出计划。
6 常见坑：频率当唯一性能指标
最常见的错误是把“最高 4.0 GHz”理解为所有核心可以长期同时运行在 4.0 GHz。最高频率通常有适用的活动核心数量、温度与功率条件。单线程短任务和全核持续计算可能处于不同频率区间。报告若只抄参数表，就无法解释为什么机器前 20 s 很快，随后持续吞吐下降。应记录代表性时间段内的实际频率及其变化。
另 1 个错误是跨设计只比较 GHz。不同处理器每周期完成的有效工作不同，缓存行为和内存连接也可能不同。即便频率相同，同 1 段程序的指令数也可能受到编译结果影响。正确的比较顺序是先看输出是否正确、任务是否等价，再看完成时间，最后借 IPC、缓存和带宽等信息解释差异。参数可以提出假设，不能替代任务测量。
还有人看到 CPU 使用率接近 100%，就认定计算单元已经满负荷运转。操作系统的使用率主要反映任务是否占用了处理器时间，并不等于每个周期都在完成有效计算。线程在执行路径中等待数据时，也可能显示为忙。若 IPC 较低、内存带宽接近平台实测上限，就应考虑数据供给；若等待的是磁盘输入，则应同时检查设备吞吐和输入输出等待。
存储与网络的规格也容易被误读。PCIe 通道数量、链路代际和设备本身能力共同限制 NVMe 传输；网卡标注 25 GbE，也不代表应用一定达到相应有效载荷吞吐。若文件服务的存储只能持续提供 1 GB/s 数据，换更高频 CPU 不会凭空补齐数据源。应先找到速度在哪段路径下降，再决定是否更换处理器。
另 1 类坑来自不对称测试：甲运行预热后的输入，乙运行刚从存储读取的输入；甲只有测试程序活动，乙还在做备份；甲填满了建议使用的内存通道，乙只装少量内存条。这样的结果能够描述当时的整机表现，却不能证明 CPU 设计本身的优劣。无法统一的条件应明确列出，并把结论限制在当前配置范围内。
排查还要区分稳定的性能边界与故障。长时间高温后降频可能来自散热配置；突发重启需要结合电源、温度和系统日志分析；纠错内存告警需要单独处理可靠性问题。不要仅因某台机器更慢就断定芯片损坏，也不要在出现错误时继续用吞吐数字掩盖风险。可靠地完成任务是所有性能和能效比较的前提。
最实用的纠偏方法，是在每个结论后补齐适用条件：“哪个任务、哪种输入、多少线程、什么整机配置、持续多久”。如果这几项写不清，暂时保留观察，不急着下采购结论。这样做不要求读者掌握复杂微架构，却能挡住大部分由单个规格引出的误判，也能让后续工程人员重复实验并确认变化来自哪里。
7 案例：缓存不足抵消高频收益
某团队要部署内存中的索引查询服务，热点数据约 24 MiB，完整数据集更大。候选甲为 3.0 GHz、32 MiB 末级缓存，候选乙为 3.6 GHz、16 MiB 末级缓存。这里使用的是抽象候选配置，不对应任何具体产品。即使热点小于缓存标称容量，也不能保证全部驻留，因为代码、其他数据和共享任务也占空间；容量只是提出缓存假设的依据。
固定单线程、相同查询序列与相同输出校验后，团队观察到乙反而较慢。先检查实际频率，确认乙确实维持更高频率，且没有明显温度限制。接着发现乙在该任务上的末级缓存未命中更多，而存储在正式测量期间基本没有活动。证据把排查方向收敛到缓存与内存路径，但还不足以仅凭相关性认定容量是全部原因。
用简化模型说明这种结果如何发生：假定两者都需要 12 亿个可计算周期。甲的计算部分需要 0.40 s，乙约需 0.333 s，乙在计算上节省约 0.067 s。再假设甲有 1000 万次、乙有 1600 万次等效串行等待，每次按 40 ns 计算。两者等待分别为 0.40 s 与 0.64 s，总时间约为 0.80 s 与 0.973 s，缓存路径的额外等待抵消了高频收益。
这组数字是可手算的解释模型，真实计数器报告的未命中数不能直接代入。内存请求可能重叠，后续缓存层也可能命中，操作系统与其他核心还会改变访问行为。模型的价值在于比较量级：频率提升能省下多少时间，额外等待可能花掉多少时间。看到低 IPC 时，也不能立即把它全部归因于缓存，需要结合其他证据。
为检验假设，团队把热点规模依次调整为 8、16、24、48 MiB，并保持每次查询的语义和采样方法一致。如果热点变小时乙恢复优势，热点扩大时差距又出现，同时缓存与等待指标随之变化，就更支持缓存相关解释。需要注意，不同数据规模可能改变分支和访问分布，因此仍应保留“当前程序与输入范围内”的限定。
再把线程数增加到实际部署值。如果多个核心共享末级缓存，单线程时够用的容量可能在并发后不足；如果所有核心一起访问内存，带宽也可能成为新边界。上线方案应采用接近真实并发的结果，不能把单线程缓存优势直接外推到整机吞吐。热点规模、并发量和邻近任务都应纳入测试矩阵。
最后的决策可以是选择甲，也可以是先调整数据布局、减少每次查询触及的数据量，再重新比较。若部署中热点经常变化，团队还需要在较大热点下检查最差响应和容量余量。这个案例说明，高频优势只覆盖能够被频率加速的部分；确定哪个部分占主导，才是从参数比较走向工程判断的关键。
8 把 CPU 权衡写进服务器方案
服务器方案首先写工作负载边界。例如：“单机运行 16 个独立批处理工作进程，每批读取 64 GiB 数据，要求在 20 分钟内完成，结果校验一致。”这比“需要高性能 CPU”更能指导配置。若是交互服务，还应写清目标并发、每秒处理量和响应时间要求，并说明测试时的数据规模。不同任务类型可以共用记录方式，但不能共用未经验证的性能承诺。
然后列出处理器和整机的关联配置：插槽数、物理核心、硬件线程、持续负载下的频率、缓存容量，以及内存容量、通道填充、网卡和存储连接。缓存共享方式等信息若没有可靠资料，就标记待确认。方案中的数据应能追溯到规格资料或测试记录，而不是为了填满表格随意推测。哪些是标称值、哪些是实测值，也要分开表达。
举例而言，配置里写“256 GiB DDR 内存”仍不够，还应说明使用几条内存条及其在通道上的分布，确保符合主板的支持规则。写“2 块 NVMe SSD”时，应确认实际 PCIe 连接以及同时传输是否受其他部件影响。扩展卡的插入可能改变部分插槽的可用通道或共享关系，必须查对应主板资料；不能只按连接器外观推断电气能力。
机器形态也应写成约束：采用 1U 还是 2U、机架允许多少功率、进风条件如何、是否允许增加扩展卡。风扇转速升高会增加整机功耗，散热不足可能让处理器持续降频。对于密集部署，应使用接近实际机房条件的持续测试；敞开机箱、低室温下的短跑成绩，不能直接当作上架后的保证值。
方案至少保留 2 类候选：偏重单任务响应的配置，以及偏重并行吞吐或容量的配置。保持任务正确性标准一致，按相同输入比较中位完成时间、波动、持续吞吐和每任务能耗。如果某个候选在预算内无法满足时限，可以排除；如果都满足，再讨论购置成本、功耗、扩展余量与维护便利。比较应围绕门槛与证据展开，而不是人为凑出唯一冠军。
故障与降级条件要写得具体。例如，长期运行时吞吐下滑超过预定范围，应检查温度、实际频率及功率限制；内存纠错告警持续增加，应进入硬件维护流程；网卡链路降速，应检查连接与协商状态。性能不达标的复测步骤和硬件错误的处置路径需要明确负责人，避免出现“更换更快 CPU”成为所有问题的默认处理方式。
验收记录应足以重现：程序版本、输入摘要、操作系统与固件版本、线程数、电源策略、测试持续时间、输出校验和仪表范围都要保存。以后升级固件、扩容内存或更换网卡，可以在同样条件下复测。这样，CPU 权衡成为可持续维护的方案依据，而不是采购完成就失去解释能力的参数截图。
9 从处理器设计权衡走向CXL 与内存池化（H40）
前面的比较说明，CPU 的计算能力要由数据供给支撑。容量不足时，程序可能被迫频繁访问存储；容量足够但带宽不足时，多个核心会争用内存通路；数据所在位置较远时，访问延迟可能增加。容量、带宽和延迟是不同维度，增加其中某项不必然改善另外几项。进入下节前，应该先能指出自己遇到的究竟是哪类边界。
传统服务器主要通过处理器连接的内存通道安装 DDR 内存。需要更多容量时，可能增加内存条、选择更高容量模块，或调整服务器平台。这些选择同时受到插槽数量、支持规则、成本和功耗影响。若为了更多内存而采购更多 CPU 核心，却没有相应计算需求，就会出现资源配置不匹配：为获得容量而买来的计算能力没有充分使用。
CXL 是面向处理器、内存与加速设备互连的公开标准体系，利用相应的物理连接能力提供规定的交互机制。下节会讨论它如何支持内存扩展及相关资源组织。本课先建立边界意识：CXL 不是把现有 PCIe 插槽随便插上内存就能工作，处理器、主板、设备、固件和操作系统需要具备匹配支持，具体能力也与标准版本和实现有关。
内存池化关心的是让可用内存资源以更灵活的方式分配给使用者。它可能改善某些场景下的容量利用，但额外连接路径仍有延迟、带宽与管理成本。远端或扩展内存不能默认拥有本地 DDR 相同的访问表现，更不能默认不同主机上的程序可以无条件同时共享任意数据。资源如何分配、如何隔离、出故障时如何恢复，仍要由平台明确设计。
可以沿用本课的热点例子：若频繁访问的 24 MiB 数据已经受等待影响，把它放到访问代价更高的位置可能进一步拖慢任务；较少使用的大体量数据，则可能适合不同层次的容量安排。判断不能只看内存总量变大，还要测任务实际触及哪些数据、访问有多频繁，以及相应等待是否能被其他工作覆盖。
因此，走向 H40 时保留同 1 套问题：目标任务是什么，限制是计算、容量、带宽还是延迟，变化后的等待路径在哪里，功耗和故障边界如何变化。下一课将把这套判断用于 CXL 与内存池化，理解为什么更灵活的内存组织能够解决部分配置问题，同时仍需要用真实任务验证收益。
放进方案里
在服务器方案里增加“处理器选择依据”段落，先写任务与门槛：固定程序版本和输入，说明数据规模、并发数、完成时间或吞吐要求，并要求结果校验一致。把单任务响应与整机吞吐分别列出，避免用并发任务总量替代用户真正等待的时间。未经过持续运行验证的频率，只能作为规格信息保留。
接着记录候选机器的物理核心、硬件线程、缓存、内存容量与通道填充、NVMe 和网卡连接，以及机箱形态和功率设置。用相同条件完成至少 5 次测量，保存每次耗时、实际频率、温度、整机平均功率与输出校验。对持续服务，再补充稳定运行阶段的吞吐和响应时间；写清电表是否包含整台服务器，保证能耗可以比较。
选择理由需要连接现象与证据。例如：“候选甲在目标热点规模和并发下满足时限，缓存等待较少；候选乙频率更高，但当前负载完成更慢。”若原因证据不足，就只报告性能差异并列出待确认项。对于内存带宽、存储供给或网卡链路已经成为限制的任务，应先验证对应路径，不能把更高频 CPU 当作通用补救措施。
验收时另列持续负载门槛，例如在约定进风温度和功率上限下运行 30 分钟，热稳定阶段吞吐仍须达标，并保留频率、温度与功率的时间记录。双路配置还应记录线程绑定与内存分配位置，分别核对本地和跨插槽访问的表现，避免验收通过后因调度变化失去预期收益。
最后写入余量与复测条件：热点扩大、线程数增加、内存扩容和固件升级后，均按原记录复测；持续吞吐下降时检查温度与功率限制；出现计算错误、重启或内存告警时先处理可靠性。若考虑 CXL 扩展内存，另列容量需求、预期访问频率、平台支持和验收项目。让方案明确何时成立、何时需要重新验证，才能把 CPU 权衡变成后续运维可用的依据。
10 小结：下一步CXL 与内存池化（H40）
频率决定时钟节奏，IPC 帮助描述每周期推进的工作，缓存与内存路径影响等待，多核收益受并行程度和共享资源限制。吞吐、延迟、功率和能耗需要分别测量，再按任务目标决定取舍。能解释观测结果的整机证据，比单个最高规格更适合支撑方案。
自测时可以问自己：3.6 GHz 为什么可能输给 3.0 GHz？核心翻倍后吞吐不变，应先检查哪些共享资源？平均功率更低是否一定更省电？如果能用任务时间、等待和整机条件回答这些问题，就已经具备进入 H40 的基础。下一步将讨论 CXL 与内存池化，把同样的判断扩展到内存容量、位置和分配方式。