OctaFuse 2.4.0统一接入DashScope的ASR与TTS语音能力

当语音识别（ASR）与语音合成（TTS）真正进入企业级业务场景时，API 网关面对的早已不只是一次普通的 HTTP 请求：ASR 既可能是同步转写，也可能是异步任务；TTS 既可能返回完整音频文件，也可能持续输出音频流；而实时语音场景还需要基于 WebSocket 双向传输文本、事件以及二进制音频帧。

在 2.4.0 版本中，OctaFuse 将这些差异化的语音调用方式统一纳入路由体系。应用既可以继续使用 OpenAI 兼容音频接口，也可以直接接入 DashScope 原生实时协议；而网关则负责依据路由配置选择阿里云百炼上游、完成请求转换，并记录真实用量与计费信息。

Provider 导入能力也同步覆盖阿里云百炼标准服务、百炼 Coding Plan 以及千问 AI 平台 Token Plan，原本需要逐项手工填写的套餐专属端点，现在无需再单独配置。

与此同时，管理面的认证机制也迎来一次关键升级：原先单一的 `MASTER_KEY`，被具名、可轮换、可吊销、可分配权限的 **Admin API Keys** 所替代。不同系统、自动化流程和运维场景都可以使用彼此隔离的最小权限凭证，提升安全性与可管理性。

一句话看懂 2.4.0：

> **将 ASR、流式 TTS 与实时语音统一纳入同一套路由和计费体系，再通过具名密钥按调用身份与业务场景精细划分管理权限。**

## 01｜DashScope 语音能力接入统一路由

2.4.0 新增了 DashScope 协议族，以及一组清晰的音频操作定义与适配器。这里的 DashScope 指的是上游协议类型，而非单纯的供应商名称：同一个 Alibaba Cloud Provider 可以同时提供 OpenAI 兼容端点与 DashScope 原生端点。

对于调用方来说，常用接口入口仍然保持简洁统一：

| 能力 | 请求入口 | 说明 |

| --- | --- | --- |

| ASR | `POST /v1/audio/transcriptions` | 保留 OpenAI 兼容的 multipart 调用方式 |

| TTS | `POST /v1/audio/speech` | 支持完整音频返回与 HTTP 流式输出 |

| 实时 ASR / TTS | `GET /v1/dashscope/realtime` | 通过 WebSocket 转发 DashScope 原生事件 |


*应用侧依然调用统一的 `/v1/audio/speech`；路由池会根据模型与策略选择 Alibaba Cloud 上游，再由目标配置决定实际使用的 DashScope 模型与适配器。*

这张路由图体现了 OctaFuse 一贯采用的分层设计：左侧的请求入口（Request Surface）描述客户端如何发起调用，中间的模型层负责能力映射，右侧的上游目标（Upstream Target）则说明请求最终如何到达具体供应商。公开模型名与真实的 Provider model 相互解耦，因此应用无需感知供应商侧的模型命名、协议差异或端点细节。

跨协议调用并不会依赖对模型名称的猜测。配置路由时，需要明确指定适配器：例如将 OpenAI multipart ASR 转换为 Qwen-ASR 或 Fun-ASR 请求，或者将 OpenAI speech 请求转换为 SpeechSynthesizer、Qwen-TTS、MiniMax 等 DashScope 接口。显式适配器不仅能让配置错误更早暴露，也避免网关在运行时进行不透明的协议推断。

## 02｜阿里百炼与千问 Token Plan：统一路由 LLM、ASR、TTS

阿里云体系中的标准服务与订阅套餐，使用的是不同的 API Key、额度体系和 Base URL。2.4.0 在 Provider 导入目录中将其拆分为三套独立预设，从而避免套餐端点与按量端点被混用：

| Provider 预设 | OctaFuse 直接配置的能力 | 使用时注意 |

| --- | --- | --- |

| **阿里云百炼** | OpenAI 兼容对话、DashScope 原生 ASR / TTS 与实时音频 | 使用百炼标准 API Key 和按量服务端点 |

