私有化部署：门槛不在软件，在 GPU
把系统装进自己的机房只是第一步。真正决定项目成败的是：机器怎么配、模型怎么选、离线环境怎么活、出问题时谁来排障。这一页把这些写清楚，包括我们做不到的部分。
先说结论
私有化的门槛不在软件，在 GPU
这一点必须先说清楚，否则后面全是空谈：语音合成与大模型推理 在 CPU 上不具备可用性。不是「慢一点」，是慢几十倍 —— 一句话要等几十秒， 客户早挂了。所以私有化必须配 GPU 服务器。
上表是本项目在真实机器上的实测口径，不是厂商宣传数字。 CPU 能做到的如实标注，做不到的明确写「必须 GPU」。
私有化部署时，语音合成与大模型跑在客户自己的 GPU 服务器上，全链路不依赖公网。
为什么不能「先用 CPU 跑起来，以后再说」
因为 CPU 版本不是「性能差一点」，是时序根本不成立： 对话要求「客户说完 1–2 秒内接上」，而 CPU 合成一句要几十秒。 上线后最典型的现象是客户说完话等三秒没人应答，以为掉线，然后挂断。
这类项目最后都会变成「系统上线了但没人用」，还背了一个失败项目的名声。 所以我们的做法是：先做容量测算，机器不到位就不上线。
容量测算
并发路数怎么算出来，不是猜出来
「能支持多少路并发」这个问题，取决于三件事：GPU 型号与显存、 单路对话的算力开销、以及你能接受的响应延迟。下面给的是测算方法。
| 输入项 | 怎么定 | 定错会怎样 |
|---|---|---|
| 峰值并发路数 | 不是日均通话量，是同一秒同时在通话的最大路数 | 按日均算会严重低估，高峰期大量呼叫排队甚至失败 |
| 单通平均时长 | 从接通到挂断的实际时长，按行业差异很大 | 算错会连带算错 GPU 占用时长 |
| 可接受首句延迟 | 客户说完到系统出声的时间，建议 ≤ 2 秒 | 放宽到 5 秒以上，客户会以为掉线 |
| 语音合成质量档位 | 高保真（48kHz）与轻量档的算力开销差数倍 | 选了最高档但卡不够，只能降档或限流 |
| 大模型规模 | 参数量越大越"懂"，但显存与延迟同步上升 | 盲目上大模型，结果并发路数砍半 |
| 是否同时跑 ASR | ASR 可以放 CPU，但量大时也要给资源 | 全挤在一台机上互相抢资源 |
测算的正确顺序
- ① 先定「峰值并发路数」和「可接受延迟」—— 这两个是业务约束，不是技术选择。
- ② 再定语音档位与大模型规模 —— 这两个决定单路开销。
- ③ 然后实测单卡能扛几路（用你的真实话术跑压测，不是看参数表）。
- ④ 最后乘安全系数（建议 1.5–2 倍）并留出扩容空间。
三个常见的高估陷阱
① 用「最大吞吐」当「并发数」。 跑分时的吞吐是在理想条件下测的，真实对话里有停顿、有打断、有检索等待， 资源利用率达不到峰值。
② 忽略知识库检索的 CPU 争抢。 检索本身很快，但并发上来后 CPU 会被占满，反过来拖慢音频处理。
③ 忘了录音落盘与审计写入的 IO。 全量录音是个持续写盘的动作，磁盘慢的时候会直接卡住通话线程。
离线运行
内网部署最容易翻车的三个地方
「支持私有化」和「真的能在没有外网的机房里跑起来」是两件事。 下面这三个问题在离线环境里几乎必现。
「启动卡住但不报错」的排查口诀
内网部署遇到「服务起不来但没有错误信息」，第一件事查出网请求： 看进程有没有在等某个域名的 DNS 解析或 TCP 连接。 这类等待通常有很长的超时（几十秒到几分钟），表现出来就是「卡住了」。
第二件事查模型与词典路径：文件存在但路径写错、权限不足， 也会表现为长时间无响应。
数据与安全
私有化之后，数据这一层还要做什么
很多人以为「数据在自己机房」就安全了。实际上内部泄露、 越权查看、离职带走数据，这些风险在私有化环境里一样存在。
号码加密存储 + 摘要主键
号码以加密形态落盘，主键是 HMAC 摘要。查询、列表、导出默认都是脱敏形态。
密钥指纹校验
库里记录密钥指纹，换密钥开库时直接报可读错误，绝不静默返回空结果。
明文查看需授权且留痕
查看完整号码单独授权，每次查看写审计日志（谁、何时、看了哪条）。
多角色权限
看板、毛利率、名单、取证包分属不同权限，默认拒绝。拿一把万能钥匙等于没有审计。
录音留存可配
保留天数、是否录音、是否随通话结束立即归档，都可按行业口径配置。
取证包导出
监管或客户追责时，可按时间段导出通话转写、录音、质检结果、操作日志的完整证据链。
交付与运维
交付物里必须有什么
私有化项目最常见的失败不是技术，是「交付完之后客户不会运维」。 所以交付物清单要写清楚。
| 交付物 | 内容 | 缺了会怎样 |
|---|---|---|
| 部署包 | 离线安装包 + 全部模型与依赖 | 内网装不起来，或装起来但缺模型 |
| 部署说明 | 硬件要求、安装步骤、配置项含义、验收标准 | 换个人就装不了，运维强依赖原班人 |
| 配置手册 | 每个配置项的作用、默认值、改错的后果 | 客户改了配置发现没反应，误以为系统有问题 |
| 排障手册 | 日志位置、常见故障定位步骤、健康检查方法 | 出问题只能等原厂，响应时间不可控 |
| 容量测算书 | 按客户峰值并发算出的卡型与数量 | 扩容时无人知道该加什么 |
| 验收报告 | 实测的响应延迟、识别准确率、并发压测结果 | 无法证明系统达到合同要求 |
验收要测什么
建议在验收时现场跑这四项：① 客户说完到首句出声的延迟； ② 十句真实业务话术的识别准确率； ③ 峰值并发下的通话成功率； ④ 关闭录音后磁盘上确实没有音频文件。
第四条容易被忽略，但它是最容易出事的 —— 客户以为关了录音，实际一直在录， 这在个人信息保护上是直接的红线。
运维责任要说在前面
私有化之后，机器、网络、磁盘、备份、系统补丁都是客户自己的责任。 我们能提供的是软件层面的支持与排障指导。
这一点在签约前要写清楚，否则出问题时容易变成「你说能私有化， 那为什么磁盘满了也要我们自己处理」这种扯不清的局面。
常见问题
私有化决策期最常问的四条
这四条基本决定了「要不要私有化」这个决定本身。
什么情况下必须私有化？
三种情况基本只有私有化能满足：
- 数据不得出机房。金融、医疗、部分国企有明确要求，没有折中方案。
- 内网离线运行。生产网与公网物理隔离的环境。
- 需要深度定制。要改代码、接内部系统、定制特殊流程。
反过来，如果只是「希望数据安全一点」，但并没有强制要求，那托管部署 + 加密存储 + 权限管控在成本上更划算。
能不能只私有化一部分（比如模型私有、管理后台托管）？
技术上可以做到混合：模型在内网、管理后台在云端。但这种架构通常不划算 —— 号码与录音仍然要在两边传输，等于把「数据不出机房」这个主要理由自己破坏掉了， 同时又多背了一套跨网架构的运维成本。
如果确实需要，更常见的混合方式是「生产在内网、运营报表用脱敏数据外发」， 而不是把核心链路拆开。
机器我们自己买还是你们供？
两种都可以，建议客户自己买。理由：机器在客户名下，后续扩容、 保修、资产处置都更直接；而且我们不做硬件生意，不存在推高配置的动机。
我们会给出明确的配置要求（卡型、显存、内存、磁盘、网络）， 客户按自己熟悉的渠道采购即可。如果客户希望我们代采，也可以，但要提前说清 硬件质保的责任划分。
升级怎么办？每次升级都要停服务吗？
软件升级需要短暂停机，通常可以安排在业务低峰期（如凌晨）。 模型升级更谨慎：新模型要先在小流量上跑对照，确认效果不劣化再全量切换， 并且保留回滚版本。
这一点很重要 —— 模型不是越新越好，某个新版本在通用测试集上更好， 但在你的行业话术上可能变差。所以升级必须是可回滚的。
迁移路径
从托管迁到私有化，怎么迁不翻车
很多客户是先托管跑起来、量上来或合规要求变化后再迁私有化。 这条路径是可行的，但有几个地方必须提前想到。
先确认哪些数据能迁、哪些不能迁
名单、授权凭证、退订记录、通话历史、质检结果、话术与知识库 —— 这些都要迁。其中退订记录最关键：如果迁移丢了退订名单， 迁完之后会把明确拒绝过的客户再打一遍，这是最严重的一类事故。
所以迁移的第一件事不是搬数据，是核对退订记录条数与摘要是否一致。
密钥要沿用还是重新生成
如果沿用原密钥，迁移后号码可以直接解密；如果重新生成， 历史号码需要做一次全量重加密迁移，否则会出现「换密钥开库报错」的情况。
建议：沿用原密钥，并把密钥按客户自己的密钥管理规范保管（离线备份）。 重新生成只在有明确安全要求时才做，且必须安排迁移窗口。
并行跑一段时间
不要一次性切断。建议新环境先跑一条业务线或一部分名单， 与旧环境并行一到两周，对比通话成功率、延迟、识别准确率。
并行的另一个作用是验证线路：新环境的线路接入可能与原来不同， 主叫号码变化会影响接通率，这一点必须用真实数据验证。
切流与回退预案
确认新环境稳定后再切流，并保留旧环境一段时间作为回退。 回退预案要写清楚：什么情况下回退、回退需要多久、回退期间数据怎么处理。
没有回退预案的迁移，本质是在赌不出问题。
迁移里最容易出事的两个点
① 退订记录丢失或格式不兼容。 旧环境的退订标记可能是「客户 ID」，新环境需要「号码摘要」， 两者对不上就会漏掉。迁移前必须做一次映射核对。
② 主叫号码变更导致接通率骤降。 客户对新号码的接听意愿明显更低，而且新号码没有历史信誉积累。 如果可能，尽量沿用在用的主叫号码。
运维现实
私有化之后，日常要盯的五件事
这部分内容通常没人写在方案里，但它决定了系统半年后还能不能用。
一、磁盘水位
录音与审计明细是持续增长的。如果没有清理策略，磁盘早晚会满， 而磁盘满的表现通常是「通话中断」或「服务起不来」，很难第一时间想到是磁盘问题。 建议按留存期自动清理，并设置水位告警。
二、GPU 温度与降频
长时间满负载运行后，GPU 会因温度过高降频，表现为「响应变慢」。 这类问题不会报错，只会让人觉得「系统最近变卡了」。需要监控温度与频率。
三、模型与依赖的版本一致性
升级某个组件时，要确认与之配套的依赖版本。语音链路上任何一环版本不匹配， 表现都是「识别变差」或「合成异常」，而不是明确的报错。
四、备份与恢复演练
备份做了不等于能恢复。建议每季度做一次恢复演练： 从一个备份把系统完整拉起，确认数据完整、服务可用。
五、密钥保管
号码加密用的密钥如果丢失，历史数据将无法解密。必须离线备份， 并且明确谁保管、存放在哪、交接时怎么移交。
这五件事都不复杂，但需要有人负责。建议在交付时就指定运维负责人， 并把这份清单交给他 —— 而不是等到出问题再说。
一句话总结
私有化到底买到什么
用一段话把前面所有内容收口，方便你判断这件事值不值。
你买到的是三样东西：数据不出机房的确定性、 长期单通成本的可控性、以及能改得动的能力。
代价是：必须有 GPU 服务器、必须自己承担运维、必须有人能看懂部署手册。 如果这三样里有一样做不到，私有化会变成一个长期的负担而不是资产。
所以我们给客户的建议通常是：先用托管跑通业务、验证名单与话术， 等通话量上来或者合规要求变化了，再考虑迁移。这样即使迁移不顺， 业务也不会停 —— 因为业务逻辑已经在托管环境里验证过了。