3. 硬件基础与选型：CPU架构对延迟的影响
做高频交易，说白了就是跟物理定律赛跑。你写的代码再漂亮，如果硬件不给力，延迟照样下不去。我见过不少团队，软件优化做到极致了，结果换块网卡又砍掉几微秒——嗯，硬件选型就是这么直接。
这一章我们聊聊CPU、网卡，还有FPGA和GPU。都是真金白银砸出来的经验。
3.1 CPU架构：NUMA、缓存层级、睿频
CPU是交易系统的核心。但很多人只盯着主频看，忽略了架构细节。我个人习惯，选CPU先看三样东西：NUMA拓扑、缓存层级、睿频行为。
NUMA：别让你的数据“串门”
NUMA（非统一内存访问）是现代多路服务器的标配。什么意思？每个CPU有自己的本地内存，访问本地内存快，访问远端内存慢。差距有多大？
| 访问类型 | 延迟（纳秒） |
|---|---|
| 本地内存（Local） | ~80 ns |
| 远端内存（Remote） | ~140 ns |
你看，差了将近一倍。我在项目中遇到过，一个交易进程跑在CPU0上，但分配的内存却在CPU1的NUMA节点上。每次读写都要跨QPI总线，延迟直接多出60纳秒。别小看这几十纳秒，在高频交易里，这就是胜负手。
numactl --cpunodebind=0 --membind=0 ./your_trading_app，CPU和内存要绑在同一个节点。
缓存层级：L1/L2/L3的“温度”
CPU缓存是延迟优化的主战场。为什么？因为内存太慢了。看看这个对比：
| 存储层级 | 延迟 | 大小 |
|---|---|---|
| L1 缓存 | ~1 ns | 32 KB |
| L2 缓存 | ~4 ns | 256 KB |
| L3 缓存 | ~12 ns | 8-32 MB |
| 主内存 | ~80 ns | GB级 |
说白了，你的交易数据如果能塞进L1缓存，延迟就是1纳秒。如果掉到主内存，就是80纳秒。差了80倍。你想想看，一个订单簿的数据结构，如果设计得不好，每次查询都触发缓存未命中，那延迟就崩了。
我建议，核心的热数据（比如买卖盘口的前几档）一定要控制在L1缓存大小内。32KB，够放不少东西了。如果数据量超过L3，那就得考虑用FPGA了——这个后面说。
睿频：双刃剑
Intel的睿频（Turbo Boost）技术，听起来很美：自动超频嘛。但在HFT里，它是个麻烦。为什么？因为睿频的触发有延迟。当你的交易进程突然需要算力时，CPU从基频升到睿频需要几十微秒。这几十微秒，行情可能已经变了。
我在项目中遇到过，某次回测时发现延迟抖动特别大。查了半天，原来是睿频在作怪。进程空闲时降频，行情来了再升频，中间那几十微秒的延迟完全不可控。
cpupower frequency-set -g performance把CPU调到最高性能模式。虽然功耗高一点，但延迟稳定。做HFT，稳定比峰值更重要。
3.2 网卡选型：Solarflare/Mellanox vs Intel
网卡是交易系统的“耳朵”和“嘴巴”。行情进来、订单出去，都靠它。选错了，软件优化再好也白搭。
Solarflare：HFT的标配
Solarflare（现在叫Xilinx了）的网卡，几乎是HFT行业的标配。为什么？因为它有两大杀器：
- OpenOnload： 用户态协议栈。绕过内核，直接从用户态收发网络数据。延迟从几十微秒降到几微秒。
- 硬件时间戳： 在网卡硬件层面打时间戳，精度达到纳秒级。做延迟测量和回放时，这个太重要了。
我个人习惯，只要预算允许，首选Solarflare SFN8522或X2系列。配合OpenOnload，延迟能稳定在1-2微秒以内。
Mellanox：RDMA的王者
Mellanox（现在叫NVIDIA了）的网卡，强在RDMA（远程直接内存访问）。说白了，就是网卡直接把数据写到应用的内存里，CPU都不用碰。延迟更低，CPU占用更少。
但RDMA有个门槛：你的应用得支持。如果只是普通的TCP/UDP交易，Mellanox的优势不明显。我建议，如果你做的是极低延迟的行情分发或订单路由，可以考虑Mellanox ConnectX-6或更高型号。
Intel：够用但不极致
Intel的网卡（比如X710、XXV710）便宜、稳定、驱动成熟。但延迟方面，跟Solarflare和Mellanox比，差了一个数量级。为什么？因为Intel网卡依赖内核协议栈，中断处理、上下文切换，这些开销都跑不掉。
如果你做的是非核心的交易系统（比如风控、监控），Intel网卡完全够用。但如果是核心的交易引擎，我建议还是上Solarflare或Mellanox。
3.3 FPGA与GPU在HFT中的角色
CPU再快，也有物理极限。当延迟要求进入亚微秒级别时，FPGA和GPU就登场了。
FPGA：硬件的“硬”实力
FPGA（现场可编程门阵列）说白了就是一块可以重新配置的芯片。你可以把交易逻辑直接烧录到硬件里，数据进来，几个时钟周期就出结果。延迟是多少？几十纳秒。
我在项目中遇到过，一个订单簿的深度计算，用CPU做要5微秒，用FPGA做只要200纳秒。差了25倍。而且FPGA的延迟是确定的，没有抖动。这对HFT来说太重要了。
但FPGA也有缺点：开发周期长，调试困难，成本高。你想想看，写Verilog代码跟写C++完全是两码事。我建议，只有那些延迟要求极高、逻辑相对固定的场景（比如行情解析、订单簿重建、信号生成）才用FPGA。
GPU：并行计算的“大力士”
GPU在HFT里的角色比较尴尬。为什么？因为GPU擅长的是大规模并行计算，但HFT的延迟要求是单笔交易在微秒级。GPU的延迟太高了——数据从CPU传到GPU，再从GPU传回来，光这个传输就要几十微秒。
不过，GPU在回测和风险计算里很有用。比如，你要同时计算几千个策略的信号，或者做蒙特卡洛模拟，GPU的并行能力就体现出来了。我见过一些团队，用GPU做盘后回测，速度比CPU快几十倍。
3.4 知识体系总览
这一章的内容比较多，我画了一张图帮你理清思路：
这张图把CPU、网卡、FPGA/GPU的延迟优化要点都串起来了。你想想看，从行情数据到达网卡，到CPU处理，再到订单发出，每一步都有优化空间。硬件选型就是把这些环节的延迟压到最低。
好了，这一章的内容就到这里。硬件选型是基础，下一章我们会深入软件层面的优化——从内核旁路到用户态协议栈，都是实战经验。