3. CPU选型：Intel Xeon vs AMD EPYC vs ARM架构、核心频率与缓存大小的影响、睿频与锁频策略
CPU选型这事儿，我做了十几年高频交易系统，踩过的坑比走过的路还多。说白了，选CPU不是看参数表谁漂亮，而是看你的策略到底需要什么。今天咱们就掰开揉碎了聊聊这三家——Intel Xeon、AMD EPYC，还有这两年越来越猛的ARM架构。
3.1 三大架构的底层逻辑差异
先说说我个人的理解。高频交易对CPU的要求，其实就三个字：快、稳、准。快是延迟低，稳是抖动小，准是每次执行结果可预测。
3.1.1 Intel Xeon：老牌劲旅，生态成熟
Intel Xeon在高频交易圈子里，一直是默认选项。为什么？因为它的单核性能太稳了。我记得2018年帮一家做市商做系统，当时测试了Xeon Platinum 8180和AMD EPYC 7601，在同样的网络环境下，Xeon的尾延迟（99.9th percentile）比EPYC低了将近30%。
但Intel也有短板。它的核心数相对少，价格还贵。你想想看，同样花10万块钱，Intel给你28核，AMD能给你64核。如果你的策略需要大量并行计算，那Intel就不划算了。
3.1.2 AMD EPYC：核心多，性价比高
AMD这几年翻身了，EPYC系列确实有两把刷子。它的优势在于核心多、内存通道多、PCIe通道多。说白了，就是能同时干更多活。
我在项目中遇到过一件事：一个做统计套利的团队，他们的策略需要同时监控上千只股票，每只股票跑一个独立的模型。用Intel Xeon，因为核心数不够，得用两台服务器。换成AMD EPYC 7742，一台就搞定了，还省了网络延迟。
但AMD有个问题——NUMA架构带来的延迟不确定性。EPYC是多个Die拼在一起的，跨Die访问内存的延迟比同Die高不少。如果你的代码没做好NUMA亲和性绑定，性能会忽高忽低。嗯，这里要注意，做高频交易最怕的就是这种不确定性。
| 对比维度 | Intel Xeon | AMD EPYC | ARM（如Ampere Altra） |
|---|---|---|---|
| 单核性能 | ★★★★★ | ★★★★ | ★★★ |
| 核心密度 | ★★★ | ★★★★★ | ★★★★★ |
| 延迟稳定性 | ★★★★★ | ★★★ | ★★★★ |
| 功耗/性能比 | ★★★ | ★★★★ | ★★★★★ |
| 生态成熟度 | ★★★★★ | ★★★★ | ★★ |
3.1.3 ARM架构：新玩家，潜力大
ARM架构进服务器市场，也就是这几年的事。Ampere Altra系列是代表。它的优势是功耗低、核心数多、延迟一致性好。
我曾经测试过Ampere Altra Max，128核，功耗才250W。同样的性能，Intel得两倍功耗。但ARM的问题在于生态——很多高频交易软件、中间件、甚至操作系统内核，对ARM的优化还不够。你想想看，如果因为一个库不兼容导致系统崩溃，那损失可不是省点电费能弥补的。
3.2 核心频率与缓存大小的影响
很多人选CPU只看主频，觉得4.0GHz一定比3.0GHz快。其实没那么简单。高频交易里，缓存命中率往往比主频更重要。
3.2.1 核心频率：不是越高越好
频率高确实能提升单线程性能，但代价是功耗和发热。我见过有人为了追求5.0GHz的睿频，上了液冷散热，结果系统稳定性反而下降了。为什么？因为高频下电压波动大，容易触发硬件错误。
我个人习惯是：锁频使用。把CPU频率锁定在某个稳定值，比如3.5GHz，而不是让它自动睿频。这样延迟更可预测。你想想看，如果交易信号来了，CPU正好在降频散热，那延迟就多出几微秒——这几微秒可能就是盈亏的分界线。
3.2.2 缓存大小：L1/L2/L3的取舍
缓存对高频交易的影响，怎么强调都不过分。我举个例子：一个订单簿重建操作，如果数据全在L1缓存里，可能只需要10纳秒。但如果L1 miss了，去L2取，就是30纳秒。再miss，去L3，100纳秒。最惨的是去内存取，几百纳秒就没了。
所以，选CPU时，我优先看L1缓存大小和L2缓存大小。Intel Xeon的L1缓存一般是32KB数据+32KB指令，L2是1MB。AMD EPYC的L1也是32KB，但L2是512KB。ARM的Ampere Altra，L1是64KB，L2是1MB——这一点ARM有优势。
但缓存大也有代价——访问延迟会稍微增加。所以不是越大越好，而是要看你的数据访问模式。如果你的策略是频繁访问小数据集（比如只盯几个合约），那L1大一点好。如果是大数据集（比如全市场扫描），那L3大一点好。
// 一个简单的缓存性能测试示例
// 测试不同数据大小下的访问延迟
#include <stdint.h>
#include <chrono>
volatile int64_t sink;
void test_cache_latency(int64_t* arr, int size, int iterations) {
auto start = std::chrono::high_resolution_clock::now();
for (int i = 0; i < iterations; ++i) {
// 随机访问，模拟真实场景
int idx = (i * 2654435761) % size; // 黄金比例哈希
sink = arr[idx];
}
auto end = std::chrono::high_resolution_clock::now();
auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count();
printf("Size: %d, Avg latency: %.2f ns\n", size, (double)ns / iterations);
}
3.3 睿频与锁频策略
这个话题，我专门拿出来说，因为太多人在这里翻车了。
3.3.1 睿频（Turbo Boost）的陷阱
睿频技术，说白了就是让CPU在散热允许的情况下，临时跑得更高。听起来不错，但对高频交易来说，这是灾难。
为什么？因为睿频的触发条件不可控。CPU可能因为一个后台进程的突发负载而触发睿频，也可能因为温度升高而突然降频。这种不确定性，会让你的延迟分布变得很宽。我见过最夸张的情况，同一台机器，同一段代码，延迟从1微秒到10微秒都有——这就是睿频的锅。
3.3.2 锁频策略：怎么锁？锁多少？
锁频不是随便锁一个值就行。你需要根据你的策略和散热条件来定。
我一般这样做：
- 先测基线：在默认设置下，跑你的策略，记录延迟分布和CPU温度。
- 逐步降频：从最高频率开始，每次降100MHz，观察延迟变化和温度变化。
- 找到拐点：当频率降低到某个点后，延迟不再明显增加，但温度显著下降——这个点就是最佳锁频点。
举个例子，我去年调优一台Intel Xeon Gold 6248R，默认睿频能到4.0GHz。我锁到3.6GHz后，延迟只增加了3%，但温度从85°C降到了65°C，系统稳定性大幅提升。
# Linux下锁频命令示例
# 查看可用频率
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
# 锁定所有核心到3.6GHz
for cpu in /sys/devices/system/cpu/cpu[0-9]*; do
echo "3600000" | sudo tee $cpu/cpufreq/scaling_max_freq
echo "3600000" | sudo tee $cpu/cpufreq/scaling_min_freq
done
# 验证
cat /proc/cpuinfo | grep "cpu MHz" | head -5
echo 1 | sudo tee /sys/devices/system/cpu/cpu*/cpuidle/state*/disable
3.4 总结：怎么选？
说了这么多，最后给个实操建议：
- 如果你是做超低延迟（纳秒级）：选Intel Xeon，锁频，关睿频，优化缓存亲和性。别犹豫，Intel的生态和稳定性目前还是最好的。
- 如果你是做高吞吐（微秒级）：AMD EPYC性价比更高，核心多，能同时处理更多订单。但要做好NUMA优化。
- 如果你有技术储备且想尝鲜：ARM架构值得关注，尤其是功耗敏感的场景。但要做好踩坑的准备。
最后说一句：没有最好的CPU，只有最适合你策略的CPU。别盲目追新，先搞清楚你的瓶颈在哪——是计算延迟？还是内存带宽？还是网络延迟？对症下药，才是正道。