> ## Documentation Index
> Fetch the complete documentation index at: https://api-docs.upmore.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Qwen ASR（阿里百炼）

> 通过 Upmore API 调用阿里百炼 Qwen ASR 语音转写，支持词级时间戳——包含模型选型、限制，以及为什么建议先抽音轨再上传。

阿里百炼的 Qwen ASR 模型通过 OpenAI 兼容的转写端点提供，音频和视频文件都支持，其中 `qwen-audio-3.0-asr-flash` 会返回词级时间戳。

## 模型

| 模型                         | 输出            | 输入上限         | 价格          |
| -------------------------- | ------------- | ------------ | ----------- |
| `qwen-audio-3.0-asr-flash` | 文本 + 句级/词级时间戳 | 5 分钟 / 2 GB  | 0.00022 元/秒 |
| `qwen3-asr-flash`          | 仅文本（无时间戳）     | 5 分钟 / 10 MB | 0.00022 元/秒 |

两个模型都支持音频（`wav`、`mp3`、`m4a`、`aac`、`flac`、`ogg`、`opus`、`amr`、`wma` 等）和视频（`mp4`、`mov`、`mkv`、`avi`、`webm`、`flv`、`wmv`）。传入视频时会自动转写其中的音轨——模型**不理解画面内容**。

> 时间戳是**词级而非字级**：中文按词切分（`今天`、`给大家介绍`），每个词带 `start`/`end`。响应只返回一条覆盖整个文件的 `segment`，字幕分行需要你自己按标点和停顿切。

## 快速开始

```bash cURL theme={null}
curl https://api.upmore.net/v1/audio/transcriptions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F model=qwen-audio-3.0-asr-flash \
  -F response_format=verbose_json \
  -F language=zh \
  -F file=@audio.mp3
```

`response_format` 支持 `json`、`text` 和 `verbose_json`，只有 `verbose_json` 带时间戳。

### 带词级时间戳的响应（`verbose_json`）

```json theme={null}
{
  "task": "transcribe",
  "duration": 46,
  "text": "大家好，今天给大家介绍一款全新的智能早餐机。…",
  "segments": [
    {
      "id": 1,
      "start": 0.12,
      "end": 46.142,
      "text": "大家好，…",
      "words": [
        { "word": "大家好，", "start": 0.12, "end": 0.8 },
        { "word": "今天", "start": 1.16, "end": 1.64 },
        { "word": "给大家介绍", "start": 1.64, "end": 2.8 }
      ]
    }
  ]
}
```

## 建议先抽音轨再上传（推荐做法）

Upmore 是通过公网把请求转发给阿里百炼的，上游模型接收的是**内联 Base64 data URI**。由此带来三个后果：

1. **体积上限**。内联 Base64 输入上限 10 MiB，约合**原始文件 7.5 MB**。1080p 视频通常远超这个体积。
2. **带宽与成本**。文件要先从你的客户端传到 Upmore，再由 Upmore 以 Base64（比原始大约 33%）发往阿里。网关的公网出流量是计费的，接近上限的上传，带宽成本可能和转写费本身相当。
3. **内存**。网关会把整个文件连同 Base64 副本（约 1.33 倍文件大小）缓冲在每个进行中的请求里。

改成传公网 URL 可以让字节不经过网关，但那样**上游要自己去下载**。实测同一条 538 KB 音频：URL 方式耗时 **21–45 秒**，而内联上传只要 **3.7 秒**——又慢又不稳定。

**所以最佳实践是先抽出音轨。** 46 秒的素材能从 1.4 MB（WAV）压到 **361 KB**（64 kbps 单声道 MP3）：

```bash theme={null}
ffmpeg -i input.mp4 -vn -c:a libmp3lame -b:a 64k -ac 1 audio.mp3
```

| 方式             | 传输体积                       | 网关出流量\*          | 延迟（46 秒素材）  |
| -------------- | -------------------------- | ---------------- | ----------- |
| WAV 上传         | 1.4 MB → 1.9 MB Base64     | ≈ 0.0015 元       | \~5 秒       |
| **抽出的 MP3 上传** | **361 KB → 481 KB Base64** | **≈ 0.0004 元**   | **\~5 秒**   |
| URL 传入         | \~0（上游自己下载）                | ≈ 0（改由对象存储出流量承担） | 21–45 秒，不稳定 |

\* 按约 0.8 元/GB 的标价估算。46 秒的转写费是 0.0101 元，所以抽成 MP3 后上传，带宽成本约占转写费的 4%；而接近上限的 WAV 或 MP4 上传，带宽成本可能逼近转写费本身。

## 计费

按模型返回的**音频时长**计费：`ceil(秒数) / 60 × 1000` 个 token，再乘以模型倍率。按 0.00022 元/秒的标价，46 秒约 0.0101 元。传入视频时只按音频时长计费。

## 限制与说明

* **单次 5 分钟**。更长的文件要切成 ≤5 分钟的片段，转写后把每段时间戳加上偏移量再拼接。（支持 12 小时长文件的异步 `filetrans` 接口目前尚未开放。）
* **仅支持文件上传**。把 URL 当作 `file` 的值传入，目前不支持。
* **只转语音**。视频画面不会被分析。需要画面时间轴，请用视频理解模型（如 `doubao-seed-2-1-pro`），再把两条时间轴按时间戳合并。