Venice 异步音乐生成

在 LLM 应用中直接集成音乐或长篇配音生成，最常见的痛点是 HTTP 请求超时。一段几十秒的音频推理通常需要数十秒甚至更长的时间，如果使用传统的同步接口调用，网关大概率会在任务完成前切断连接。这个技能的核心目标，就是将这种重耗时的音频任务改造成可轮询的异步流式工作流。

核心能力与执行流程

该技能严格封装了 Venice 音频 API 的异步生命周期，将复杂的流程拆分为四个明确的步骤：

• POST /audio/quote：在提交任务前预估成本。由于音频模型计费方式多样，通过该接口获取具体的美元报价，可有效避免因 duration_seconds 设置过大导致的预算透支。
• POST /audio/queue：入队提交任务。在此阶段需要注入生成参数（如 prompt、lyrics_prompt 等），并且技能会先行探测模型的 model_spec 元数据，确保所传参数严格匹配模型声明的 supports_* 能力边界。
• POST /audio/retrieve：轮询任务状态并下载。推荐以 2-5 秒的间隔轮询，依据返回的 average_execution_time 动态调整等待时间。任务完成后直接接收二进制音频流。
• POST /audio/complete：清理服务端临时文件。若未在 retrieve 步骤开启自动删除，必须显式调用该接口释放存储资源。

工程实践与避坑指南

在处理音乐生成时，有几个工程细节值得关注：

• 严格控制并发与计费：音乐模型多为按时长计费，建议在调用 queue 之前，务必结合 /billing/balance 余额与 quote 报价做一层拦截校验。
• 歌词参数强关联：调用 lyrics_optimizer 时，lyrics_prompt 必须为空字符串；而在纯乐器模型上强塞歌词会直接触发 400 错误。
• 媒体链接的脆弱性：获取到的音频 URL 具有时效性，必须在 retrieve 的响应窗口期将字节流持久化到本地或对象存储，因为 complete 执行后文件将从 Venice 的存储中彻底抹除。