| **阿里云百炼（Coding Plan）** | 兼容 OpenAI、Anthropic 的文本模型调用能力 | 需使用 Coding Plan 专属 Key，并接入 `coding.dashscope.aliyuncs.com`；不能与按量端点混合使用 |

| **千问 AI 平台（Token Plan）** | OpenAI、Anthropic 兼容对话；`qwen-audio-3.0-tts-plus` TTS；`qwen-audio-3.0-realtime-plus` 实时语音 | 使用 `sk-sp-` 套餐 Key 与 `token-plan.cn-beijing.maas.aliyuncs.com` 专属端点 |

在实际接入过程中，只需从 Provider 导入目录选择对应预设，填写套餐 Key，再导入或创建所需模型并挂载到路由池即可。OctaFuse 会保留套餐专属端点设置，避免请求误走阿里百炼按量地址，导致套餐 Credits 无法生效。

根据阿里云当前公开的 Token Plan 模型清单，除千问 `qwen3.8-max`、`qwen3.7-max`、`qwen3.7-plus`、`qwen3.6-plus` / `flash` 外，团队版还覆盖 DeepSeek、Kimi、GLM、MiniMax 等主流文本模型。2.4.0 中的音频路由则直接对接套餐内的 `qwen-audio-3.0-tts-plus` 与 `qwen-audio-3.0-realtime-plus`，因此不仅可以将该套餐作为 AI 编程或 Agent 的文本上游，也能在支持范围内接入语音合成和实时语音能力。

需要特别说明的是：Token Plan 与 Coding Plan 的官方适用范围，是兼容的 **AI 编程与智能体工具中的交互式调用**，并不适用于自动化脚本、工作流平台或自定义应用后端。OctaFuse 提供的是协议适配、统一路由与凭证配置能力，并不会改变套餐本身的授权边界。虽然官方套餐还列出了图片和视频模型，但这些模型依赖独立的生成接口，并不属于 2.4.0 Token Plan 预设当前直接覆盖的路由范围。

## 03｜从文件请求到实时 WebSocket

文件音频、流式输出和实时语音拥有不同的请求生命周期，2.4.0 分别对这些路径进行了适配处理：

- **同步文件 ASR**：将上传内容转换为上游模型所要求的请求体，并把识别结果映射回兼容响应。

- **异步文件 ASR**：接收 DashScope 可访问的公网 `file_url`，完成任务提交与结果查询；网关不会替调用方上传文件。

- **HTTP / SSE TTS**：支持完整音频响应以及持续音频分片输出，避免因大文件产生无界缓冲。

- **Realtime ASR / TTS**：通过 `/v1/dashscope/realtime` 建立 WebSocket 连接，用于转发 DashScope 的 task 或 session 事件，以及对应的二进制音频帧。

实时连接依然使用 OctaFuse 用户 API Key 进行鉴权，并通过网关公开模型完成路由：

```text

wss:///v1/dashscope/realtime?model=&operation=

Authorization: Bearer

```

网关只会替换启动事件中的模型名，后续文本内容、二进制音频帧以及服务端事件都保持原协议透传。Cloudflare Worker 与 Node.js Proxy 均支持这条实时语音链路，并共享鉴权、初始连接故障转移、用量记录和路由配置能力。

## 04｜ASR 与 TTS：按时长、Token 或字符分别计费

语音识别与语音合成虽然都属于音频能力，但它们并不适合共用同一种计费单位。OctaFuse 会依据模型定价配置，自动选择相应的计费口径：

| 能力 | 计费模式 | 用量来源 | 请求日志 |

| --- | --- | --- | --- |

| ASR | 按秒 | 上游返回的音频时长；文件接口缺失时按文件信息估算，并记录来源 | `billing_kind=audio_per_second`、`audio_duration_seconds` |

| ASR | 按 Token | 上游 `usage` 中的 input、output、audio 与 text tokens | `billing_kind=audio_tokens` 及各类 Token 数量 |

| TTS | 按字符 | 上游返回的 `usage.characters` | `billing_kind=audio_per_character`、`audio_characters` |

