构建了一个开源网关，让现有的 ElevenLabs / OpenAI / Deepgram 应用只需更改一行代码即可在 Sarvam AI 上运行。

印度语音 AI 的问题不在质量，而在迁移成本。如果你在印度运营 IVR、催收机器人或方言辅导应用，你很可能在向一家国际提供商支付语音费用，而该语音从未为印地语、泰米尔语或 Hinglish 代码混合而设计。你知道 Sarvam 的 Bulbul 和 Saaras 能更好地处理你用户的语言。你可能已经测试过它们。 然后你打开迁移指南，估算出两个工程师周的工作量，于是它就永远留在了待办事项中。让我确信这才是真正瓶颈的是：Sarvam 维护了四份手写的迁移指南——ElevenLabs、Cartesia、Deepgram、Gemini。这四份文档的全部目的就是帮助某人重写可正常运行的代码。而 ElevenLabs 那份指南的结尾有一节叫“Common mistakes”，列出了五个 bug，其中一个被他们描述为“the single most common migration bug”。那不是警告。那是缺失基础设施的规格说明。 我构建的 sarvam-bridge 在前端说各家厂商的方言，在后端说 Sarvam 的语言。更改你的基础 URL，保留你的代码。那五个记录在案的错误中的每一个在结构上都不可能发生：ElevenLabs 返回原始字节；Sarvam 在 JSON 中返回 base64 → bridge 负责解码。Sarvam 要求提供 language_code；其他厂商的客户端都不会发送 → bridge 根据 Unicode 文字检测出来。pitch/loudness 在 bulbul:v3 上静默失效 → bridge 将其丢弃并附带警告头。2500 字符限制 → bridge 在 danda（।）处分块，而不是在单词中间。v2 和 v3 的说话人名称不能互换 → bridge 会进行验证并重新映射。 真正困难的印度语言特定部分 分块。你不能像分块英语那样分块印度语言文本。一个只知道 . 的分割器会把整个印地语段落视为一个句子，因为印地语用 danda 结束句子。更糟的是——通过索引切片 JS 字符串可能会把辅音与其 matra 分开。क 和 ि 会分离，文本渲染成乱码，语音输出也会出错。硬分割通过 Intl.Segmenter 以字素粒度进行。 音频重组。分块意味着每个块返回一个 WAV。Buffer.concat 会在流中间留下 44 字节的 RIFF 头，解码器会将其播放为可听见的咔嗒声。必须解析每个容器，提取 PCM，写入一个头。 奥迪亚语陷阱。ISO-639 称其为 or。Sarvam 期望 od-IN。发送错误的代码，会得到 400 错误，且没有任何提示说明哪个字段出错。让我花了一个小时。 声音选择。Sarvam 按关键错误率发布每种语言的说话人质量，我认为没有多少人使用它。mani 用于旁遮普语男性，ratan 用于英语，shubh 用于印地语/泰卢固语/卡纳达语。我最喜欢的细节——varun 的 CER 很好，但 Sarvam 将其标记为反派/悬疑角色声音，因此被排除在自动选择之外。放在惊悚片里没问题，放在银行 IVR 里则是灾难性的。 值得知道的成本问题 IVR 菜单和代理脚本每天要合成相同的字符串数千次，每次都要计费，每次返回字节完全相同的音频。缓存处理顺序重复。但突发情况下——广播发出，300 个来电者在同一秒内点击同一个提示——所有请求都会错过缓存，因为还没有任何请求填充它。单飞合并将这些请求合并为一次上游调用。在禁用缓存的情况下测量：100 个并发相同请求 → 1 次上游调用。 然后压力测试在我自己的代码中发现了六个 bug 包括一个远程 DoS：带有天城文或表情符号的声音 ID 会导致进程崩溃，因为 Node 会在非 latin1 头值上抛出异常，而我正在将调用者输入回显到警告头中。普通的印度语言输入变成了崩溃向量。还有一个测试因错误的原因通过——缓存掩盖了我实际测试的内容。绿灯不等于正确。 现在有 168 个测试，在 3,500 个恶意请求中零 5xx，0 个依赖 CVE。MIT 许可，与 Sarvam 无关，基于公开文档构建：https://github.com/thekartikeyamishra/sarvam-bridge 如果在座有人比我更了解 Sarvam API，我非常愿意接受指正。