企业自建实时语音 AI 助手：传输层和智能层分开选型|云服务|内网|服务器|蓝屏事件|语音ai助手|运维|选型

实时语音大模型和开源编排框架在近一两年相继成熟，企业做语音助手比两年前容易得多。选型时除了比较大模型，还要看数据能不能出内网、电话能不能接进来、部署在哪里。本文把语音助手分成传输层和智能层，整理五个条件、四个误区和五个选型步骤。

一、近一两年的两个变化

出现了实时语音大模型。 OpenAI Realtime、Gemini Live、通义千问 Omni、豆包实时语音等模型可以直接听语音、出语音，响应快，用户插话时也能停下来。
开源编排框架好用了。 LiveKit Agents（Apache 2.0 许可）[1]、Pipecat（BSD-2 许可）[2] 把语音识别（ASR）、大模型（LLM）、语音合成（TTS）串成一条低延迟的处理流程，换一家服务商通常只改几行配置。

用开源框架，一个下午就能搭出 demo。现在做出来已经不难，要比较的是用哪种方式做，做完能不能装到自己的环境里。智能客服、AI 外呼、AI 面试、远程问诊、内网业务助手，这几类场景对数据、入口和成本的要求差别很大。路线选得不合适，往往到上线前后才发现。

二、语音助手的两层：传输层和智能层

传输层：把用户的声音低延迟地送到 AI，再把 AI 的声音送回用户。包括各端的录音和播放、网络差时抗丢包、消除回声，以及接入电话和会议设备。这部分属于实时音视频（RTC）。
智能层：听懂用户的话，想好怎么回答，再说出来。有两种做法：一种是端到端实时语音模型，一个模型直接语音进、语音出；另一种是级联，ASR、LLM、TTS 三段分别选型。

各家方案的区别，基本都是这两层怎么搭配。只比较用哪个大模型，传输层就漏掉了。

三、影响选型的五个条件

数据能不能出内网。 通话音频、转写文字、模型推理，哪些可以放到企业外面？金融、医疗、政务、司法类业务一般要求全部留在内网，这样大部分公有云方案就用不了。
用户从哪里进来。 只有 App 和网页，还是还要接电话热线、小程序、会议室终端？要接电话，传输层就得支持 SIP 线路（IP 电话通用的信令协议），还要处理按键、挂断、免提回声这些电话里才有的情况。
响应速度和打断。 用户能接受的是一两秒内回话、一插话 AI 就停。延迟不只来自模型，也来自网络传输。用户用信号不好的手机、或者打电话进来，体验和办公室里用浏览器试 demo 不一样。
成本怎么算。 公有云服务一般按分钟或用量收费，用量小时省事，用量大或通话时长没法预估时，账单也不好估。自建或私有化要先投服务器和人力，之后的成本比较好预估。
部署在哪里。 公有云、客户机房，还是不通外网的专网？有没有国产 CPU 和操作系统的要求？要不要离线安装和升级？

四、四个常见误区

误区一：选型就是选模型。 模型决定回答的质量；传输层决定能不能听清、能不能及时打断、电话能不能接进来。传输层有问题，换模型解决不了。
误区二：demo 有多快，上线就有多快。 demo 一般在网络稳定、麦克风好的环境里跑。上线后会遇到网络丢包、8kHz 电话音质、免提回声，所以要用真实线路和真实网络测。
误区三：端到端模型一定更好。 端到端模型在自然度和延迟上确实有优势，但主流模型大多以云服务的形式提供，很难装进内网。知识库检索、调用业务系统、话术审核这些企业常见需求，用级联方案更容易一段段控制和替换。
误区四：开源就不花钱。 框架没有授权费，但自己部署后，媒体服务器运维、弱网优化、各端 SDK、电话和设备接入、国产化适配都要自己做，花的是人力。

从这四个误区看，实时语音 AI 选型时，传输层和部署环境要和模型一起比较。 数据边界、电话入口、国产化和离线交付这些条件，每家企业都不一样；路线选得不合适，往往到上线前后才发现。

五、传输层的三种方案

方案一：公有云 RTC + 对话式 AI 服务

上线速度：最快，在控制台开通即可
数据放在哪：主要在厂商云上，部分厂商有私有化版本
收费方式：多数按分钟或用量
电话和会议设备：各家不同
国产化与离线交付：看厂商的私有化版本
谁来运维：厂商
生态与灵活度：限于厂商提供的功能

方案二：开源自建（LiveKit Agents / Pipecat 等）

上线速度：做 demo 快，正式上线的部分要自己补
数据放在哪：自己的服务器
收费方式：框架免费，服务器和模型费用自付
电话和会议设备：部分框架有 SIP 组件，要自己部署和维护
国产化与离线交付：要自己适配
谁来运维：自己的团队
生态与灵活度：社区大，插件多

