Latency Budgeting on Hyperliquid: From REST Polls to Sub-Second Reads
By @CoinMarketMan - 08-Jun-2026
Hyperliquid 的延迟预算:从 REST 轮询到亚秒级读取
在 Hyperliquid 上有一类交易策略,盈利与否的差异是以几百毫秒来衡量的。Hyperliquid 与中心化永续交易所之间的资金费率套利。需要在第二波触发前进场的清算级联反向交易。想要在 Money Printer 群组转为净多头的同一分钟内建仓的群组翻转信号。
对于这些策略,数据读取架构比策略本身更重要。一个完美规模但延迟三秒执行的群组翻转入场,不如一个中等规模但准时执行的入场交易。延迟不是锦上添花,而是决定你能运行哪些策略的硬约束。
本文将详细介绍基于 Hyperliquid 策略的延迟预算:每种数据源实际消耗的时间成本,REST 轮询在哪里失效,以及 WebSocket 订阅和事件驱动架构如何改变可执行策略的边界。
延迟堆栈
典型的 Hyperliquid 交易管道有四个延迟层,每层在链上发生某事到你的系统做出反应之间增加毫秒(或秒):
- 链上 → 索引器。 从 Hyperliquid L1 上成交清算到该成交出现在数据提供商索引中的时间。HyperTracker 通常为 200-800 毫秒。
- 索引器 → 你的代码。 从索引器获得数据到你的代码看到数据的时间。REST 轮询:取决于轮询间隔(典型为 1-30 秒)。WebSocket:5-50 毫秒。
- 你的代码 → 决策。 处理信号并决定是否采取行动的时间。取决于代码复杂度。对于任何延迟敏感的策略应该低于 100 毫秒。
- 决策 → 成交。 从代码发出订单到该订单挂在 Hyperliquid 订单簿上的时间。典型为 80-300 毫秒,取决于你与 Hyperliquid L1 的网络距离。
快速策略的总延迟预算:WebSocket 路径约 500 毫秒-1 秒,REST 轮询路径 2-30 秒。
REST 轮询在哪里失效
REST 轮询是大多数分析集成的默认选择,因为它简单——按计划发起 HTTP 请求并处理返回的数据。对于信号到行动窗口以分钟为单位的策略(大多数散户跟单交易),它运行良好,但对任何时间敏感的策略都会严重失效。
失效点:
资金费率结算。 Hyperliquid 资金费率每小时以 1/8 的费率结算。如果你的策略通过在结算前处于极端费率的正确一侧来收获资金费,你只有几秒钟的窗口期来建仓。5 秒间隔的 REST 轮询已经让你错过了 50% 的窗口。
清算级联。 当 Hyperliquid 上触发大额清算时,二阶清算(清算价格在价格冲击范围内的仓位)会在几百毫秒内触发。想要反向交易级联的策略需要 WebSocket 级别的延迟才能在反弹前建仓。
新闻催化剂下的群组翻转。 实时新闻事件(财报、监管公告、ETF 批准)触发的群组仓位变化会在接下来的 10-60 分钟内复合。捕捉第一波需要实时在数据流上,而不是轮询。
通用规则:如果将执行延迟 5 秒会使你的策略优势降低超过 50%,REST 轮询就不适合它。
WebSocket 订阅实际带来什么
HyperTracker API 对所有实时数据暴露 WebSocket 订阅:仓位、成交、群组定位、资金费率、清算。与 REST 的架构差异:
REST(轮询): 每 N 秒,你的代码问服务器"当前状态是什么?"服务器返回快照。你对比上一个快照找出变化。延迟下限 = 轮询间隔。
WebSocket(推送): 你的代码维护一个持久连接。服务器在变化发生时发送每个变化。延迟下限 = 网络往返时间,根据你的位置通常为 20-100 毫秒。
对于高频群组监控,差异是显著的。每 5 秒对群组定位端点进行一次 REST 轮询会让你承受最多 5 秒的陈旧数据。WebSocket 等效方案只需约 50 毫秒。
代码方面,切换增加了复杂性但不多:
import websockets, json
async def subscribe_cohort_changes(asset="BTC"):
async with websockets.connect("wss://api.hypertracker.cmm.app/ws") as ws:
await ws.send(json.dumps({
"subscribe": "cohort_positioning",
"asset": asset,
"cohorts": ["money_printer", "smart_money"]
}))
async for message in ws:
event = json.loads(message)
# event = {"cohort": "money_printer", "asset": "BTC",
# "long_ratio": 0.62, "delta_24h": +0.08, ...}
handle_cohort_update(event)
这就是整个订阅。更新实时流入。
按策略类型划分的延迟预算
不同策略容忍不同的延迟。粗略分类:
| 策略 | 可接受延迟 | 所需架构 | |---|---|---| | 跟单交易(多日持仓) | 10-60 秒 | REST 轮询 30 秒 | | 群组偏向信号(4 小时-1 天决策) | 1-5 秒 | REST 轮询 1 秒或 WebSocket | | 资金费套利 | 200-500 毫秒 | 需要 WebSocket | | 清算级联反向交易 | <200 毫秒 | WebSocket + 协同定位执行 | | 新闻驱动的群组翻转 | <2 秒 | 需要 WebSocket |
大多数开发者犯的错误是过度工程化。如果你在构建一个在 12 小时持仓上开仓的跟单交易仪表板,WebSocket 是不必要的基础设施成本。30 秒间隔的 REST 轮询完全足够。把复杂性预算留给真正重要的策略。
架构:事件驱动 vs 轮询驱动
一旦你决定使用 WebSocket 作为数据层,系统架构的其余部分也会改变。轮询驱动系统按周期工作:每 N 秒,检查状态、决策、行动。事件驱动系统按反应工作:当事件到达时,立即处理并可能采取行动。
事件驱动系统更难正确编写,因为:
- 状态管理是并发的(在你处理一个事件时可能有多个事件到达)
- 数据更新和你的行动之间可能出现竞态条件
- 当事件以不可预测的顺序触发时调试更困难
但对于延迟敏感的策略,你别无选择。轮询周期的最坏情况延迟太高。
在 Hyperliquid 上进行群组监控的清晰事件驱动模式:
class CohortMonitor:
def __init__(self):
self.state = {} # 按资产的当前群组定位
self.position_book = {} # 你的未平仓位
async def on_cohort_event(self, event):
asset = event["asset"]
cohort = event["cohort"]
# 更新状态
self.state[(asset, cohort)] = event["long_ratio"]
# 检查触发器
if cohort == "money_printer":
await self.check_money_printer_flip(asset, event)
async def check_money_printer_flip(self, asset, event):
# Money Printer 之前净空头,现在净多头?这就是信号。
prev = self.state.get((asset, "money_printer_prev"), 0.5)
if prev < 0.5 and event["long_ratio"] >= 0.55:
await self.open_position(asset, side="long", size=...)
触发器在 WebSocket 传递事件的瞬间触发。无轮询延迟,无错过的窗口。
成本考虑
在大多数 API 层级上,WebSocket 订阅比 REST 轮询成本更高。HyperTracker 的 Pulse 层级($179/月)包含 WebSocket 访问。算一下:如果你在运行需要亚秒级延迟的策略而使用 REST 轮询,你损失的交易价值超过 $179/月。计算一下。
免费层级和最低付费层级仅支持 REST。对于除上述延迟敏感策略外的所有情况,这都没问题。
更大的框架
大多数散户开发者将数据延迟视为技术细节。它不是。这是一个战略约束,决定了哪些策略类别对你开放。如果你的数据管道有 5 秒分辨率,你就被锁定在资金费套利、级联反向交易和新闻驱动入场之外——无论你的信号有多好都无济于事。
好消息是:REST 轮询和 WebSocket 之间的差距在开发工作量上并不大,而解锁整个策略类别的延迟预算变化。对于从事 Hyperliquid 原生策略的开发者来说,WebSocket 投资通常是你将做出的投资回报率最高的基础设施决策。
延迟是策略质量的隐形天花板。测量它,围绕它设计,并为让你低于它的层级付费。