CPU选型：核心频率与IPC、缓存架构、NUMA架构影响、Intel Xeon vs AMD EPYC vs ARM
做低延迟行情系统，CPU选型是绕不开的核心决策。很多人一上来就盯着主频看，觉得频率越高越快。嗯，这其实是个误区。我见过不少团队花大价钱买了高频CPU，结果行情处理延迟反而没降下来。
为什么会这样？因为CPU的「快」不是单一维度决定的。今天我就把CPU选型的几个关键点掰开揉碎了讲清楚。
核心频率与IPC：一对欢喜冤家
核心频率（GHz）和IPC（每时钟周期指令数）是决定CPU单核性能的两大支柱。频率决定了CPU每秒能跑多少个时钟周期，IPC决定了每个周期能干多少活。两者相乘，才是真正的单核吞吐能力。
我个人习惯把IPC比作「效率」，频率比作「速度」。一个工人（核心）跑得再快，如果每次只能搬一块砖（低IPC），那总产出也有限。反过来，效率再高，跑得慢也不行。
关键公式：单核性能 ≈ 频率 × IPC
在低延迟场景下，我们追求的是「确定性」和「低延迟」，而不是单纯的吞吐量。高频CPU往往伴随着更高的功耗和发热，这会触发降频机制。我在项目中遇到过，某款5.0GHz的CPU在持续高负载下，实际运行频率掉到了4.2GHz，还不如一款稳定4.5GHz的CPU表现好。
避坑指南：我曾经踩过一个坑——只看Boost频率，没看全核满载频率。行情系统是持续高负载的，CPU几乎一直处于满载状态。这时候Boost频率基本用不上，全核满载频率才是真实性能。选型时一定要看「全核满载频率」这个参数。
缓存架构：L1/L2/L3的博弈
缓存是CPU和内存之间的「缓冲地带」。延迟从低到高依次是：L1（约1ns）→ L2（约4ns）→ L3（约10ns）→ 内存（约100ns）。
对于行情系统来说，行情数据通常只有几十到几百字节，但更新频率极高。如果数据能留在L1缓存里，延迟就是1ns级别；如果频繁命中L3，延迟就变成了10ns；如果跑到内存里，那就是100ns起步了。
我建议重点关注以下几点：
- L1缓存大小：行情处理的核心数据结构（如订单簿快照）如果能塞进L1，延迟会大幅降低。Intel的L1数据缓存通常是32KB，AMD是32KB，ARM（如Graviton）是64KB。ARM在这一点上有优势。
- L2缓存大小：每个核心独享的L2缓存，决定了核心能「私藏」多少数据。AMD EPYC的L2是512KB/core，Intel Xeon是1.25MB/core（Golden Cove架构），ARM Graviton3是1MB/core。
- L3缓存大小：共享缓存，影响多核间的数据共享效率。行情系统通常用单核或双核处理，L3的影响相对小一些，但也不能忽视。
注意：缓存不是越大越好。大缓存意味着更高的访问延迟和更大的芯片面积。选型时要看你的行情数据「工作集」大小。如果工作集是64KB，那L1 32KB的CPU就会频繁miss，性能反而不如L1 64KB但频率稍低的CPU。
NUMA架构影响：跨节点访问的代价
NUMA（非统一内存访问）是多路服务器中常见的架构。简单说，每个CPU有自己的本地内存，访问本地内存快，访问远端内存慢。
在低延迟行情系统中，NUMA的影响非常明显。我曾经调试过一个系统，行情处理延迟偶尔会飙升到正常值的3倍。排查了半天，发现是操作系统把行情线程调度到了CPU0，但网卡中断绑定到了CPU1，导致线程需要跨NUMA节点访问内存。
解决方案其实不复杂：
- 绑定核心：使用taskset或numactl将行情处理线程绑定到特定核心，同时将网卡中断也绑定到同一NUMA节点。
- 关闭NUMA平衡：在BIOS中关闭NUMA balancing，避免操作系统自动迁移内存页。
- 使用本地内存：通过numactl --membind指定只使用本地内存。
实战经验：我建议在BIOS中直接关闭NUMA，让所有内存统一编址。虽然会损失一些总带宽，但延迟的确定性会大幅提升。对于行情系统来说，确定性比峰值性能更重要。
Intel Xeon vs AMD EPYC vs ARM：三足鼎立
这三家各有千秋，我分别说说我的看法。
| 维度 | Intel Xeon | AMD EPYC | ARM（如Graviton） |
|---|---|---|---|
| 单核性能 | ★★★★★ | ★★★★☆ | ★★★☆☆ |
| 缓存架构 | L1 32KB, L2 1.25MB | L1 32KB, L2 512KB | L1 64KB, L2 1MB |
| NUMA影响 | 中等（2-4节点） | 较大（4-8节点） | 较小（通常1-2节点） |
| 功耗 | 较高（200-350W） | 中等（200-280W） | 低（100-200W） |
| 生态兼容性 | 最好 | 好 | 一般（需重新编译） |
Intel Xeon：目前单核性能的王者。我个人的主力选型就是Xeon，尤其是Sapphire Rapids系列，单核IPC提升明显。如果你追求极致的单核延迟，Intel是首选。但要注意，Intel的功耗较高，散热要做好。
AMD EPYC：核心多、性价比高。如果你需要同时处理多个行情源（比如同时接入沪深、港股、美股），EPYC的多核优势就体现出来了。但NUMA节点多，需要仔细做亲和性配置。我在项目中用过EPYC 7763，64核128线程，配合numactl绑定后，延迟表现相当不错。
ARM（如AWS Graviton）：功耗低、成本低。如果你在云上部署行情系统，Graviton是个不错的选择。ARM的L1缓存更大（64KB），对行情数据的工作集更友好。但生态兼容性是个问题，很多行情SDK只提供x86版本，需要自己编译或找替代方案。
我的建议：如果你做的是「极致低延迟」的本地部署，选Intel Xeon，配合高频内存和低延迟网卡。如果你做的是「高吞吐、多行情源」的系统，AMD EPYC更合适。如果你在云上，且行情SDK支持ARM，Graviton的性价比很高。
知识体系总览
下面这张图总结了CPU选型的核心逻辑，你可以对照着看：
说白了，CPU选型没有「万能答案」。你得先搞清楚自己的行情数据特征、延迟要求、部署环境，再对症下药。我个人习惯是先做一轮POC测试，用真实的行情数据跑一遍，看看不同CPU的实际表现。纸上谈兵终觉浅，实战才是硬道理。
最后说一句：别迷信参数。我见过用低频但大缓存的CPU跑出比高频CPU更低的延迟。也见过ARM在特定场景下吊打x86。选型的关键是「匹配」——让你的CPU架构和行情数据特征完美契合。
公众号:蓝海资料掘金营，微信deep3321