毫秒級競速：鏈上高頻與套利機器人伺服器選型指南

鏈上高頻交易的伺服器選型，首先是鏈路選型。訊號在哪裡產生，策略在哪裡計算，交易最終交給哪個 Builder、Leader 或 Sequencer，決定了機器應該放在哪裡。CPU、磁碟和核心參數只有放進這條完整鏈路中，才有實際意義。

1. 從訊號到提交：毫秒究竟花在哪裡

一次交易機會的競爭，可以拆成三個連續階段：

$T_{\text{決策與提交}} = T_{\text{訊號到達}} + T_{\text{計算與簽名}} + T_{\text{交易送達}}$

對跟單和新池狙擊 Bot，競爭往往從訊號到達之前就開始了：資料源何時發現事件、經過幾次轉發、最終何時被本機解析，決定了策略能提前多少時間行動。如果本地只需完成簡單判斷與簽名，繼續增加 CPU 核心通常不會改變訊號遲到的問題。複雜套利 Searcher 的壓力則更多落在訊號到達之後：熱狀態更新、路徑搜索和並行模擬會消耗單核算力、記憶體頻寬與快取容量。出塊間隔越短，計算與提交之間可用的時間越少；策略必須給交易抵達 Builder、Leader 或 Sequencer 留出餘量。

因此，選伺服器時應把資料源出口、策略計算節點和目標提交入口放在同一條路徑上考慮。如果三者集中在同一區域，一台高頻機器就可能承擔接收、計算和發送；如果訊號與提交入口相距較遠，接收節點與區域提交節點可以分工，但跨區傳輸本身也要計入總耗時。CPU 跑分和一次 Ping 只能說明局部能力。真正用於選型的，是同一策略在候選機房長期測得的訊號首達時間、計算完成時間、目標入口接收時間，以及高峰時段的表現。

2. 伺服器選址：找到交易真正抵達的入口

EVM L1：圍繞 Builder 選址，就近發往目標入口

Ethereum 與 BSC 都有圍繞 Builder 的交易構建與提交工作流，但兩者的提議者與構建者機制並不完全相同，伺服器選址目標非常明確：訊號出現後，怎樣讓有效交易以最短路徑抵達目標 Builder？

訊號交易源在物理上散落全網，自建全地域嗅探節點不僅成本高，而且容易引入跨區中轉延遲。更實用的做法是直接接入成熟的高質量公開或私有 Mempool 服務。

選址時先確認資料流實際交付的區域，再在該區域部署計算節點。許多 EVM L1的 Builder 為同一提交服務開放多個區域入口，策略算出結果後即可選擇就近的 Builder 端點，讓接收、計算和提交盡量留在同一區域，減少跨洋折返。

• Ethereum：評估 Titan、BuilderNet 等 Builder 時，可將法蘭克福／阿姆斯特丹與美東（北弗吉尼亞）列入候選區域。部署前核實各服務當前開放的區域端點，再決定是否在兩地分別部署計算與提交節點。

• BSC：Fermi 升級將目標出塊間隔縮短至 450ms。工程上建議把“從收到訊號到交易抵達 Builder”的整體耗時壓在 350ms 以內；這是工程預算，並非協議保證。候選區域可包括法蘭克福、美東和東京，部署前需從候選機房對 Builder 實際域名進行 P95/P99 延遲實測。

Solana：資料接收靠近驗證者，交易發送關注質押通道

Solana 跟單與狙擊策略需要盡早發現 Leader 正在處理的交易。直接接收 Shred 資料流，可以比等待普通 RPC 的日誌或完整區塊通知更早提取可用訊號：Bot 據此觸發後續交易，本地節點也能更快更新熱狀態。對這種策略，伺服器既要接得早，也要在訊號出現後迅速完成計算和下單。

發送端的關鍵是擁堵時能否穩定抵達 Leader。Solana 的 SWQoS 按質押權重分配 Leader 的交易接收能力：80% 的 Leader TPU 容量採用質押加權優先級，見 Solana 官方 SWQoS 說明。與其建立受信任轉發關係的 RPC 服務也可利用這條路徑。它改善的是擁堵時交易被低質流量擠出的風險，並不保證每筆交易優先成交。

質押權重的地理分布可作為伺服器選址的參考。以下保留隨稿提供的 2026 年 11 月快照；原稿未附原始資料集鏈接，採購前應與當前驗證者資料重新核對。國家層級佔比不代表節點都位於表中城市，也不保證未來固定比例的出塊窗口。

這份快照呈現出西歐質押較集中的特徵，德國與荷蘭合計超過 54%，可將法蘭克福或阿姆斯特丹列為核心計算與監聽候選區域。美國、日本與新加坡合計 24.01%，設定美東與東京節點可用於減少其他 Leader 窗口的跨洋傳輸。實際覆蓋仍應結合當前 Leader 排程、節點位置與端到端實測確認。

Base 與 Robinhood Chain：下沉到排序器所在區域和可用區

對於採用集中排序路徑的 L2，靠近有效 Sequencer 端點有助於縮短網路路徑，但交易排序規則同樣影響納入結果。

• Base：Flashblocks 提供約 200ms 預確認，應與完整 L2 區塊和 Ethereum 最終性區分。交易排序還會受到優先費影響。可將 AWS us-east-1（北弗吉尼亞） 列為首輪候選區域；1–2ms RTT 是適合就近鏈路的實測目標，不是所有機房的性能保證，也不能單憑 RTT 證明排序器的物理位置。

