Home>Blog>Latency Budgeting on Hyperliquid: From REST Polls to Sub-Second Reads
Latency Budgeting on Hyperliquid: From REST Polls to Sub-Second Reads

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 交易管道有四个延迟层,每层在链上发生某事到你的系统做出反应之间增加毫秒(或秒):

  1. 链上 → 索引器。 从 Hyperliquid L1 上成交清算到该成交出现在数据提供商索引中的时间。HyperTracker 通常为 200-800 毫秒。
  2. 索引器 → 你的代码。 从索引器获得数据到你的代码看到数据的时间。REST 轮询:取决于轮询间隔(典型为 1-30 秒)。WebSocket:5-50 毫秒。
  3. 你的代码 → 决策。 处理信号并决定是否采取行动的时间。取决于代码复杂度。对于任何延迟敏感的策略应该低于 100 毫秒。
  4. 决策 → 成交。 从代码发出订单到该订单挂在 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 投资通常是你将做出的投资回报率最高的基础设施决策。

获取群组 + 仓位数据的 WebSocket 访问 →

延迟是策略质量的隐形天花板。测量它,围绕它设计,并为让你低于它的层级付费。