SK

量化系列三 做策略需要什么能力。 有个学弟要去ntu读硕，专业是计算机控制与自动化。本科是在ucl读的纯数。现在对于量化很有兴趣，正在进行一些学习，目前是刚刚开始，问我能不能给出一些学习上方法上的建议。包括常有人问，做策略到底要先学什么。我自己的答案可能有点反直觉，数学和编程只是门槛，过了之后就不再是最难的部分。下面这几样是我们比较看重的。 微观结构的直觉。 一笔单子进盘口之后到底发生了什么——排在谁后面、什么时候轮到你、被吃和被撤是两回事、盘口为什么会在某一刻突然变薄。教科书（GLFT、Avellaneda-Stoikov这些）给的是框架，框架不等于直觉。我们是靠盯真实的逐笔数据、一遍遍问“刚才这一下为什么会这样”，才慢慢有点感觉的。看得够多，才对异常敏感一些。 对回测的怀疑。 我刚开始也是看到一条漂亮的回测曲线就高兴，后来才慢慢学会第一反应先问“这哪儿算错了”。好看的回测很多时候是成交假设太松，用触碰价就算成交、不算排队、不算延迟。我们现在把回测也当成一个找问题的工具。看这个策略会在哪儿先出事：亏损边界在哪、最大回撤多深、延迟突然多50ms会怎样。学会不轻易相信自己的结果，花了我不短的时间。 风控放在收益前面。 如果没有风控意识，Ai可能给出一组逻辑完整的参数，但不一定知道这组参数在极端行情里会把风险敞口推到什么地步。对我们来说，做策略是先想清楚它在什么情况下会出问题，再谈它怎么赚。什么时候该停手，通常比什么时候能多赚一点更重要。 够用的工程能力。 不需要是顶尖工程师，但至少得能不自欺。能处理原始的逐笔数据、能让回测和实盘跑同一份代码（而不是“逻辑差不多”）、能在出问题时分清是策略的问题还是基建的问题。工程上差一点，很多时候连自己错在哪都定位不了。 怎么学，我的体会是：多学习，多从失败里学。对我帮助最大的，是跑崩了的策略，和之后花几天把它为什么崩搞清楚的过程。一次真实的教训很有意义。大致路径是：提一个假设，用尽量苛刻的方式回测。上很小的真钱，盯着实盘和回测的差距、把它解释清楚再来一轮。论文和框架当然要读，但读完最好拿真实数据自己验一遍，别照单全收。 写到这儿其实也没什么高深的结论。再说一条，大概能一直做下去的，不一定是最聪明的，是愿意一直怀疑自己已有结论的。一直不断更新迭代的。我们失败过很多次。这也是我们一直提醒自己的事。

野心 执行力 坚持 在这个时代会无限托举你到命运之上。

@limingpro_Guard 其实做了很多策略，有成功的也有失败的，太有的说了。

@StepOneAi 坐等策略部分干货

高频做市基建二下单和风控 聊完服务器层面，说下单。 下单层踩过最大的坑是以为下单就是发请求。其实不是的。下单是一个完整的链路，从策略决定报价到交易所确认成交，中间每一环都有延迟，每一环都可能出事。 我们现在的架构底线： 第一，核心报价走 WS，不用 REST。REST 是给你查余额用的，不是给你抢单的。哪怕是批量下单，也必须走 WS。利用本地 buffer 把这一次需要下单和撤单的指令打包存好，然后一次性 flush 出去，速度比走 REST 快得多。 第二，API 限流（Rate Limit）的硬隔离。不做市可能不知道，交易所的限流分两种情况：锁 API Key 和锁 IP。这两者的解决方案完全不一样。如果交易所是锁 API Key，用基础的令牌桶（Token Bucket）就可以了，给每个服务分配额度，防止一个策略抽风把 token 跑满导致全家卡死。但如果是锁 IP，光靠基础令牌桶就不管用了，你必须在底层建一个 IP 桶（IP Pool），一旦触及阈值立刻做动态切换。 第三，执行 p50 控制在 30us 以内。什么概念？从策略发出指令到网卡把包推出去，中间不超过30微秒。超过这个数，你的单子在盘面上就是慢的。 第四，网络分离。策略的发单绑定 EIP 发送订单组，这跟接收行情的 ENI 必须分开。不然遇到极端大行情，海量数据瞬间把带宽打满，你的撤单指令根本挤不出去，只能看着单子被吃。 再说风控。 风控和策略一定要分开。 我们的做法：行情延迟超过阈值（比如 500 毫秒），直接熔断不下单，并且立刻撤单。 为什么？不仅是因为“信息过期”500ms 的延迟意味着交易所服务器本身丢包或者通道严重卡顿。这个时候，交易所内部大概率已经发生了撮合，只是数据包还没推给你。如果你继续按手里的残影去强行定价，算出来的价格必然是错的，挂出去就是坏价。所以这种时候不仅不能挂单，还要立刻撤单防守。这不是策略问题，是底线风控问题。 Kill switch 单独管理最大回撤，和策略层完全解耦。策略层管赚钱，风控管别亏死。两个不能混在一起写，因为策略出 bug 的时候，你得能一键拔掉，而不是去策略代码里找开关。

