本文讨论 A 股高频行情进入 Colo 服务器时的硬件入口：网卡。重点不是简单比较厂商宣传的平均延迟，而是理解 Solarflare、NVIDIA ConnectX 和 FPGA 定制卡分别解决什么问题，以及网卡型号、端口、时间戳、PCIe、NUMA、固件和冗余结构如何共同影响行情接收链路。本文停在网卡硬件入口，不展开 RX Queue、内核旁路、用户态收包和订单簿处理。

本篇范围：从交换机端口到服务器网卡和硬件平台选型。网卡之后的数据搬运、轮询、A/B 合并、Channel/Seq、补包、协议解码和订单簿构建将在后续系列讨论。

1. 网卡不是一个透明插头

在普通业务系统中，网卡经常只按 10G、25G 或 100G 带宽选择。但高频行情主要由大量小包、突发流量和严格的尾部延迟约束组成，网卡会直接影响：

• 小包每秒处理能力；
• 从物理端口到主机内存的延迟；
• 延迟分布和极端抖动；
• 突发流量下是否丢包；
• 硬件接收时间戳；
• PTP 时钟同步；
• 接收队列和流量分类能力；
• 用户态网络栈或 DPDK 的支持；
• 驱动、固件和诊断工具；
• A/B 双路的故障隔离程度。

因此，不能只问“这张卡是多少 G”，还要问：它在目标服务器、目标驱动和真实行情包型下，是否稳定、可观测、可恢复。

2. 先确定网卡在系统中的职责

本文把网卡方案分成三类。

2.1 低延迟通用网卡

代表：AMD Solarflare、NVIDIA ConnectX。

主要职责：

接收以太网帧
→ 校验和流量分类
→ 硬件时间戳
→ DMA 到主机内存
→ 交给软件处理

行情含义、A/B 合并、订单簿和策略仍由 CPU 软件完成。

2.2 可编程智能网卡或FPGA加速卡

主要职责可以扩展为：

收包
→ 过滤
→ 时间戳
→ 协议解析
→ 序号检查
→ A/B合并
→ 部分订单簿或特征计算

它不只是把数据交给 CPU，而是开始理解行情内容。

2.3 完整硬件交易路径

更激进的 FPGA 方案可能继续完成：

行情解析
→ 订单簿
→ 信号
→ 风控
→ 订单编码与发送

这已经不是网卡选型，而是交易系统边界重构。对第一代行情系统，不应默认从这一层开始。

3. 选型之前先确认需求

3.1 网络需求

• 行情端口是 10G、25G、50G 还是更高；
• A/B 是否各使用独立端口；
• 是否还接收快照、逐笔、指数和恢复流；
• 是否使用 SFP、SFP28、SFP56 或 QSFP；
• 是否要求光口、DAC 或 AOC；
• MTU 和最大 UDP 包长；
• 峰值 PPS 和微突发规模。

3.2 延迟需求

不能只写“低延迟”，应明确测量路径：

交换机发包时间
→ 网卡硬件接收时间
→ 数据可被软件读取的时间

需要观察：

• P50；
• P99；
• P99.9；
• P99.99；
• 最大值；
• 行情峰值时的分布；
• 两路同时输入时的分布。

高频系统通常更关心尾部延迟和抖动，而不是单一平均数。

3.3 时间需求

• 是否支持硬件 RX 时间戳；
• 时间戳生成在 PHY、MAC 还是更后的位置；
• 是否支持 PTP 硬件时钟；
• 两张卡的时钟如何同步；
• PTP 失锁时是否可检测；
• 时间戳与系统时钟如何关联。

3.4 运维需求

• 驱动和固件是否有长期支持；
• 是否能固定生产版本；
• 是否能读取端口、队列和错误计数；
• 是否有厂商诊断工具；
• 是否支持在线升级或需要停机；
• 操作系统和内核版本是否兼容；
• 故障卡是否容易获得同型号替换件。

4. Solarflare的定位

Solarflare 目前属于 AMD 产品体系。AMD 将 Solarflare X4 定位为面向资本市场和电子交易的超低延迟以太网适配器，并提供 Onload 与 ef_vi 等软件接口。

4.1 为什么交易系统经常选择Solarflare

Solarflare 的核心优势通常不是最高端口带宽，而是围绕低延迟电子交易形成的完整路径：

• 小包低延迟；
• 较成熟的内核旁路软件；
• 硬件时间戳和时间同步能力；
• 面向交易场景的工具和调优经验；
• 可以从标准 Socket 逐步过渡到更低层接口；
• 适合专用行情接收和交易服务器。

