前端通过 Ajax 异步调用 GLM-TTS 语音合成服务
在内容创作和人机交互日益依赖语音技术的今天，如何让网页应用'开口说话'已成为开发者关注的重点。无论是为视障用户朗读文章，还是为短视频自动生成配音，高质量、低延迟的文本转语音（TTS）能力正逐渐成为现代 Web 产品的标配功能。
而真正棘手的问题在于：语音合成通常耗时较长，动辄几秒甚至十几秒，如果让用户干等页面卡住不动，体验几乎无法接受。传统的表单提交方式显然行不通——我们需要一种既能异步处理复杂计算，又能实时反馈结果的机制。
这正是 GLM-TTS 与 Ajax 结合的价值所在。前者是基于大模型的先进语音合成系统，支持零样本音色克隆与情感迁移；后者则是前端实现非阻塞通信的核心技术。两者协同，构建出一套流畅、可扩展的智能语音交互流程。
GLM-TTS 并非普通的 TTS 工具，它源自大规模预训练语言模型架构，由社区开发者进行 Web 化封装后，具备了图形界面与本地部署能力。其最大亮点在于无需训练即可复现目标音色——只需上传一段 3–10 秒的参考音频，系统就能提取声学特征，并用该声音朗读任意新文本。
整个推理过程分为三个阶段：
- 特征提取：从参考音频中捕捉音色、语调、节奏等个性化信息；
- 对齐优化（可选）：若同时提供参考文本，系统会进行语音 - 文本对齐，提升发音一致性；
- 波形生成：模型先输出梅尔频谱图，再经神经声码器转换为最终
.wav音频文件。
这些操作运行在 PyTorch 框架下，依赖 GPU 加速。为了提升效率，系统启用了 KV Cache 机制，缓存注意力键值对，显著减少长序列生成时的重复计算，使推理速度提高 30% 以上。
生成的音频默认保存至 @outputs/ 目录，命名规则包含时间戳（如 tts_20251212_113000.wav），避免多任务冲突覆盖。更重要的是，这个路径不会立即返回给前端——因为合成可能还在进行中。这时就需要一个'中间人'来持续追踪状态。
传统做法是让服务器等到音频完全生成后再响应请求，但这样会导致 HTTP 连接长时间挂起，浏览器超时或用户误操作关闭页面的风险极高。我们真正需要的是'提交即走，完成通知'的异步模式。
这就是 Ajax 的用武之地。尽管名字里还带着 XML，但如今它早已演变为泛指所有通过 JavaScript 发起的异步 HTTP 请求的技术统称。借助 fetch() 或 XMLHttpRequest，前端可以在不刷新页面的前提下，悄悄与后端交换数据。
具体到 GLM-TTS 的应用场景，完整交互流程如下：
- 用户填写文本并上传参考音频；
- 点击'开始合成'，前端将参数打包成 JSON，POST 到
/api/tts； - 后端接收到请求后，立即启动后台任务，生成唯一
task_id并返回； - 前端拿到
task_id后，启动定时轮询，每隔 2 秒向/api/status?task_id=xxx查询进度； - 当任务状态变为'completed'，接口返回音频 URL；
- 前端将其赋值给
<audio>标签的src属性，触发自动播放。
这一设计的关键在于解耦任务提交与结果获取。用户点击按钮后立刻获得反馈：'任务已提交'，而不是盯着转圈等待。与此同时，UI 仍可自由操作其他功能，毫无卡顿感。
下面是一段典型的前端实现代码：
async function startTTSTask(inputText, promptAudioPath) {
const response = await fetch('/api/tts', {
method: 'POST',
: { : },
: .({ : inputText, : promptAudioPath, : , : , : })
});
task = response.();
(task.) {
.(, task.);
(task.);
} {
( + task.);
}
}
() {
maxRetries = ;
attempts = ;
interval = ( () => {
attempts++;
res = ();
status = res.();
(status. === ) {
(interval);
.(). = status.;
.().();
} (status. === || attempts >= maxRetries) {
(interval);
();
}
}, );
}