@JustOutLier @lnkybtc 无所谓的，换一种想法，被抄说明你的东西有价值。

@StepOneAi @lnkybtc 坏处是、创意被抄袭、也变得前所未有地方便

以极低的资金和时间成本把所有事情做到 90 分的感觉真好，这是初创企业主最好的时代。

我最近一直在刻意训练自己，建立一种新的思考习惯。用长期主义对冲短期焦虑。

@TacticalBoulder 其实我也不知道哪有平台上有比较有意思的做市内容。之前开始做的时候也是很迷茫，和团队踩过很多坑。所以我最近想在x上去发相关的内容。

@StepOneAi 谢谢!我们现货这边用的是 ws,p50 和永续的一样,差异可能是 FIX 带来的,我们会试一下。 请问有没有哪个中文社交平台上有比较有意思的做市相关的内容?

高频基建一 服务器层面。 做加密高频做市，一切从行情延迟开始。很多人以为策略是核心，其实不是，基建才是。你的策略再强，行情比别人慢一拍，单子挂进去就是被吃的那个。跟Cto聊完，直接放几个硬指标。 服务器：AWS东京 ap1a-az4，EC2 c7i/c8i xlarge起步。别省钱用小土豆，做市不是跑网站，CPU缓存和内存带宽直接决定你的解析速度。我们20个instance一组，秒来秒关做ec2 hunting。 行情延迟 benchmark： Futures p50 local ts-T：1.3-1.8ms Spot SBE+Fix：400us-900us 怎么压下来的？ 第一，把行情模块打包成蒸馏好的低延迟探针，直接上传到服务器，辅助 EC2 搞延迟 hunting。 第二，Codec 零拷贝解析 JSON，别让数据在内存里搬来搬去。 第三，双轨订阅。同一个交易所的行情，两条线同时拉。为的是万一其中一条出现丢包，另一条能瞬间补上。 解析完的行情通过 IPC 回传给策略进程，本地维护订单簿深度，用 ringbuffer 管理。为什么选 ringbuffer？因为它不需要锁，写和读可以同时进行。 还有个细节：depth@0ms。 这东西不在交易所的 API 文档里，熟悉底层的人知道有这一档位。我们要维护的是绝对“当下”的快照，策略看的是此刻的盘口，给它50毫秒前的，决策就是错的。 行情快只是一半，另一半瓶颈在发单执行。 连接池必须预热保活，指令出来直接裸写。更关键的是网络分离：策略的发单绑定 EIP（弹性公网IP）发送订单组，这跟接收行情的 ENI（弹性网卡）必须彻底分开。只有这样，遇到极端大行情爆发时，才能保证整个服务器上所有instance 的定价依然准确，不会因为网络拥堵互相踩踏。 另外就是订单状态维护。 高频里的订单状态转换必须依靠极其严苛的状态机流转。Pending、New、Partial、Canceled，每一步都不能有模棱两可的灰色地带。遇到极端行情拔网线或者接口抽风，单子卡在未知状态，你的状态机怎么兜底处理，直接决定了下一秒是继续做市还是单边止损。 最后，为什么实盘核心代码的尽头依然是Rust？ 很多语言的 GC在极端插针行情里只要卡你两三毫秒，单子就被吃得骨头都不剩。Rust 虽然没有 GC 的烦恼，但底层原则是一致的：实盘盘中绝不临时 new 或者 malloc。所有内存必须在系统启动时一次性分配好，对象用完放回内存池，坚决不让操作系统在盘中去给你找内存碎片。 在微秒级的世界里，做市这件事，慢一点就是钱。不是少赚，是亏。

三天前这个号还是0关注。 现在X 170，小红书 700。 说实话没想到。一开始发这些就是发着玩的，不知道发什么，说点自己擅长的。写的内容也有点看点。 我不是什么大佬，我要永远当谦逊的学习者。 欢迎大家多来聊。提问也好，指出我哪里写错了也好，不同的玩法也好。做量化最怕的就是待在信息茧房里，多一个人聊就多一个视角。

@TacticalBoulder 是按 ⁠local ts - T⁠ 算的。（在我一篇的数据里其实也标明了这一点：⁠Futures p50 local ts-T：1.3-1.8ms⁠）。

@StepOneAi 请教下 p50 是按哪个口径算的？local ts − E 还是 local ts − T？两个差不少，想对齐一下再比。

@0xJason 大读枭，每天的任务之一就是读书。

@StepOneAi 偷学什么呢

还需要学习的东西好多 我喜欢现在的生活 每天都在学习 是内心的充实

太急是一种很强的负能量

当真实的分享者而不是活跃的运营者 做x的目标是不是为了盈利 而且需要有更多志同道合的伙伴 分享更多更好更优质的内容 时刻提醒自己不要回复和评论无聊的话

@JustOutLier 你这么久就注册了，我24年注册也是这两天才开始营业。

2011年注册、上周才开始营业的飘过