AMD 官方资料中，Onload 用于通过内核旁路加速现有网络应用，ef_vi 则是更低层的超低延迟 API。具体软件路径属于下一阶段文章，本篇只把它视为选型时的生态能力。

4.2 当前X4系列的端口形态

AMD 当前公开的 X4 产品包括：

型号	端口形态	官方列出的端口速率
X4522	双 SFP	1/10/25/50GbE
X4542	双 QSFP，可拆分	双口 40/50/100GbE，或四口 1/10/25GbE

这不表示 X4542 一定比 X4522 更适合行情。若券商提供的是 10G 或 25G 双路行情，端口形态、光模块、服务器插槽、功耗和实际延迟测试可能比最高速率更重要。

4.3 Solarflare适合什么场景

• 服务器主要用于行情和交易；
• 流量以 UDP 组播小包为主；
• 团队希望使用 Onload 或 ef_vi；
• 更重视低抖动和交易行业经验；
• 不需要复杂的 FPGA 自定义逻辑。

5. NVIDIA ConnectX的定位

Mellanox 已属于 NVIDIA，ConnectX 是数据中心高性能以太网和 InfiniBand 适配器系列。它的定位比 Solarflare 更通用，常见于 AI、存储、云计算、RDMA、高吞吐网络和低延迟应用。

5.1 ConnectX的软件生态

与行情相关的常见路径包括：

• 标准 Linux Socket；
• NVIDIA XLIO；
• DPDK mlx5 驱动；
• 更底层的 Verbs 或其他 NVIDIA 网络组件。

NVIDIA 官方文档将 XLIO 描述为用户态、内核旁路的 TCP/UDP 加速库，可通过 POSIX Socket 兼容方式或更低层 API 工作。DPDK 的 mlx5 驱动则适合已经采用统一用户态轮询和内存池架构的团队。

5.2 ConnectX的优势

• 服务器和交换网络生态广；
• DPDK 支持成熟；
• 端口速率和型号选择丰富；
• 流量分类、虚拟化和卸载能力丰富；
• 适合统一的数据中心网络平台；
• 团队已有 NVIDIA/Mellanox 运维经验时，接入成本较低。

5.3 ConnectX适合什么场景

• 公司已经统一使用 DPDK；
• 现有交换网络和监控体系以 NVIDIA 为主；
• 同一平台还承担内部高速通信、存储或计算网络；
• 需要较高带宽或丰富硬件流量转向；
• 愿意通过真实压测验证小包尾部延迟。

5.4 型号越新不等于行情越快

新一代网卡可能增加更高带宽、AI 集群、存储、安全和虚拟化功能，但这些功能不一定直接降低 10G/25G UDP 组播行情的端到端延迟。

选择时应比较：

目标速率
目标包型
目标服务器
目标驱动和固件
目标用户态软件
目标CPU与NUMA配置

而不是只按 ConnectX 型号数字排序。

6. Solarflare和ConnectX如何选择

维度	Solarflare	NVIDIA ConnectX
主要定位	电子交易和低延迟网络	通用高性能数据中心网络
Socket 加速	Onload	XLIO
低层用户态路径	ef_vi	DPDK mlx5、Ultra Socket 等
DPDK 统一平台	可用，但不是唯一核心	生态成熟
端口和高带宽范围	更聚焦	非常广
交易行业经验	强	强，但场景更通用
适合的默认场景	专用行情/交易服务器	统一高性能网络平台

实际选型不应写成固定结论。两家网卡都可能满足高频行情需求，决定结果的经常是软件路径、服务器平台、驱动版本和团队经验。

7. FPGA定制卡为什么不是高配网卡

FPGA 是现场可编程门阵列。普通网卡的主要逻辑由厂商固定，而 FPGA 可以由机构自行实现数据通路。

7.1 普通低延迟网卡路径

7.2 FPGA路径

FPGA 的价值不是单纯增加带宽，而是把固定、规则明确的处理变成硬件流水线，减少操作系统调度、缓存未命中和通用 CPU 路径带来的抖动。

8. FPGA可以逐步卸载什么

8.1 第一层：网络前置

• 包过滤；
• 流量分类；
• 硬件时间戳；
• A/B 路径标记；
• 原始包复制；
• 基础完整性检查。

这类功能规则稳定，适合先做。

8.2 第二层：传输和协议处理

• UDP 包切分；
• PacketSeq 检查；
• Channel 识别；
• A/B 去重；
• 乱序缓存；
• 固定格式字段解析。

协议变更会要求更新 FPGA 镜像，因此版本管理和回归测试必须严格。

8.3 第三层：订单簿和特征