方案三：私有化商业引擎（如 STMLink SAI Agent）

上线速度：需要部署，按项目交付
数据放在哪：企业内网，可以不连外网运行
收费方式：按并发数授权，可以一次性买断
电话和会议设备：自带 SIP 电话、H.323 会议终端、GB28181 摄像头接入
国产化与离线交付：支持国产 CPU 和操作系统，有离线安装包
谁来运维：厂商交付，企业运维，有商业支持
生态与灵活度：兼容 Pipecat，可以接任意 ASR / LLM / TTS

以上开源和云服务的各项依据各方公开文档整理，以对方官网为准。写着"各家不同"的项，选型时要逐家确认。

六、智能层：端到端模型还是级联

端到端实时语音模型

自然度与延迟：最好，语气和停顿更像真人
能否全部私有化：主流模型大多是云服务
可控性：只能整体调，单独换某一部分很难
成本：按用量收费
适合：重视体验，数据可以上云

级联 ASR → LLM → TTS

自然度与延迟：取决于三段各自的速度，流式处理可以做到秒级
能否全部私有化：可以，三段都有能在内网部署的开源模型
可控性：每段都能单独换，可以加知识库、加审核
成本：私有化后主要是硬件和运维成本
适合：重视合规和成本，需要深度定制

两种做法可以同时用。比如在同一套传输层上，不敏感的场景接云端实时语音模型，敏感业务走内网的级联方案，不少企业就是这样做的。

七、选型步骤

确定数据边界。 把音频、转写文字、对话记录、业务数据逐项列出来，标明能不能出内网。智能层能不能用云端模型，由这一步决定。
列出所有入口。 App、网页、小程序、电话热线、会议室。只要有电话或会议设备，传输层就必须支持 SIP 接入。
选智能层。 数据可以上云、重视体验，选端到端模型；必须留在内网、要接知识库和做审核，选级联，三段都选能私有化的模型。
选传输层。 对照上面的对比，看部署环境、设备接入、国产化、收费方式，以及团队里有没有人能运维。
在真实场景里做 PoC。 用企业自己的网络、线路和模型，测这几项：接通后多久开口，插话后多久停，识别准确率，转人工的比例，目标并发下服务器的负载。达标了再扩大使用范围。

以 STMLink SAI Agent 为例，它是"私有化传输层，智能层随意选"这一类：

AI 以服务端身份加入实时音视频频道，和 Web、App、小程序、电话里的用户在同一个频道里对话。底层的 Python SDK 已经公开发布（）[3]。
pip install srtc
兼容 Pipecat：SDK 自带 Pipecat transport。已经用 Pipecat 写好的语音 agent，把 Daily 或 LiveKit 的 transport 换成 SRTC 的就能用，其余代码不用改。
不绑定模型厂商：可以直接接通义千问 Omni、豆包、Gemini Live、OpenAI Realtime 等实时语音模型，也可以自己组合 ASR、LLM、TTS。大模型用 OpenAI 兼容接口，可以换成部署在内网的开源模型，比如用 vLLM 部署的 Qwen 系列。
可以完全离线部署：媒体服务器、Agent 进程和 ASR、LLM、TTS 都能装在内网，支持 x86、ARM 和信创环境，对话音频和文字都留在内网。
能接电话：通过会议室连接器的 SIP 接入，用运营商的 SIP 中继或企业已有的 IP-PBX 接听和拨打电话。
传输层指标：SRTC 在音频丢包 50%、视频丢包 30% 时不卡顿，端到端媒体延迟低于 400ms（不含模型推理时间）[4]。

八、不同情况怎么选

互联网产品，数据可以上云，想尽快上线：用公有云 RTC 的对话式 AI 服务，或直接用实时语音大模型的云服务。先把需求验证出来，用量大了再算成本。
有开发团队，愿意自己运维，用户主要在公网：用 LiveKit Agents 或 Pipecat 自己搭，社区和插件多。上线前要估一下弱网优化、各端 SDK 和电话接入还要补多少工作。
数据不能出内网，有国产化或断网要求，要接电话和会议设备：用私有化的实时音视频引擎，加内网部署的级联模型。常见于政务热线、医院预约和随访、法院和检察院业务咨询、金融客服、企业内网助手。
已经用 Pipecat 做了原型，现在要部署到客户机房：保留现有代码，只换传输层，改动最小。

不管选哪种，都建议先挑一个问题范围明确的场景，用真实网络和线路做 PoC，看测出来的数据再决定。

你认为企业自建语音助手时，哪一层最容易被忽略？欢迎留言讨论。

关注风远科技，可站内私信交流实时语音 AI 落地，或站内搜索「STMLink」了解私有化实时音视频方案。

资讯来源 / 数据说明