 jackandCursor
|
0a0fd2f682
|
影子信号走增量：清空十币 560ms → 247ms
compute() 每根新建 TF_DF 换成按 (symbol, timeframe) 缓存的流式对象。worker
进程被复用，所以缓存跨根存活；2 worker 轮流拿 10 币，每个 worker 最终缓存
全部 20 条流，实测内存开销落在噪声里（597→598MiB）。
## 前提先验，否则整个改动建立在沙子上
init_stream/append_bar **没有 trim**，dataframe 靠 pd.concat 无界增长。所以
增量必然让窗口每根 +1，只能周期性重建拉回，两次重建之间窗口是 [W, W+500]
而非恒定 W。于是必须先证明 compute() 输出对窗口长度不敏感——否则增量等于
静默换掉一批信号，不报错不崩。
verify_window_sens.py：三币 75 个信号窗口，+200/+500/+1000 三档全部逐字段
一致。step39 说的是「命中率在 2000 根饱和」，饱和不等于不变，这是两回事。
## 对拍
verify_incr_parity.py：三币 1,800 根、21 个命中、各跨 1 次重建边界，逐字段
零分歧。不能引用 HANDOFF §5.5——那验的是 bsp_list 那条链的整体哈希，而这里
是 find_fast_bsp3 那条链，且流式对象跨根复用，状态污染只会让信号悄悄换一批。
对拍顺带定论一件读代码定不了的事：cal_bi_list **不依赖** klc.trend。
init_stream/append_bar 从不调 cal_trend（它只在 get_klc_list 里），所以追加
出来的 klc 其 trend 恒为 UNKNOWN，而批量构建的有值；两者结果逐字段相同。
HANDOFF §5.5 那句「bi.py:221 读 klc.trend，笔的计算依赖它」不成立——221 行
在 cal_trend 自己的循环里，读的是它自身的序列状态。
## 重建不走 init_stream
init_stream 是逐行 dataframe.iloc[idx]，正是引擎提速刚修掉的反模式：2001 根
要 238.5ms，而批量 lean 只 74.3ms，慢 3.2 倍。第一版用它重建，10 个币启动时
各来一次，清空反而涨到 1686ms。改用 TF_DF(df, lean=True) 重建，append_bar
靠 _ensure_stream_state 就能接上。
## 实测
append_bar 21.8ms vs 批量 lean 重建 77.7ms = 3.56x，与研究侧测的 3.7x 一致。
拆解：add_indicators 全表 7.5ms（34%，为加一根重算 2001 行）+ cal_bi_list
整表重扫 11.1ms（51%）+ concat 1.4ms。这两项都在引擎侧，值得反馈。
十币 / 2 核：清空 560→247ms，排队 92→10ms，纯计算 219→108ms。判定从
「加 worker 无用，唯一出路是增量」变成「宽裕，无需优化」。
注意 inner 108ms 里 chan 构建只占约 22ms，其余是 build_htf_zones /
find_fast_bsp3 / attach_htf_context。**瓶颈已不在 chan 构建**，再压增量收益
有限。
stream_bars 落到 latency CSV：恒等于 2001 说明缺口判定在每根都回退重建、
增量静默失效，这一点从耗时上看不出是哪一环。实测窗口稳定长大。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 06:17:47 +08:00 |
|
|
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 |
|