• 新增、撤单和成交更新；
• 价格档位聚合；
• 最优买卖价；
• 部分订单流特征。

这部分需要处理大量状态、异常恢复和内存访问，复杂度明显高于简单报文解析。

8.4 第四层：策略和发单

• 信号计算；
• 硬件风控；
• 订单编码；
• 直接发送。

到这一层时，FPGA 已经成为交易系统核心，而不是行情网卡。任何协议或策略修改都需要硬件开发、仿真、综合、时序验证和生产发布流程。

9. FPGA的主要优势与成本

9.1 优势

• 固定流水线，延迟更确定；
• 可以并行处理多个功能；
• 减少 CPU 调度和内存路径抖动；
• 部分场景可避免行情先经 PCIe 到 CPU 再返回网卡；
• 可根据自有协议和策略定制。

9.2 成本

• 需要 FPGA、网络和交易协议的复合团队；
• 调试和可观测性差于软件；
• 协议升级速度慢；
• 恢复、重建和异常状态更难实现；
• 硬件错误可能持续产生看似正常的错误结果；
• 需要软件参考实现作为校验和兜底；
• 生产发布需要更严格的验证流程。

9.3 厂商延迟数字如何理解

AMD Alveo UL3524 等产品面向超低延迟交易，并公开给出收发器级延迟指标。这类数字通常描述特定硬件测试路径，不等于：

行情进入
→ 解码
→ 订单簿
→ 策略
→ 风控
→ 订单发出

的完整端到端延迟。选型时必须读取测试条件，不能把收发器、网卡、应用和完整交易链路的数字混为一谈。

10. 一张双口卡还是两张独立网卡

假设 A/B 分别接在一张双口网卡的两个端口：

虽然线缆和交换机不同，但仍共享：

• 网卡芯片；
• 固件；
• 驱动实例；
• PCIe 插槽；
• 供电；
• 卡级温度和硬件故障。

更强的隔离方式是：

但两张卡也会带来新的问题：

• PCIe 插槽是否足够；
• 是否位于不同 NUMA 节点；
• A/B 合并时是否产生跨 NUMA 数据传输；
• 两张硬件时钟如何同步；
• 固件和驱动版本是否完全一致。

因此，冗余和低延迟之间需要综合设计，不能只看卡数。

11. PCIe和NUMA为什么属于网卡选型

11.1 PCIe

网卡需要通过 PCIe 把数据写入主机内存。需要确认：

• 插槽实际是 x8 还是 x16；
• 支持的 PCIe 代际；
• 是否与其他设备共享带宽；
• 是否经过额外 PCIe Switch；
• BIOS 是否把插槽降速；
• IOMMU 和虚拟化设置是否影响路径。

11.2 NUMA

多路服务器中，每张网卡通常更接近某个 CPU 和内存节点。理想路径是：

网卡
→ 本地 PCIe Root Complex
→ 本地内存
→ 本地 CPU 核心

如果网卡接在 NUMA 0，而接收线程和缓冲区位于 NUMA 1，数据可能需要跨 CPU 互连，增加延迟和抖动。

但 A/B 两张卡也不一定必须分散到两个 NUMA 节点。若最终由同一个合并器处理，两路跨节点汇合也会增加成本。应通过服务器拓扑和实测决定，而不是套用固定规则。

12. 硬件时间戳和PTP

网卡硬件时间戳可以在包进入硬件路径时记录时间，比应用程序调用系统时钟更接近真实到达时刻。

它可以用于：

• 比较 A/B 路径延迟；
• 区分网络延迟和软件处理延迟；
• 分析微突发；
• 对齐行情和订单事件；
• 定位交换机到服务器的最后一段链路。

需要确认：

• 每个包是否都能获得时间戳；
• 时间戳点位；
• 时间戳分辨率与准确度；
• PTP Hardware Clock 的同步方式；
• 两张卡是否属于同一时钟域；
• PTP 失锁和主时钟切换如何上报；
• 时间戳溢出、跳变和缺失如何处理。

“支持硬件时间戳”不等于已经具备可比较的精确时间，时钟源、拓扑和监控同样重要。

13. 固件和驱动版本管理

同一张网卡在不同版本下可能出现：

• 接收性能变化；
• 时间戳行为变化；
• 用户态库兼容性变化；
• 特定内核版本问题；
• 组播过滤或队列配置差异；
• 新功能引入新的已知缺陷。

生产环境应记录：

网卡厂商与型号
硬件版本
序列号
固件版本
驱动版本
用户态库版本
操作系统与内核版本
BIOS版本
PCIe插槽和NUMA位置

