一、冲击成本与交易系统设计：低延迟系统、OMS、EMS
做量化交易这些年，我越来越觉得一个道理：策略再好，执行不行，一切都是白搭。你想想看，明明模型算出来有3个bp的套利空间，结果因为系统慢了半秒，订单进去的时候价格已经变了——这钱就没了。
冲击成本，说白了就是你的订单对市场价格造成的影响。大单砸进去，价格被推高，你买贵了；大单卖出来，价格被打压，你卖便宜了。这个差价，就是冲击成本。
那怎么控制它？靠的就是交易系统的三个核心组件：低延迟系统、订单管理系统（OMS）、执行管理系统（EMS）。今天我就把这套东西掰开揉碎了讲清楚。
1.1 低延迟系统：速度就是生命
低延迟系统，说白了就是让你的订单比别人跑得快。在量化交易里，尤其是高频交易，微秒级的差距就能决定胜负。
我个人习惯把低延迟系统拆成三个层面来看：
- 硬件层面：用FPGA做行情解析和订单生成，比CPU快一个数量级。我在项目中遇到过，同样的策略，从CPU迁移到FPGA，延迟从10微秒降到了0.5微秒。
- 网络层面：尽量用光纤直连交易所，减少交换机跳数。我记得有一次，为了省掉一个交换机，我们专门租了机房里的相邻机柜。
- 软件层面：用C++写核心逻辑，避免垃圾回收。嗯，这里要注意，Java和Python的GC暂停是低延迟系统的天敌。
核心指标：低延迟系统的目标通常是端到端延迟 < 10微秒，从行情到达到你发出订单，中间不能超过这个数。
为什么会这么苛刻？因为现在交易所的撮合速度越来越快，你慢1微秒，可能就排在了别人后面，成交概率直接下降。
1.2 订单管理系统（OMS）：订单的交通警察
OMS，全称Order Management System。它的职责很简单：管理订单的生命周期。从订单生成、发送、修改、撤销，到最终成交或拒绝，OMS都要管。
我见过不少团队，策略写得不错，但OMS设计得一塌糊涂。结果呢？订单发重了、撤单撤不掉、成交回报丢了——这些都是真金白银的损失。
一个好的OMS，至少要做到以下几点：
- 订单状态机：每个订单都有明确的状态，比如“已发送”、“部分成交”、“完全成交”、“已撤销”。不能有歧义。
- 订单路由：支持多交易所、多账户。比如你有A股和港股，OMS要能自动把订单发到对应的交易所。
- 风控检查：在订单发出前，检查资金是否足够、持仓是否够卖、是否超过单笔限额。我曾经因为忘了加风控，导致一笔大单把账户里的钱全花光了。
避坑指南：我曾经在OMS里漏掉了“订单超时重发”的逻辑。结果有一次交易所网络抖动，订单没发出去，系统也没重试，白白错过了一波行情。从那以后，我要求所有OMS必须支持自动重发，但重发次数不能超过3次，防止重复下单。
1.3 执行管理系统（EMS）：策略的双手
EMS，全称Execution Management System。它和OMS的区别在于：OMS管“发什么”，EMS管“怎么发”。
EMS的核心任务是最小化冲击成本。比如你要买100万股，直接一笔砸进去，价格肯定被推高。EMS会帮你拆单，比如拆成1000笔，每笔1000股，分散到一段时间内慢慢买。
常见的执行算法有：
| 算法名称 | 核心逻辑 | 适用场景 |
|---|---|---|
| TWAP（时间加权平均价格） | 按时间均匀拆单 | 流动性好的品种，比如大盘股 |
| VWAP（成交量加权平均价格） | 按历史成交量分布拆单 | 需要跟踪市场成交量的场景 |
| IS（Implementation Shortfall） | 动态优化，追求最小化冲击成本+机会成本 | 大单、流动性差的品种 |
| POV（Percentage of Volume） | 按市场成交量的固定比例下单 | 不想暴露大单意图的场景 |
我个人习惯用IS算法，因为它最灵活。它会实时计算“如果现在不买，价格涨了怎么办”和“如果现在买了，价格被推高怎么办”，然后动态调整下单速度。
注意：EMS的算法参数不能一成不变。我记得有一次，我用VWAP算法做一只小盘股，结果历史成交量分布和当天完全不一样，导致拆单节奏完全错乱。后来我加了实时成交量修正，才解决了这个问题。
1.4 三者如何协同工作？
低延迟系统、OMS、EMS，这三者不是孤立的。它们的关系是这样的：
- 策略层生成交易信号，比如“买入100万股”。
- EMS收到信号，拆成小单，比如“每5秒买入1000股”。
- OMS收到小单，检查风控，然后通过低延迟系统发送到交易所。
- 交易所返回成交回报，OMS更新状态，EMS根据成交情况调整后续下单计划。
你看，这是一个闭环。任何一个环节出问题，都会影响最终的执行效果。
下面这张图，是我自己画的一个简化架构，你可以看看它们之间的数据流：
嗯，这张图虽然简单，但核心逻辑都在里面了。你想想看，从策略到执行，每一步都有专门的系统负责，这样才能保证冲击成本被控制在最小范围内。
1.5 实战中的坑与经验
最后，我分享几个实战中踩过的坑，希望能帮你少走弯路：
- 不要迷信低延迟：有些团队为了追求极致延迟，把系统搞得很复杂，结果稳定性下降。我个人觉得，10微秒以内就够用了，再往下优化性价比不高。
- OMS的日志一定要全：每个订单的每次状态变化都要记录。我曾经因为日志不全，查一个bug查了三天，最后发现是网络丢包导致的。
- EMS的算法要回测：别以为VWAP就一定能跑赢TWAP。不同市场、不同品种，表现差异很大。我习惯用历史数据回测至少3个月，再决定用哪个算法。
- 风控不能只靠OMS：虽然OMS有风控检查，但最好在策略层也加一道。比如策略层可以限制单笔最大金额，防止OMS的风控被绕过。
一句话总结：低延迟系统是“快”，OMS是“稳”，EMS是“省”。三者配合好了，冲击成本才能降下来。
好了，这一章就讲到这里。下一章我们会深入讨论冲击成本的量化模型，看看怎么用数学公式来估算它。到时候见。