• Robinhood Chain：以 俄亥俄（AWS us-east-2） 作為本選型方案的首輪候選區域，在多個可用區部署探針，比較 Feed 首達時間與提交耗時。使用官方連接端點，並參考 BlockRazor 的俄亥俄可用區測試背景。俄亥俄觀測較快並不能獨立證明排序器的精確機房位置或排序規則。

3. 伺服器選型：將預算精準投入延遲瓶頸

同一台伺服器未必需要同時承擔訊號接收、本地模擬和交易發送。跟單或狙擊 Bot 通常先受制於訊號首達時間；MEV Searcher 和多路徑套利策略還要爭取更短的狀態更新、模擬與簽名時間。先確認瓶頸在哪一段，再決定買機房、網路還是算力。

只接收訊號：先選供應商，再選設定

如果 Bot 消費外部 Mempool、Sequencer Feed 或普通日誌，且不運行本地全節點、也不做大規模狀態模擬，4–8 vCPU、16–32GB 記憶體和可靠 NVMe 可以作為起步設定。此時更值得投入的是資料源質量、供應商和穩定的網路路徑。

選供應商時，可以沿著該鏈最重要的節點往回找。

Robinhood Chain 可先評估俄亥俄的候選路徑：優先在 AWS us-east-2 的候選可用區部署相同接收程序，比較 Feed 首達時間，再決定主區。Base 的首輪候選則是北弗吉尼亞。

Ethereum、BSC 等 EVM L1 應分別核實目標 Builder 的區域入口和其節點服務區所屬供應商。

Solana 可以參考出塊驗證者的城市和供應商分布。下表保留隨稿提供的 2026 年 11 月供應商快照；原始資料集鏈接未附，採購前請重新核對。百分比對應各城市快照，不代表全球供應商市場份額：

與核心節點使用同一家供應商，是篩選候選機房的辦法，但本身不保證內網優勢；採購前還應確認具體資料中心、網路互聯方式和目標端點。用同一訊號流實測首達時間、P99、掉包和故障率，並同步記錄後續交易的上鏈結果。

需要本地計算：按模擬規模選 CPU、記憶體與磁碟

訊號到達後，單次 EVM/SVM 模擬的耗時受核心性能影響；並行搜索、狀態快取和本地節點則進一步消耗核心數、記憶體頻寬與 NVMe I/O。此時伺服器選型應和 訊號接收位置以及供應商一起評估：若最快的資料源在另一地區或者不同供應商，計算節點的跨區或跨雲傳輸可能抵消更高時脈帶來的收益。

AWS 實例規格見 C8a、C8g 和 M8azn 官方頁面；這些系列在俄亥俄區域的支持情況可查 AWS 區域清單。裸金屬方面，TeraSwitch 公佈了 9950X、9375F 和 9575F 設定；Cherry Servers 有 9950X 機型；Allnodes 提供可定制的 Turin / Threadripper 9000 裸金屬與 Gen5 NVMe，適合按節點角色調整 CPU、記憶體和磁碟的團隊。價格、庫存與可用機房以實際下單頁面為準。

輕量 Bot 可以先用一台接收與下單一體的機器驗證策略；Searcher 和 Quant Trading 團隊再按實測瓶頸拆分節點。預算也應分開看：伺服器及網路是一部分，資料流、交易發送服務和鏈上費用是另一部分。最後比較的是整筆交易從訊號首達到目標入口接收、再到實際納入區塊的結果，而非單台機器的跑分。

交易送達（Submit）：優先評估路由與連接

交易送達本身對伺服器硬體設定（CPU/記憶體）沒有大的影響。這一階段的核心決定因素是物理路由與網路鏈路，因此通常無需在此階段單獨堆砌機器設定；高吞吐提交仍需檢查簽名隊列、封包處理與連接管理。

4. 生產環境調校：先測瓶頸，再改核心參數

4.1 網路緩衝與掉包

大量接收 Shreds 時，應先觀察網卡掉包、UDP 接收錯誤與應用隊列積壓。提高 net.core.rmem_max 可以讓應用申請更大的 socket 接收緩衝區，配合應用的 SO_RCVBUF 調整，防止突發流量打滿緩衝區掉包。

對頻繁提交小消息的 TCP 客戶端，開啓 TCP_NODELAY 可關閉 Nagle 算法避免拼包延遲；同時必須做好連接復用，避免單筆交易反復建連握手。不要隨意盲改 tcp_tw_reuse 等可能導致連接異常的參數。

4.2 CPU、行程與本地節點

網路包到達伺服器，不代表策略程序立即開始處理。在共享型雲主機上，需監控 CPU Steal；若高峰期排隊嚴重，升級為獨享計算型實例或物理裸機（Bare Metal）比調整參數更有效。自建節點還需監控區塊高度落後情況與 NVMe 讀寫延遲，避免用過時狀態進行無效模擬。

4.3 時鐘同步與端到端測量

跨機器對比事件先後必須依賴可信時間戳。建議設定 Chrony 同步鄰近的高精度時鐘源，將毫秒以內作為需實測驗證的同步誤差目標；同一台機器內測量耗時應始終使用單調時鐘（Monotonic Clock）。

5. 結語

伺服器選型的本質，是讓你的計算節點與目標鏈路形成最短物理閉環：

• EVM L1：選用高質量資料源，在同區域部署節點並就近發往該區域 Builder；

• Solana：評估歐洲核心驗證者群集附近的供應商機房，結合 Shred 接收與 SWQoS 提交通道；

• L2：將 Base 的北弗吉尼亞與 Robinhood Chain 的俄亥俄可用區作為候選，以當前端點和實測表現選址。

只有當訊號到達、交易提交以及最終上鏈的端到端指標得到持續改善，機房位置與硬體投入才能真正轉化為交易優勢。