ASR 既可以适配按音频时长计费的模型，也可以适配按音频与文本 Token 计费的转写模型；相关用量、计费模式和最终费用都会一并进入请求日志。2.4.0 新增的重要部分是 TTS 字符计费：请求日志新增 `audio_characters` 字段，按照上游返回的有效字符数以及模型配置的字符单价单独核算费用。

这样，运维人员就可以在同一套请求日志中统一核对最终命中的供应商与模型、协议类型、操作、适配器、上游 Request ID，以及本次请求究竟是按秒、按 Token，还是按字符计费。

日志不会保存音频二进制内容；文本请求仍沿用现有的请求体日志策略。如果 TTS 未返回真实字符用量，网关不会使用输入文本长度去补算最终费用，也不会将预算预估伪装为正式账单。

## 05｜从单一 `MASTER_KEY` 到具名、分权的管理密钥

过去，外部系统、自动化任务与运维工具通常共享同一个 `MASTER_KEY` 来调用 Admin API。这种方式虽然简单，但很难回答三个关键问题：这次调用究竟来自谁、这个场景真正需要哪些权限，以及一旦凭证泄露该如何只轮换受影响的密钥。

2.4.0 将浏览器会话与 Bearer Key 身份彻底分离，并新增 **系统集成 → 集成密钥（Integration Keys）**：


*升级迁移会把旧 `MASTER_KEY` 复制为全权限的 `legacy-master`，以保证现有调用方继续可用；在系统稳定后，应根据调用身份与使用场景拆分密钥，并逐步完成替换。*

每一把集成密钥都可以：

- 使用独立名称标识具体系统、第三方集成、自动化任务或运维场景

- 按用户、用户 Key、Provider、模型、路由、配置、分析、日志或 Playground 分配权限

- 为同一系统拆分只读、写入或专项操作凭证，避免权限无序扩散

- 单独轮换或吊销，不影响其他无关调用方

- 记录最后使用时间，便于清理长期闲置的凭证

只有 Console Session 才能创建、修改和吊销集成密钥。任何 Bearer Key，即使拥有 `*` 权限，也无法管理 `/admin/access-keys/*`。这条权限边界可以有效避免某个调用方借助自身密钥继续生成新的管理凭证。

升级后，旧 `MASTER_KEY` 的值仍然可以通过 `legacy-master` 调用 Admin API，因此兼容性不会被立即中断。但更推荐尽快为门户系统、自动化脚本和运维工具分别创建最小权限 Key，更新它们的 `GATEWAY_MASTER_KEY` 或等价配置，验证无误后再轮换或吊销 `legacy-master`。

## 06｜预设、联调与路由运维同步增强

围绕新增的语音能力，Admin 侧也补齐了配置与联调入口：

- Qwen Token Plan 与 Provider 导入现已支持 DashScope 音频端点。

- ASR / TTS 模型目录和路由适配器支持直接选择。

- Playground 支持 DashScope Realtime 实时连接联调。

- 阿里云 TTS 定价已得到修正，并新增 CosyVoice 3.5 预设。

- Routes Flow 优化了粘滞绑定摘要、刷新、用户数和拓扑默认密度，复杂路由更易查看和维护。

这些能力让“配置 Provider → 建立音频模型 → 创建路由 → 在 Playground 联调 → 查看请求日志”形成完整、顺畅的管理闭环。

## 小结

如果你正在寻找一种方式，统一管理多个大模型供应商、语音能力调用以及不同业务场景下的管理权限，可以前往官网进一步了解 OctaFuse，或直接在 GitHub 查看源码与部署文档：

- [OctaFuse 官网](https://octafuse.dev/)

- [GitHub 仓库](https://github.com/OctaFuse/octafuse-gateway)

如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 **Star**。你的关注与反馈，将帮助我们持续完善模型路由、协议适配以及自托管部署体验。

","createTime":1786549626,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"fa vNum":0,"html":"","isOriginal":0,"likeNum":0,