升级流程至少包括实验室压测、历史行情回放、A/B 对比、故障注入和灰度运行。不能只因为厂商发布了“最新版本”就直接升级生产行情服务器。

14. 网卡验收不能只做ping测试

14.1 基础功能

• 端口速率和链路稳定性；
• 组播加入；
• VLAN 和 MTU；
• 硬件时间戳；
• PTP 锁定；
• 驱动和诊断工具。

14.2 小包性能

• 目标 UDP 包大小；
• 持续 PPS；
• 突发 PPS；
• 多组播组并发；
• A/B 两路同时输入；
• 同时开启时间戳和流量分类。

14.3 延迟分布

P50
P99
P99.9
P99.99
最大值

必须在空载、稳定高负载、微突发、CPU 干扰和两路同时输入条件下测试。

14.4 丢包和恢复场景

• RX 缓冲压力；
• 单路断线；
• 链路频繁上下线；
• 组播成员变化；
• PTP 失锁；
• 固件重置；
• 网卡温度升高；
• PCIe 错误；
• 一张卡故障后另一张卡是否仍稳定。

14.5 可复现性

每次测试都应记录完整环境，避免比较两个“名字相同但配置不同”的结果：

• 服务器型号；
• CPU 和 BIOS；
• 内存与 NUMA；
• 网卡插槽；
• 固件、驱动和软件；
• 交换机和光模块；
• 流量发生器；
• 包长、速率、突发模型；
• 测量时钟和统计方法。

15. 一个实用的选择路径

15.1 第一代系统

Solarflare 或 ConnectX
+ 两张独立物理卡
+ CPU 软件完成行情处理

目标是先建立：

• 完整、可验证的行情接入；
• 原始数据留存；
• A/B 路径监控；
• 软件订单簿参考实现；
• 可复现的延迟和丢包测试。

15.2 第二阶段

根据团队生态选择：

Solarflare → Onload / ef_vi
ConnectX → XLIO / DPDK mlx5

再优化 CPU 隔离、NUMA、内存、队列和用户态数据路径。

15.3 第三阶段

只把已经证明稳定、规则明确且真正成为瓶颈的部分卸载到 FPGA：

• 时间戳；
• 包过滤；
• A/B 去重；
• 固定协议解析；
• 部分特征计算。

完整硬件订单簿或策略应在软件参考实现、异常恢复方案和硬件验证体系成熟后再考虑。

16. 选择矩阵

需求	选择倾向
专用行情和交易服务器	Solarflare 或经过实测的 ConnectX
团队已有 Onload/ef_vi 经验	Solarflare
团队已有 DPDK/MLX5 体系	ConnectX
需要统一数据中心网络生态	ConnectX
需要固定流水线和极低抖动	FPGA
协议和策略经常修改	CPU 软件方案
没有 FPGA 开发与验证团队	不选择完整 FPGA 路径
要降低单卡故障影响	A/B 使用两张独立网卡
只依据厂商平均延迟做决定	不足，必须实测尾部延迟

17. 仍需确认的问题

• 券商提供的端口速率和光模块类型；
• 峰值 PPS 与微突发模型；
• 最大 UDP 包长度和 MTU；
• 是否要求硬件时间戳；
• PTP 主时钟和交换机拓扑；
• 服务器 PCIe 与 NUMA 结构；
• 操作系统、驱动和固件支持周期；
• A/B 是否要求卡级物理隔离；
• 是否已有 Onload、XLIO 或 DPDK 技术栈；
• FPGA 计划卸载到哪一层；
• 端到端延迟目标和测量方法。

没有这些信息，无法仅根据厂商和型号给出可靠结论。

18. 后续文章

前三篇已经把行情从交易所一路讲到服务器网卡入口。后续系列将进入行情程序：

1. 网卡 RX Queue、RX Ring、DMA 与 CPU；
2. Linux Socket、Onload、ef_vi、XLIO 和 DPDK；
3. A/B 双路接收与消息去重；
4. Channel、Seq、乱序窗口和丢包恢复；
5. 协议解码和逐笔事件标准化；
6. 本地订单簿构建与可信状态；
7. 行情异常时的策略降级和交易保护。

参考资料

• AMD Solarflare X4 Ethernet Adapters
• AMD Solarflare X4 Support：Onload 与 ef_vi
• NVIDIA XLIO Documentation
• DPDK NVIDIA MLX5 Ethernet Driver
• AMD Alveo UL3524

本文仅为个人学习笔记和系统架构设计整理，不构成任何投资建议或交易建议。高频量化交易系统涉及市场风险、技术风险、合规风险和运维风险，任何实盘部署都应经过充分测试、独立验证和风险评估。