长音频只回来前几句，通常是两类原因交叠：一类是音频根本没被完整送进模型，比如切分后只传了第一段、或用 URL/文件字段时被服务端按大小或时长截住；另一类是输入确实全送了，但输出长度相关参数偏保守，生成到几百字就正常收尾。两者在返回文本上的表现很像，靠肉眼分不出来，比较稳的做法是先做切分实验，用“单段基线 → 只改输出参数 → 按序拼接”的顺序把输入问题和输出问题分开。

目标是把“输入没送全”和“输出被参数截断”分开判断：先把长音频按固定时长切成带起止时间的片段并编号，单独送第一段记录返回长度作为基线；再固定输入、只调输出长度相关参数，对比两次返回长度；最后按序送片段并拼回时间轴，看丢失集中在开头、中段还是边界。适用于可自行切分音频、能改请求参数的场景；如果服务端对时长/体积有前置限制、或返回里没有可对照的时间信息，结论需要结合环境确认，不能直接当成参数问题处理。

把长音频按固定时长切成等长片段并编号

这一步的目的不是“优化音频”，而是让每一段输入都变成可定位的样本。只要片段命名里带起止时间，后续不管返回的是文本还是时间戳，都能反查它对应原始音频的哪一段。建议在临时输出目录里工作，切完先打印每段的时长和文件大小做自检，避免出现最后一段只有几毫秒、或者某段实际为空的假片段干扰判断。

下面是一个通用切分骨架，命令行参数按你本地的 ffmpeg 版本替换，输出目录先用占位路径：

# 占位路径：请替换为本地临时目录，例如 /tmp/audio_seg
SRC="input_long_audio.wav"
OUT="/path/to/seg_out"
SEG=30   # 每段时长（秒），按需调整

mkdir -p "$OUT"
ffmpeg -hide_banner -i "$SRC" -f segment -segment_time "$SEG" \
  -c copy "$OUT/seg_%03d_${SEG}s.wav"

# 自检：打印每段时长与文件大小
for f in "$OUT"/*.wav; do
  dur=$(ffprobe -v error -show_entries format=duration \
        -of default=noprint_wrappers=1:nokey=1 "$f")
  size=$(stat -c %s "$f")
  echo "$f  duration=${dur}s  bytes=${size}"
done

如果文件名里的序号不能满足“起止时间”要求，可以用脚本按顺序累加偏移量重命名，比如 seg_000_0-30s.wav、seg_001_30-60s.wav。这样在后面拼回时间轴时，顺序和边界都是明确的。

单独送第一段，确认返回长度是否正常

先只看第一段。这一段足够短，理论上最不容易触发输入侧的时长或体积限制。把它的返回文本长度记录下来，作为“单段基线”。关键是要先约定一个衡量口径：用返回的字符数，还是用返回文本所覆盖的音频时长。字符数和时长不是线性关系，语速、标点、是否包含时间戳都会影响，同一批样本里最好只用一个口径，否则后面两次对照会失去可比性。建议在代码里直接统计字符数，同时记录是否返回了时间信息。

import os, requests

API = "https://<your-endpoint>/v1/audio/transcriptions"  # 占位
KEY = os.environ.get("ASR_API_KEY", "")
seg = "/path/to/seg_out/seg_000_0-30s.wav"

with open(seg, "rb") as f:
    r = requests.post(API,
        headers={"Authorization": f"Bearer {KEY}"},
        files={"file": f},
        data={
            # 参数名以实际文档为准，这里只给占位
            "model": "<omni-model-name>",
            # "language": "zh",
            # "max_tokens": 4096,   # 若支持，先给一个明显偏大的值
        },
        timeout=120)
text = r.json().get("text", "")
print("status=", r.status_code, "chars=", len(text))
print(text[:200])

如果第一段单独送都明显偏短，问题多半不在长音频切分，而在输出参数或者请求本身；如果第一段正常、后面按序送才变短，才需要怀疑输入侧或边界处理。这一步不要急着下结论，只把长度记下来。

固定输入、只改输出长度相关参数，观察返回变化

这一步只动输出侧参数，输入片段、模型、语言都保持不变。不同接口里限制输出的参数名不一样，常见的有 max_tokens、max_new_tokens、max_output_tokens 这类，具体以实际文档为准；没确认过的参数不要凭猜测填，先写成占位注释，确认后再启用。做两次请求：一次用偏大的输出上限，一次用默认或偏小的值，对比返回文本长度。

• 如果两次返回长度差异明显、且偏大那次更接近第一段基线，说明输出被参数截断的可能性更大。
• 如果两次返回长度几乎一样、都偏短，说明瓶颈更可能在输入读取或服务端前置限制，而不是输出上限。

结论可以写成这种可核验的句式，而不是笼统判断：“同一片段在输出上限调大后返回字符数由 X 变为 Y，因此输出截断是主要因素之一；但这不等于长音频整体问题已解决，还需结合按序拼接结果确认。”X、Y 用你自己脚本打印出的真实数值，不要照抄。

把片段按序送入，拼回时间轴检查丢失位置

把所有片段按编号依次送入，把每段返回文本按顺序拼接，并保留片段编号作为分隔标记。记录方式建议是每段一行：片段名、返回字符数、是否为空、首句摘要。这样丢失位置会很明显：集中在开头，说明前面若干段没被处理或送错了；集中在中段，可能是某个尺寸较大的片段触发了限制；集中在片段边界，通常和切分方式以及上下文断裂有关。

片段边界处的典型表现是：一句话被切成两半，前半句落在上一段结尾的返回里，后半句落在下一段的返回开头，单独看都像“缺词”。验证方式是有意让相邻片段重叠一段，重叠长度从几百毫秒开始逐步加长，观察边界处返回是否更连贯。重叠多长才够，和语速、接口的上下文处理方式都有关，需要结合环境实测，不建议直接照搬一个固定值。

# 拼接记录骨架
for i, seg in enumerate(sorted(seg_files)):
    text = call_api(seg)          # 返回该片段文本
    with open("concat_log.txt", "a") as out:
        out.write(f"[{i}] {seg} chars={len(text)}\n{text}\n\n")

如果多段都返回空或极短，先回头看切分自检输出，确认这些片段本身不是空文件或格式异常，再谈参数问题。

确认不可复现或随机的部分，标注为待核实

同一输入、同一参数重复送三次，把每次返回长度列成表，比单次结果更有参考价值。每次都短且长度接近，可以当成稳定可复现的截断；三次里有一次正常、两次偏短，或长度浮动较大，就属于随机波动或不可复现部分，不要写成“稳定规律”。

表格里的“记录值”用你脚本实际打印的数字替换，判断列区分“可复现截断”和“偶发波动”。对三次结果不一致的情况，建议在结论里明确标注为待核实，并补记当时的网络返回状态、是否有超时重试，这些信息后续排查时比一个笼统结论更有用。