外呼系统集成：先算清机器和接口，再谈上线
装一套环境是小时级的事，项目周期耗在机器买错、接口没定主数据和验收没有口径上。这一页讲三件事：硬件怎么从并发倒推、和现有系统怎么接、上线六个阶段各自拿什么验收。
先说卡点
外呼系统集成，难的不是装软件
装一套环境是小时级的事。真正消耗项目周期的是三件事： 机器买错、接口没定清、以及验收标准从头到尾没人写下来。
一个典型的外呼项目，从立项到稳定运行，花在「部署」上的时间可能只占一成， 剩下九成分布在：线路与号码的报备、与 CRM 的字段对齐、话术与知识库的定稿、 以及上线后头两周的调参。把这一页当成装机指南会失望， 它更像一份项目风险清单。
最常见的三个坑，回头看都很朴素。第一是机器买反了： 先按「要跑大模型」买了卡，结果真正吃资源的是并发合成； 或者只买了 CPU 机器，演示时能出声，一上二十路就卡成断续。 第二是接口没定主数据：外呼和 CRM 双向同步，两边都能改状态， 跑一周之后没人知道哪条记录是真的。第三是验收没有量化口径： 到验收那天才开始讨论「什么叫接通率达标」，于是项目在会议室里再拖一个月。
这三个坑的共同点是：它们都不在技术方案里，而在约定里。 技术方案可以写得很漂亮，约定写不清，项目照样会烂尾。 所以下面每一节都尽量落到「谁在什么时间交付什么、拿什么判定通过」。
还有一条要先声明：本页给出的所有算例都是测算演示， 不是性能承诺。真实产能必须在你的线路上、用你的话术、按你的并发做压测才成立 —— 任何跳过压测直接报路数的方案，都值得要求它给出测试条件。
机柜装好只是起点，接口和验收才是项目的主体。
一个必须先问的问题
这套系统上线后，谁是它的运维责任人？托管形态下是服务商； 私有化形态下必须落到具体岗位，包括模型升级、驱动、证书、以及 「显存被别的进程占了」这类问题的处理人。这个角色没人认领时， 系统会在第三个月开始「时好时坏」，而且没人能解释为什么。
形态选择
托管、私有化、混合，前置条件各不相同
三种形态的技术能力可以做到一致，差别在数据边界、扩容方式和运维责任。 选错形态的代价通常不在首年，而在第一次扩容或第一次监管问询的时候。
托管
系统跑在服务商侧，你只对接接口与号码。前置条件最少：一条可用线路、 一份合规材料、一个能收数据的接口。扩容是提工单，小时级生效。 适合验证阶段与话务量波动大的业务。要确认的是数据存储地域、导出能力、 以及停服时的数据返还方式。
私有化
整套系统装进你的机房或专有云。前置条件最硬：GPU 服务器（带合成与推理时）、 内网对象存储（放录音）、可用的内网时间同步与证书方案、 以及一个能处理模型版本的人。它的价值不是「更安全」这句口号， 而是数据物理不出内网、升级节奏自己掌握。
混合
识别与业务逻辑在本地，语音合成与大模型推理在有 GPU 的一侧。 它解决的是「数据不能出内网，但硬件预算一次到不了位」这个现实矛盾。 代价是多一条链路要监控，且责任边界必须在合同里写明： 哪一段出问题由谁定位、响应时限多久。
离线部署的额外前置
完全离线时，模型安装包、依赖镜像、时间源、证书链都要在本地备齐。 升级不再有「云端自动更新」，每次迭代都要走一遍内网分发与回滚验证。
硬件测算
从并发倒推显存，而不是从型号倒推并发
「要什么配置」这个问题没有通用答案，但有通用算法。 按下面五步走，你能算出自己那台机器该多大，也能判断供应商给的配置是否离谱。
第一步：算出真实并发路数
并发不是「一路能打多少通」，而是同一时刻有多少通在通话中。公式： 并发 = 日呼量 ÷ 有效拨打秒数 × 平均通话时长 × 冗余系数。 举例：日呼两万通、有效时段六小时（21600 秒）、平均通话四十秒， 理论并发约 37 路；乘 1.3 的冗余，规划 48 路。 冗余不是浪费，它吸收的是时段内的峰谷差。
第二步：拆开三段算力需求
一通电话经过三段计算：识别、推理、合成。三段里只有后两段必须有 GPU。 识别按「实时率」衡量 —— 处理一秒音频需要多少秒计算，低于 1 才能跟上说话； 推理与合成按「每秒需要生成多少 token / 多少帧波形」衡量， 再乘并发，就是这张卡每秒的产出要求。
第三步：显存按三块相加
显存 = 模型权重 + 每路运行时开销 × 并发 + 音频与上下文缓冲。 权重是固定值，取决于模型大小与精度（半精度大约是单精度的一半）； 运行时开销主要是缓存，随并发近似线性增长，这一项才是并发能力的真正瓶颈。 所以「这张卡能不能跑」问的不是权重装不装得下，而是装下权重之后还剩多少给并发。
第四步：单卡压测，得到可承载路数
不要用厂商给的「单卡支持多少路」当结论，要在自己的环境里压一次：固定话术、 固定音频集、逐级加并发，记录首帧延迟的分布而不是均值。 当作到 20 路时首帧延迟的九十分位开始抬头，可用路数就在那附近， 而不是延迟均值翻倍的那一刻 —— 均值会把少量长尾完全抹平。
第五步：按比例缩放，留一张卡的余量
压测得到单卡可承载路数之后，卡数 = 规划并发 ÷ 单卡路数，向上取整再加一张。 加的这一张不是浪费：它承担单卡故障、模型热更新和突发峰值。 举例，规划 48 路、压测单卡 20 路，则需要 3 张，实际配 4 张。
哪些数字不能省
测算表里至少要留四项：并发路数、单路首帧延迟上限、识别语种与是否加载方言、 以及是否在同一张卡上同时跑合成与推理。最后一项最容易被忽略 —— 两套模型抢同一张卡，压测得到的路数会比单独跑任何一套都低得多。
四种集成方式
接口接在哪一层，决定它以后好不好改
四种方式没有优劣，只有适用。选错的典型症状是： 业务每改一次规则，就要发一次版。
CRM 双向同步
外呼结果写成 CRM 的活动记录，CRM 的名单变更推回外呼任务。 关键在于定主数据与冲突规则：同一条记录两边都改过时，以时间戳新者为准， 还是以某一侧为准。这一条不写清，跑一周就会对不上账。
工单系统对接
通话产生的待办、承诺回拨、投诉受理，落成工单并带上下文： 通话标识、已确认字段、客户原话摘要。工单系统是「有人必须做点什么」的地方， 所以这里传的必须是可执行信息，不是一段转写全文。
呼叫中心话路集成
两种接法：SIP 中继把话路接到 AI，或者由 AI 通过接口发起呼叫。 SIP 接法的延迟与音质可控、可复用现有号码；接口接法上线快， 但延迟多一跳，且主叫透传受对方平台限制。要按「谁持有号码」来选。
数据仓库导出
把通话清单、意图标签、转写结果按日批量导出到数仓，供 BI 与合规调取使用。 这一层不做实时，做的是口径稳定：字段定义一次定死， 加字段可以，改字段含义必须发版本说明。
| 集成方式 | 数据方向 | 实时性 | 主要工作量 | 典型风险 |
|---|---|---|---|---|
| CRM 双向同步 | 双向，逐条记录 | 准实时，秒级到分钟级 | 字段映射 + 冲突规则 + 幂等设计 | 两边同时改，状态互相覆盖 |
| 工单系统对接 | 单向，外呼到工单 | 实时，通话结束即创建 | 上下文裁剪 + 指派规则 | 工单里塞全文转写，坐席不看 |
| 呼叫中心话路 | 音频双向，信令面独立 | 严格实时，延迟敏感 | SIP 参数对齐 + 编解码协商 | 单向无声、主叫透传被改写 |
| 数据仓库导出 | 单向，外呼到数仓 | 批量，按日或按小时 | 字段口径定义 + 增量策略 | 字段含义悄悄变化，报表失真 |
| 组合使用 | 按层拆分 | 混合 | 先做一条主链路，再补旁路 | 四条一起开工，谁都验收不了 |
上线流程
六步，每步都有可判定的交付物
没有交付物的阶段等于没有结束。下面每一步都写了「交什么」和「怎么判过」， 照着走，验收会从一场争论变成一次核对。
把成功标准写下来
交付物：一页纸的目标与验收口径，含通话量、并发、时段、以及三个过程指标的定义。 判定：业务、IT、合规三方在同一份文件上签字。没有这一页，后面的争议都没有裁判。
先开线路，再谈系统
交付物：可用中继、已报备号段、SIP 参数表。判定：用测试号真实拨打并接通， 双向有声音、主叫显示正确、并发压到规划值不掉线。
装好并压出真实产能
交付物：环境检查清单、单卡与整机压测报告（含首帧延迟分布）。 判定：规划并发下延迟九十分位不超过约定上限，连续跑二十四小时无内存增长。
定稿，而不是持续修改
交付物：话术版本、知识库条目表（每条带出处与负责人）、禁区清单。 判定：用一批历史真实录音做离线回放，未命中率与错答率在约定范围内。
一条主链路先跑通
交付物：字段映射表、接口文档、联调用例与结果记录。 判定：从名单进、拨号、通话、写回、生成工单这条主链路端到端跑通， 重复提交不产生重复记录。
小批量上线，再谈全量
交付物：灰度报告、回滚方案（已验证）、运维手册与值班表。 判定：灰度批次的过程指标达到阶段 01 的口径，且回滚在演练中真的跑起来过。
为什么把「线路」放在「环境」之前
线路与号码的报备周期通常是周级，而装环境是小时级。顺序排反的结果是： 系统早就装好了，团队天天在等号码，等号码下来时话术和人员的注意力已经散了。
为什么灰度要单独算一个阶段
灰度不是「先打一百通看看」。它是一个有退出条件的小规模运行： 跑多久、跑多少量、看哪几个指标、什么情况下回滚，都要在开始之前写下来。 否则灰度会变成「一直在灰度」，而问题被日常运营稀释掉。
回滚方案必须演练
没验证过的回滚方案等于没有方案。私有化环境尤其如此： 模型包回滚、配置回滚、数据库结构回滚是三件不同的事， 其中数据库结构往往不可逆，要在升级前就想好降级路径。
| 阶段 | 交付物 | 验收判据 | 不通过的典型原因 |
|---|---|---|---|
| 01 立项与口径 | 目标与验收口径文件 | 三方签字，指标定义无歧义 | 「接通率」没定义分母 |
| 02 线路与号码 | 中继、号段、SIP 参数表 | 真实拨通、双向有声、并发达标 | 主叫透传被上游改写 |
| 03 环境与算力 | 压测报告、环境清单 | 九十分位延迟达标，长跑稳定 | 只测了均值，长尾没看 |
| 04 话术与知识库 | 话术版本、条目表、禁区清单 | 离线回放的未命中与错答可控 | 话术一直在改，从未定稿 |
| 05 集成联调 | 映射表、接口文档、用例结果 | 主链路端到端通，且幂等 | 字段含义两边理解不一致 |
| 06 灰度与移交 | 灰度报告、回滚方案、运维手册 | 过程指标达标，回滚演练通过 | 无人接手日常运维 |
排障
日志要能按一通电话串起来
分散的日志等于没有日志。排障快不快，取决于能不能用一个标识 把信令、音频、识别、决策、写库这五段拼成一条时间线。
推荐的索引是通话标识：拨号时生成，贯穿全程，写进每一条日志。 有了它，一次查询就能拿到这一通电话的完整链路；没有它， 你只能按时间窗口去猜哪几条日志属于同一通，而这个猜测在有并发时几乎必然出错。
日志分三层放：信令与话路（呼叫状态、编解码、丢包与抖动）、 媒体与识别（音频流时间戳、中间识别结果、置信度）、 业务（意图判定、话术节点跳转、写库结果与耗时）。 三层的保留期可以不同，但索引必须一致。
日常要盯的四个数：首帧延迟的九十分位、识别低置信度占比、话术节点的异常跳出率、 接口失败重试次数。这四个一起变差，通常指向同一个下游 —— 某个服务在拖慢整条链路，而不是四个独立故障。
排障的纪律是先分层再定位。现象先归到话务、媒体、识别、业务四层中的一层， 再往里查。跳过这一步直接翻代码，最常见的结局是花两小时看识别日志， 而问题出在中继的单向音频上。
呼不出去
看信令：有没有发起、上游返回什么码。整批失败多半是注册失效或中继并发耗尽； 零星失败看号码状态与频控。与识别、话术无关，别去改配置。
接通了没声音
先分清单向还是双向。单向多是编解码协商不一致或 NAT 穿透问题； 双向无声看音频流是否真的到达服务端。这一层与模型无关。
声音断续、反应慢
看首帧延迟分布与丢包率。若延迟的九十分位随并发上升而抬高，是算力不足； 若与并发无关而抖动高，是网络或线路质量问题。两者的处理完全不同。
听懂了但答错
看转写文本与检索命中的条目。文本对而答案错，是知识库问题； 文本错，是识别问题；命中为空却仍然作答，是阈值配置问题。
数据没写回
看接口调用与重试记录。注意幂等：重试成功但重复写入，表现为「同一通电话三条记录」， 这类问题在业务侧看起来像数据错乱，实际是接口设计问题。
偶发、无法复现
先看是否与并发或时段相关。偶发问题最忌「重启一下试试」—— 重启会清掉现场，让下一次复现的成本更高。先留快照再动手。
常见疑问
落地阶段最常被追问的四件事
这四条会直接影响排期和预算，值得在开工前就对齐。
能不能先上线再补合规材料？
技术上可以，业务上不建议。线路与号码的报备是外呼的前置条件， 没有报备的号段随时可能被停；而被停的那天，你既有在跑的任务会中断， 又要在没有数据的情况下向业务解释。
更现实的问题是：合规材料通常决定了你能拨哪些号段、什么时段能拨。 这两件事直接改变并发测算的输入。先上线后补材料，等于把测算重做一遍。
已有呼叫中心，还要不要另建一套？
多数情况不需要另建。用 SIP 中继把 AI 接到现有话路上，号码、录音、质检、 报表都能沿用，坐席侧几乎无感。需要另建的场景是：现有平台的并发已满、 或者不支持标准 SIP 对接。
判断方法很简单：让现有平台提供 SIP 对接参数与一条测试中继。 拿不出来，才考虑另建；拿得出来，先接一次再说。
私有化和托管，能不能中途切换？
能，但要按「新建一套再切流量」的方式做，而不是原地迁移。可迁移的是： 话术与知识库（结构化配置）、字段映射、拒呼库、以及历史录音与标签； 不可直接迁移的是模型版本与索引结构，需要在目标环境重建。
切换前必须确认导出能力，并要求导出物是通用格式。带不走的数据， 会变成你下一次议价时的沉没成本。
上线后谁负责日常调优？
必须落到具体岗位，通常是业务运营加一名技术对接人。日常调优有三件固定动作： 每周看未命中清单并按频次补条目、每月抽核意图判定、每次话术改动前做离线回放。
这三件事没人做，系统会在两三个月内「越用越笨」—— 不是模型退化，而是业务变了而知识库没变。这一点在验收时就要写进移交清单。