 jackandCursor
|
6c843639d5
|
影子路径开 lean 模式，实测完整链路 1410 → 683ms
拉到新引擎后在服务器侧直接实测，没有沿用 3.4 倍那个换算——那是在旧代码上量的。
先做等价性验证。不能直接引用 step46 的对拍结论：它固化的是 bsp_list 那条链的
哈希，而影子路径走 find_fast_bsp3 + build_htf_zones + htf_fx_timeline +
attach_htf_context，两条链读的东西不一样。所以新建 verify_lean_parity.py 在
这条路径上逐根对拍 compute() 的每个返回字段。
其中一个坑：随机取窗口测不到信号分支。信号密度约 1/2000 根，头 12 个窗口命中
0 个，「一致」只覆盖了早退路径。改成一半窗口对齐到已知信号根，命中率才上来。
最终 180 窗口 / 两模式各 90 命中 / 零分歧。
生产实测（inner_ms，容器内同口径）：
compute_ms 646 → 132ms 4.89x
inner_ms 612 → 128ms 4.80x
lag_signal_ms 1410 → 683ms 完整链路，落回 800ms 线内
比 3.4 倍更好，因为是引擎 ~3.5x 叠 lean ~1.35x。
两点判读上的订正：
- lag_data_ms 那 576→490ms 是噪声，不要记在引擎账上。均值 721±36 vs
740±127，重叠；而且引擎本来就影响不到交易所与网络那一段。
- 仍有 44% 的根超 800ms，但尾部现在完全由数据腿主导（lag_data P90 1482ms
vs compute P90 237ms）。计算既不是瓶颈也不是尾部主因了，继续压计算换不到
尾部改善。800ms 那道闸取的是最近 30 根的中位数，683ms 已满足。
start.sh 加 SHADOW_LEAN（默认 1），设 0 可退回 full 复量两模式差异。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 04:24:08 +08:00 |
|
|
jackandCursor
|
54792fe015
|
把 compute_ms 拆成排队与纯计算，据此否掉换机器这个方向
compute_ms 一直是「提交进程池到拿到结果」的墙钟时间，排队和纯计算混在一个
数里，所以「加核有没有用」只能靠猜——这也是原先打算在 AWS 开第二台比 CPU
的依据。
worker 内部自己计时，连同父进程传入的提交时刻一起回传，拆出 queue_ms 与
inner_ms。实测中位 3ms / 695ms：2 个 worker 跑 3 个币并不排队，因为三个币的
收盘消息错峰到达。瓶颈全在单线程，加核压不到。
顺带把 README 里的内存数据从臆测的 1.5GB 改成实测 410MiB，并注明跨站点比
CPU 收益有限。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 03:02:06 +08:00 |
|
|
jackandCursor
|
181bca303f
|
影子测量改用框架吃单原语，并补齐容量与 maker 成交率两项测算
吃单查询换成 Hummingbot 的 OrderBook.get_vwap_for_volume：手写的 walk_book
返回的是按计价币吃单的加权均价，但框架的 get_price_for_quote_volume 返回
边际价、get_vwap_for_volume 收基础币量，两者语义不同。改为按基础币下单
（真实委托与 PositionExecutor.amount 均是基础币计价），深度不足由
query_volume/result_volume 判定，框架此时返回 nan 而非一个看似正常的
部分成交均价。
落盘完整盘口（双边 50 档）。此前只记三个固定名义额的成交价，这批数据的
寿命就等于那几个档位的寿命；存完整深度后任意资金量级的冲击都能离线重算。
仓位档同时从 1k/5k/20k 提到十万量级，此前低估真实仓位约两个数量级。
订阅成交流，按根按价位聚合。买卖分开存——多头在目标位挂卖出靠主动买盘
成交，混在一起会把成交率高估约一倍。BTC 每根总成交额中位与 210 天历史
的 volume×close 差 0.3%，可确认采集完整。
新增两项测算：
- 冲击不是绑定约束。32 万仓位单边冲击 0.19~2.39bp，对 8.58~20.64bp 的
预算只占 1.6~14.2%，冲击反推的资金上限 100~500 万。
- maker 成交率才是。止盈位被首次触及时，限价在该根价格区间中的位置
中位 k=0.28（63.9 万次触及，三币一致）；合并每根成交额后，32 万仓位
的全额成交率仅 30.1%/15.6%/1.5%。要 80% 全额成交，仓位须 ≤ 4.7 万
/1.4 万/0.26 万——比冲击反推的上限低 40~370 倍。
回测把这些止盈按「全额成交在目标价」计，故预算所依据的收益流本身需重估。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 02:39:47 +08:00 |
|
|
UbuntuandCursor
|
7e339d2a54
|
research: 影子交易器落在 Hummingbot 上，并修掉 Bitget 连接器的换根延迟
1m 腿的滑点余量只有几个 bp，所以要测的必须是生产路径的滑点——换个运行时
测出来的数就不作数。框架因此从「滑点已知后再定」提前到测量阶段就定为
Hummingbot（Spot/Perp 连接器均 v2.0，Bitget 是 Foundation Partner）。
新增 research/live/。前置测量：
- bench_compute.py 本机算力，1m 单币 0.318s、三币串行 1.38s
- venue_parity.py Binance 与 Bitget 同根信号重合仅 14.6~42.6%
- signal_sensitivity.py 0.25bp 扰动就换掉一半信号
- aggregate_robustness.py 但总体期望不降——脆的是信号身份，不是 alpha
- bitget_baseline.py 因此改用 Bitget 原生基线定预算：余量 BTC -0.13bp、
ETH +4.02bp、SOL +2.92bp。BTC 本就为负，只作延迟测量的参照物
运行时选型：
- parity_env.py 容器与本机信号逐一相同（下标、中枢数、checksum 全等），
容器内 0.26s/币反而更快。故 chanlun 直接挂载进容器，不必另起信号服务。
装进现有 .venv 那条路走不通：Hummingbot 要 numba>=0.61.2 与
aiohttp<3.14，与本机 Python 3.14 冲突
- latency_ccxt.py / latency_hummingbot.py / latency_compare.py 初测显示
Hummingbot 比 ccxt.pro 慢约 1030ms，90 根逐根配对里 80~97% 更慢
- probe_ws_action.py 否掉「丢弃 snapshot」的猜测：换根首条就是 update
- probe_hb_vs_raw.py 与 latency_attribute.py 四路归因——容器网络 2~18ms、
Hummingbot 处理 -10~-30ms，1350~1480ms 全落在解析方式上
- probe_ws_payload.py 定位根因：Bitget 换根会推一条带两根的消息
[上一根, 新一根]，而上游取 data["data"][0] 拿到的是上一根，新一根要等
下一条单元素消息
修复：
- patched_candles.py 处理消息里的全部元素。不能简单改成 [-1]——那样上一根
的收盘价会永远停在换根前约 1 秒的那次推送上，而信号对 0.25bp 都敏感
- verify_patch.py 60 根配对验证：拿回 1060~1090ms，与原始 WS 只差 5~14ms
已贴理论下限，19 根已收盘 K 线 OHLCV 逐根未变。折算 ETH 省 0.54bp、
SOL 省 0.42bp。此 bug 值得向上游反馈
影子交易器：
- shadow_hb.py 不下单，读连接器真实盘口按仓位吃单深度算成交价，与次根开盘价
（回测 entry_delay=1 的口径）相减，分解成延迟漂移、盘口价差、深度冲击。
盘口 10Hz 滚动缓冲 30 秒，把延迟变成自变量：每个信号记 0.5/1/2/5s 与实际
算完时刻各一个滑点值，本机算得慢也不影响能读出的曲线
- shadow_signal.py 信号计算隔离到子进程。0.26s 是纯 CPU 且 chanlun 受 GIL
限制，放进 asyncio 循环会把行情处理一起卡住
- shadow_report.py 首日延迟门槛与滑点曲线报表
不用 paper trade 测滑点：它的成交由 Hummingbot 自己的撮合模型模拟，
测出来是模型行为而非市场行为。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-27 23:51:57 +08:00 |
|