同规格机器为何速度不同：面向 Solana 的低延迟基础设施——配置、近接网络与可复现实测

在 Solana 上做实时交易与 bot 运营时延迟往往由一个最容易被忽视的层面决定在网络上到 Solana 的距离。本文从配置、网络拓扑与可复现的实测三个角度梳理面向 Solana 的低延迟基础设施是如何构建的。一、面向 Solana 优化的配置第一是专为 Solana 优化的配置。Agave validator requirements 将 2.8GHz 以上的基础时钟频率作为 CPU 的基准。在此基础上采用大幅高于该水平的高主频 CPU并着重于即便在峰值时段也能保留处理余量的配置是降低尾部延迟的关键。在 CPU 长时间维持高利用率的环境中更容易出现排队与抖动对于重视 first-arrival让交易与数据更早到达 leader 侧处理路径的用途而言这会导致尾部延迟的恶化。专有裸金属不会出现虚拟化环境中常见的「吵闹邻居」所带来的抖动与停滞。二、到 Solana 主要节点的直连第二是到 Solana 主要节点的直连。将分发源节点、接收端点与处理节点都放置在 Solana 验证者高密度聚集的数据中心之内可以在设计阶段就抑制距离带来的延迟。在同一网络配置中可以构建出一条不经外部中转、不经由公共互联网的短路径。这种近接网络上的直连能力正是支撑低延迟的根基。这套优化的运营经验已经作为配方汇集到了开源的 Solana 运营工具 SLV 之中——它建立在可复现的运营配方之上而非针对某一台机器的取巧手段。三、用实测确认与大型云的差距下面的基准测试将一台 VPS 与同等规格两者均为 AMD Turin / 4 vCPU阿姆斯特丹Ubuntu 24.04的大型云虚拟机在相同条件下并排测量CPU 吞吐量sysbench / 4 线程越大越好约 1.9 倍内存带宽STREAM Triad / 4 GiB越大越好约 3.2 倍磁盘 IOPSFIO / 4K 随机读QD32越大越好约 16.6 倍磁盘 p99 延迟FIO / 4K 随机读QD32越小越好在尾部约快 25.7 倍即便采用相同的硅片、相同的规格表数值速度也并不相同。差距来自调优——主机配置、虚拟化层、存储与网络布局以及把机器安放在 Solana 的近旁。需要说明的是上述倍率只是这一测量条件下的一例实际差异会随工作负载、连接来源与时段而变化。正因如此用任何人都能以相同方法验证的实测来评估比主观主张更可靠。四、速度由「到 Solana 的距离」决定在 Solana 上构建区块的 leader 会随 slot 切换。因此让交易与数据以更短的 RTT 到达 leader 侧处理路径的配置在重视 first-arrival 的用途中往往更具优势。「城市的名字」并不等于网络路径本身。即便身处同一座城市只要中间夹入外部中转或多余的跳数信号所经过的路由器段数延迟就会层层累积。在同一网络上的直连路线中可以构建出诸如最小 RTT 约 0.1ms 这样极短的路径而在夹入外部中转的迂回路径上中继可能增加到约 7 段延迟也可能因此大幅拉开。五、用按小时计费做低风险验证要判断这些差异在自己的工作负载下意味着什么最可靠的方式是以小时为单位做验证启用一小时在这段时间内确认从自己的 bot 或应用连接来源所看到的实际表现再据此判断。前面的基准测试同样可以在这一小时的验证中按自己的条件原样复现并比较。小结最终决定速度的不只是代码或机器的规格还有在网络上到 Solana 的距离。在贴近 Solana 的数据中心、用保留处理余量的配置、并以可复现的实测来证明品质是面向 Solana 的低延迟基础设施的核心思路。技术研发方面相关工作在荷兰政府的研发支持制度 WBSO 下自 2022 年起已连续五年获得批准并自建 AS200261RIPE NCC数据中心持续在 Solana RPC 基础设施、验证者运营与实时数据分发等方向开展研发。