做私募、做量化的朋友应该都绕不开PB系统。这些年我被问得最多的一个问题就是恒生PB和讯投PB到底有什么区别同一个账户、同一笔委托放在恒生PB上和放在讯投PB上体验差距可以很明显但你要去问券商的客户经理他大概率只告诉你“两个都能开户”细节全靠自己摸索。这篇文章我会从业务定位、系统架构、交易链路、风控能力、策略开发这几个维度把两套系统掰开揉碎讲清楚再说说实际使用中容易踩的坑。1. 先搞清楚PB系统到底在解决什么问题1.1 一个私募产品从开户到交易要经过哪些环节PB是Prime Brokerage的缩写行业内叫主经纪商业务。理解PB系统之前先看一个私募产品是怎么运转的。基金产品成立后需要开立托管账户钱放在托管机构、证券账户股票持仓放在登记结算体系、资金账户用于日常交易结算。管理人要在券商端完成日常下单、调仓、资金划付、风控设置券商则要替管理人完成交易执行、日终清算、估值对账、合规留痕等一整套服务。这一整套服务的承载工具就是PB系统。你可以把它理解成“机构客户专用网银交易终端风控后台”的合体基金经理在客户端下单运营人员在管理端配参数风控人员设阈值交易产生后所有数据都会留痕并反馈到日终对账环节。如果拿物流公司做比喻PB系统就是车队的调度中枢每辆车是一个子账户司机权限是交易权限装载上限是持仓限额路线预算是资金额度全程GPS记录是合规留痕。不同厂商做的调度中枢设计思路完全不一样这就引出了恒生和讯投两个流派。1.2 为什么券商通常同时上两套PB系统很多券商在机构业务线同时采购了恒生PB和讯投PB也就是行业内常说的QMT机构版这绝对不是重复建设。原因是客户画像差异太大主观多头私募、债券私募需要多品种、多指令、严格合规审批这是恒生系的强项量化私募和程序化团队则要策略写入、历史行情、低延迟这恰恰是讯投系的强项。一套系统很难同时满足两种需求券商只好按客户分层提供不同的入口。另外从商业模式看PB系统的选型还会影响券商自己的运营成本。恒生系对券商后台的支持更完整讯投系在交易体验上更受量化客户欢迎。多家供应商并存既是市场竞争的结果也是业务现实的需要。所以你在同一家券商里同时听到这两个名字是件很正常的事。1.3 别把PB系统和极速柜台混为一谈这里必须先划清边界。PB系统解决的是“业务闭环管理”极速柜台解决的是“通道极限速度”。很多量化朋友一说速度就想到极速柜台但其实PB系统和极速柜台是两码事PB系统管账户、权限、风控、流程极速柜台是一套高性能的交易通道往往独立于PB系统存在。券商完全可以给同一个客户同时提供PB系统用于日常管理、极速柜台用于高频交易。所以后面比较恒生PB和讯投PB的速度时我们比的是两者作为PB系统的速度不是和专用极速通道比。2. 恒生PB把合规和运营放在第一位的重量级选手2.1 出身与设计理念恒生PB来自传统金融IT厂商恒生电子产品脱胎于机构资管和主经纪商业务设计的第一原则不是快而是稳和全。它首先考虑的是券商端如何管理客户、如何满足审计留痕、如何和托管行对账、如何开多层风控所以整体架构非常正统总部统一部署、前后台分离、权限分级、全程留痕。这种设计思路带来的好处很明显参数在任何地方被改动都会有记录交易指令和风控审批有完整流程清算对账表做得非常细致。对券商机构条线和私募运营来说恒生PB是“最省心”的系统之一出了问题可以一层一层排查业务脉络清清楚楚。2.2 核心能力盘点账户、风控、清算三件套第一是账户体系。恒生PB支持产品、单元、子账户多级架构一个产品下面可以开多个单元一个单元下面还能继续分子账户。这个结构非常适合做组合管理和分仓比如一个产品里不同策略分开核算、分开限额运营上互不干扰。第二是风控体系。事前、事中、事后三个环节都有工具事前可设置股票池、禁止交易名单、行业或个股持仓上限事中有单笔委托金额、单日累计成交、价格偏离度等校验事后有完整的交易报告和审计流水。对需要强合规的私募产品来说这套东西几乎是标配。第三是清算与运营支持。日终和托管行的对账、费用计算、规模报表、银行流水导入导出恒生体系做得很完整。这些功能对交易员来说没什么存在感但对私募运营来说是每天都在用的基础设施。2.3 使用中的真实感受优点和短板都很突出我见过券商端给私募开通的恒生PB客户端第一感觉是全面第二感觉是重。全面体现在股票、两融、公募申赎、债券回购、新股申购全在一个界面里重体现在很多功能对纯主观交易者是多余的菜单层级多、权限参数细新开户产品要逐项配置首次上线至少要留出一整天的联调时间。交易速度上恒生PB并不适合高频。它的订单路径大致是客户端、券商前置系统、PB交易服务、柜台、交易所中间经过的模块多每次校验都要花时间全链路延迟常见在几十毫秒到一两百毫秒级别。对于日内高频、抢涨停这种需求这套系统完全不合适对于低频调仓、TN策略反而没有人会在意那几十毫秒。另一个短板是策略与数据能力。恒生PB本身没有为Python策略准备历史行情库和回测环境也不提供tick级行情接口。想做程序化交易只能走它自己的API而且API申请、测试、上线整个流程偏重文档和开发环境相比新兴厂商要传统得多。如果你是个纯量化团队第一天用恒生PB就会觉得处处受限。2.4 谁在用恒生PB实际部署中恒生PB的典型用户是主观多头、债券策略、复合策略以及需要强审计强合规的机构客户。它们不追求极速但希望系统可靠、后台完善、券商运营配合度高。如果纯粹是个人大户想跑程序化恒生PB大概率不是首选后面说的讯投系会更顺手。3. 讯投PB从量化交易终端长出来的轻骑兵3.1 讯投和QMT的关系讯投科技的产品大家更熟悉的名字是QMT也就是行业内常说的量化极速交易平台。很多券商把QMT接入自己的PB业务体系做成“讯投PB”或者“QMT机构版”。它一开始并不是严格的PB系统而是服务于交易员的行情、交易、策略一体化终端后来才慢慢补上多账户管理、子账户权限、券商风控等PB能力。这个出身决定了它的气质默认用户是“要自己写策略、要快速下单、要盯盘”的交易型选手。讯投PB的界面里行情、分时、K线、交易、策略编辑器是主体复杂的产品管理和审计报表反而排在后面。如果你习惯用同花顺或普通交易软件那一套交互逻辑上手QMT基本没有障碍。3.2 策略开发能力Python策略引擎与数据底座讯投PB最吸引量化的地方是策略能力。它内置了Python策略框架提供init、handlebar之类的回调函数盘中每个周期tick或bar驱动一次策略逻辑下单、撤单、查持仓都有对应接口。对熟悉Python的人来说从研究到实盘的距离被大大缩短。用一段示意代码说明最小结构# 示意代码QMT风格策略骨架非完整可直接运行版本 def init(ContextInfo): ContextInfo.symbol 600000.SH ContextInfo.set_bar_type(1m) # 使用1分钟K线驱动 def handlebar(ContextInfo): # 每个1分钟K线触发一次 if len(Close) 20: return ma_fast sum(Close[-5:]) / 5 ma_slow sum(Close[-20:]) / 20 if ma_fast ma_slow: # 示意买入一定数量 buy(ContextInfo.symbol, 100, now) elif ma_fast ma_slow: # 示意卖出一定数量 sell(ContextInfo.symbol, 100, now)注意这只是框架示意不代表可以直接实盘运行。但可以看出策略门槛比恒生PB低很多。真要做量化从研究到实盘落地的时间往往能压缩到原来的三分之一。另外QMT本身就带行情数据模块支持下载历史K线盘中订阅实时行情部分券商部署下还能开通逐笔或十档行情。回测也可以用平台内置的本地回测来跑。这些对量化团队太重要了传统PB系统根本不会给你这些东西。3.3 速度、风控与多账户相对快且够用交易速度方面讯投PB的订单路径比恒生PB短客户端或策略引擎、QMT网关、券商柜台、交易所。因为省掉了不少业务校验环节内部处理能达到毫秒级。不过最终延迟还取决于券商柜台类型和客户机房位置在同一个机房里测普遍比传统PB快不少。速度快的代价是风控厚度下降。讯投PB也有权限、额度、黑白名单、频率限制等风控但更偏“交易时控制”重逻辑不重流程。对主观私募需要的审批流、多层复核、完整审计报告它的粒度不如恒生细。这不算缺点而是定位差异选型时心里要有数。多账户管理上讯投PB支持母账户和子账户结构也可以在一个客户端里同时管理多个产品账户日常多产品并行交易比恒生轻便。不过要记住分仓是虚拟的资金划拨和对账最终还是要走PB业务后台完成。3.4 谁在用讯投PB实际部署中讯投PB的典型用户是量化私募、程序化交易的个人团队、日内回转选手、期权组合交易者以及希望用Python把策略快速落地的小型量化团队。它们并不需要特别厚重的事后审计更在乎能不能把想法写成代码、能不能快一点成交。4. 恒生PB与讯投PB一张对照表看懂核心差异4.1 十个维度的核心对照对比维度恒生PB讯投PBQMT机构版厂商出身传统金融IT巨头资管和机构业务起家量化交易平台厂商行情加交易终端起家系统定位主经纪商业务管理系统重运营与合规交易执行与策略平台重交易与开发部署形态券商总部集中部署前后台分离券商接入QMT网关客户端和策略端部署交易链路客户端到前置到PB服务到柜台到交易所客户端或策略到QMT网关到柜台到交易所延迟量级几十毫秒到一两百毫秒常见内部处理毫秒级实际取决于柜台策略开发支持API门槛高生态传统内置Python策略框架门槛低行情数据基本不提供策略历史数据历史K线、实时行情、部分L2风控体系事前事中事后完整强审计以事中交易控制为主流程略薄多账户管理产品单元子账户组合管理强母子账户多产品并行轻便适用人群主观私募、债券或复合策略、强合规机构量化私募、程序化团队、日内交易API开放度专有API申请流程重Python外部库上手快表格只能给大致印象实际操作中还有两个变量会影响体验券商自己的部署方式和产品具体版本。同一套恒生PB在不同券商上的延迟可能差一倍同一个讯投QMT不同券商开放的行情等级和权限也不一样。所以在做决定前一定要让券商提供准确信息不要只看产品名字。4.2 延迟差异的本质OMS思维与EMS思维如果把两套系统放在一起看本质恒生PB更像OMS也就是订单管理系统讯投PB更像EMS也就是执行管理系统。OMS的使命是让每一笔订单都有来路、有审批、有留痕、可回溯EMS的使命是用最快路径把订单送进市场。恒生PB的所有设计优先满足前者讯投PB的所有设计优先满足后者。两者取舍不同导致你在界面、API、延迟、报表上看到的所有差异本质上都来自这个底层定位的区别。这里补充一句不要以为用讯投PB就一定能跑高频。PB系统永远是PB系统它的风控、网关、柜台对接逻辑决定了它不能和专用极速柜台比。真正的高频量化往往是把极速柜台接到独立的程序化接口PB系统负责日常管理和低频部分各司其职。4.3 一个订单在两套系统里的路径对比拿一笔限价买入举例子。在恒生PB里订单发起后要经过客户端校验、前置系统接收、PB服务做产品单元子账户权限校验、股票池与限额风控、资金可用检查、柜台、交易所回报原路返回。每一步都为稳但每一步都耗时。在讯投PB里路径明显更短策略引擎或客户端发出委托、QMT网关做必要的权限与频率检查、柜台、交易所。风控照样有但很多非必要的业务流程被精简。把两条路径并排放在一起看延迟差异就不是玄学而是模块数量决定的。5. 到底怎么选管理人视角和券商视角都要看5.1 管理人自测先看策略频率再看接口需求我给团队选型时习惯先让他们回答四个问题第一你是人工下单还是程序化下单如果纯人工下单恒生PB和讯投PB都行主要看券商服务如果程序化下单直接优先考虑讯投PB或专用接口。第二策略的持仓周期是多长中低频策略持股几天到几个月对延迟不敏感选系统时优先看稳定性和运营配置日内、刷单类策略则必须考虑链路短的方案。第三你需要哪些市场股票、两融、期权、期货、债券、公募申赎每家券商的支持范围不同别只看系统名要落到券商那份开通权限清单上逐项勾选。第四你的合规审计要求强不强如果是受强监管的机构产品恒生PB的事前风控与留痕链路更匹配如果是自有资金量化产品用讯投PB的开发效率明显更高。把这四个答案写下来再去和券商谈基本上不会被销售话术带偏。5.2 和券商沟通时的三个确认项第一问清楚系统版本和接口文档。很多券商说的“QMT”其实是某个历史版本接口能力和数据能力都有出入。自己要拿到该券商实际部署的版本文档不要拿网上搜到的通用文档当准。第二问清楚行情等级。日线、分钟线、tick、十档、逐笔开放哪些等级直接影响策略设计。尤其做日内或者高频统计的团队没有逐笔数据很多策略根本没法做。第三问清楚开通成本和限制。子账户数量、策略运行环境、是否需要托管机房、是否支持算法单这些通常写在服务协议里不要口头确认一定要落到纸面。还有一个容易被忽略的点同一家券商能不能同时给你开两套PB。很多券商是可以的尤其是“产品账户挂恒生PB、量化产品挂QMT”的并行方式。这样既能满足合规产品运营又能跑程序化策略是不少成熟私募的通行做法。5.3 开通、测试、切换的完整流程实操中从申请到正式上线的流程大致是产品开户、确定PB系统类型、券商后台配置产品参数与风控、开通模拟环境、客户进行接口联调或客户端试跑、小资金实盘验证、逐步放量。这个流程看起来简单但每一环都可能卡住。切换系统时更要注意程序化策略在恒生PB和讯投PB上的接口完全不通用。如果你之前用恒生API开发迁移到QMT等于重写一遍反过来也一样。策略代码、历史行情、风控参数、子账户结构桩桩件件都要重新配。宁可先在模拟环境跑两周也不要做无缝切换的美梦。6. 实操中常见的坑与排查经验6.1 开发环节的三个坑第一个坑把讯投PB当成真正的极速通道。量化团队测试时发现很快但上线后因为券商网关压力变大、柜台排队延迟明显上升。处理方法是提前做压力测试不要拿一点小单量得到的延迟数据当峰值指标。第二个坑恒生PB的API和讯投QMT的Python库是两套完全不同的体系。不少团队想“一套策略两头跑”最后发现接口细节差异多到需要维护两份代码。建议一开始就锁定主用系统只在极少数情况下做双系统适配。第三个坑历史数据口径不一致。QMT的本地历史行情需要先下载证券代码、复权方式、停牌处理都可能和回测数据有差异。回测跑得漂亮、实盘变形的案例很多根子往往出在数据对齐环节。建议在正式上线前用至少一个月的历史逐笔或分钟数据做一致性校验。6.2 风控配置的两个典型事故事故一价格偏离度设得太小。我曾经遇到过运营人员把“现价上下1%”设成风控阈值日内热点票波动一大委托直接被系统拒绝券都买不进去。现实中这个参数很难一刀切要结合策略开盘价和波动特性来设置热票和冷门票要分开对待。事故二子账户共享母账户额度时互相挤占。多个子策略同时下单单笔看起来都不超限但还没到收盘就把整个产品的总限额用完了。解决方法是给每个子账户预设分仓上限而不是只依赖产品级风控。分仓参数在恒生PB上配置位置比较深在讯投PB上相对简单但两者的逻辑都一样宁可提前分好不要事后补救。6.3 分仓与对账的细节很多新手以为子账户是独立的资金账户其实子账户只是PB系统内的虚拟分仓资金仍然在母账户和托管体系里。子账户的盈亏、持仓、手续费都会被记录但实际资金划拨需要走PB后台操作。日终对账时恒生PB的自动化程度高讯投PB更依赖运营人员手动核对。如果你同时用两套系统对账逻辑还不一样这个细节一定要提前知道并制定双份对账流程。6.4 最后说几句实在的我自己接触过的团队里其实很少只停留在“恒生PB还是讯投PB”这种二选一的层面。成熟的做法是先确定自己的产品结构和策略特性再把PB系统的角色定清楚它是你的合规运营底座还是你的策略交易通道。如果两者都要就接受“并行使用两套系统”的成本。另外一个很实用的建议是选型时让券商开放一个测试环境用自己的真实策略用例跑一遍再决定。看一百页PPT不如亲手下一笔单。系统快不快、稳不稳、接口符不符合习惯实盘一跑全知道。