你这个问题很典型，订阅大量股票 Tick 后 CPU 飙高、策略卡顿，几乎是每个 QMT 实盘选手都会踩的坑。核心原因就一句话：你在让代码做大量“没必要做”的事情。
下面从“为什么卡”到“怎么改”，用大白话捋一遍。
先搞清楚：卡在哪？
QMT 的 Tick 数据是每 3 秒推一次。你订阅了 500 只股票，意味着每 3 秒你的回调函数会被触发 500 次，每次回调你如果都在跑一堆指标计算，CPU 不炸才怪。
卡顿通常出在这几个地方：回调函数里写太重了、对所有股票用同样的处理方式、不该实时算的指标非要实时算。
优化思路一：快慢分频，别让所有股票一个待遇
这是最有效的一招。核心思想是：大部分股票只需要“扫一眼”，只有少数候选股才值得“细看” 。
快频通道只做轻量筛选。订阅全市场快照（3 秒一次，数据量很小），回调函数里只做最简单的条件判断，比如“成交量是不是突然放大了 3 倍”。不计算任何指标，不做复杂逻辑。快频通道的任务就是找出那几只“有戏”的股票。
慢频通道负责深度计算。用一个定时器或者时间戳判断，每隔 1 分钟或 5 分钟，只针对快频筛出来的那几只候选股，统一拉历史数据算均线、MACD 这些指标。全市场 500 只票的复杂计算，缩减到 5 只票的精细加工，CPU 占用能降一个数量级。
实战价值很直接：避免了全市场每 3 秒重复算指标的恶劣情况，普通笔记本也能稳住。
优化思路二：订阅和全推，分清楚场景
很多人搞混了订阅和全推的用：
订阅行情是“点菜”。你主动告诉服务器只看这几只票，服务器就只推这几只。适合固定股票池，比如 ETF 轮动、50 只自选股日内 T0。带宽小、延迟低、资源。
全推行情是“自助餐”。服务器把全市场所有股票的最新行情广播给你，你被动接收。适合盘前扫全市场选龙头、盘中做异动雷达。代价是开盘前 10 分钟数据洪峰，老电脑风扇直接起飞。
老手常用折中方案：全推只做初筛，把符合条件的票放进列表，再用订阅精细跟单。
需要注意 QMT 单次订阅有数量上限（约 100-120 只），想扫全市场别硬塞订阅。
优化思路三：回调函数里，能省就省
Tick 回调函数是最耗资源的地方，因为触发频率太高了。几个立竿见影的做法：
把历史数据获取移出回调。不要在每次 Tick 回调里去调 get_market_data_ex 拉历史 K 线，那是灾难性的。历史数据应该提前下载好、缓存好，回调里只读缓存。
能提前算的就提前算。很多指标其实只需要在 K 线结束时更新一次，没必要随着 Tick 跳动每秒重算上百次。用定时器或时间戳控制计算频率。
减少循环，用向量化。Python 的 for 循环慢是出了名的。能用 pandas/numpy 向量化运算的地方，速度差几十倍。
优化思路四：主推初筛 + 订阅精跟的实战架构
如果你确实需要盯全市场找机会，可以这样搭：
第一层，主推全市场快照。用 get_full_tick() 或者快照订阅，每 3 秒扫一遍全市场。回调里只做最粗暴的过滤条件，比如涨速 > 2%、量比 > 5。这一步不涉及任何复杂指标，纯粹是数值比较。
第二层，动态订阅候选股。对第一层筛出来的票，调用 subscribe_quote 订阅 Tick 级数据。这时候你盯的可能就从 5000 只变成了 20 只，资源消耗天差地别。同时给不需要的票取消订阅，释放资源。
第三层，定时深度计算。用 run_time 定时器，每隔一段时间对候选股池统一拉数据算指标、做决策。不要把交易逻辑塞进 Tick 回调里。
最后一句
QMT 的策略性能优化，本质上是做减法。先问自己：这个计算真的需要每 3 秒跑一次吗？这只股票真的需要 Tick 级数据吗？这个指标真的需要实时算吗？
答案通常都是“不需要”。把不需要的砍掉，卡顿自然就没了。

欢迎交流，点头像添加咨询！！AA级上市券商，免费理财咨询，资金量大股票佣金万0.85，逆回购一折！专项两融4%；港股通资金大W0.7；北交所W2（提供快速通道抢碎股）！ETF万0.5，期权1.8元全包，ETF免申赎费！免费提供QMT+ptrade量化软件（含教程和答疑群）、万得宏汇套利软件、VIP极速通道、L2十档行情！！可选靓号开户！支持T0智能算法！