OctaFuse 2.4.0：让 DashScope 的 ASR、TTS 语音能力进入统一路由

当语音识别和语音合成进入真实业务，网关面对的不再只是一次普通的 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,