批量处理中断 | UVR5 中文站

批量处理中断指：把一堆文件丢进队列后，跑到一半突然停止、界面卡死无响应，或结束后发现漏了某些文件没处理。批量比单文件更吃资源，问题多集中在内存或显存累积、单个坏文件、以及日志里被忽略的错误。

批量时 UVR5 会连续加载模型、读写磁盘，若某环节资源耗尽或遇到异常文件，队列就会断在未完成处。

原因一：内存或显存累积耗尽

现象：处理若干文件后越来越慢，然后崩溃或卡死。
检查：任务管理器看内存、GPU 显存是否随进度持续上涨不回落。
处理：减小 Segment Size、关闭 GPU 走 CPU（见「显存不足」），或每批数量减少，让资源有喘息。

原因二：单个异常文件卡住队列

现象：总是跑到某一首就停，跳过它后能继续。
检查：那首可能格式损坏、采样率异常或路径含特殊符号（见「文件格式不支持」「中文路径问题」）。
处理：先单独处理可疑文件，转成标准 WAV 并重命名到英文路径，再放回队列。

原因三：从日志找被忽略的报错

位置：软件目录下的日志文件（如有）或命令行启动时的输出。
做法：用命令行启动 UVR5，批量跑到中断时，终端里最后几行通常写明哪首、什么错。
用报错关键词去对应页排查（CUDA 看「GPU 加速报错」、OOM 看「显存不足」）。

分批策略

把大队列拆成每批 10 到 20 个，减少单次资源压力，也好定位坏文件。
每批处理完核对输出数量是否等于输入数量，及时发现漏文件。
长任务避免让电脑休眠，关闭休眠或睡眠防止中途打断。

兜底方案

若频繁中断，改用"小而多批"策略并走 CPU 模式保稳定；对确实处理不了的单文件，单独转码或舍弃，保证整体队列能跑完。

下一步建议

用命令行复现并抓取报错

关闭图形界面，在软件目录用命令行启动，再跑同一批队列，终端会留下中断瞬间的报错。
重点看报错里有没有 Out of memory（显存）、Unsupported format（格式）、File not found（路径）。
把最后十几行报错完整复制，去对应页面找修复办法，比盲猜高效得多。

批量中断最怕"看不到原因就重跑"，结果每次都在同一首卡住。命令行能把这个隐藏报错暴露出来，是定位问题的关键一步。抓到原因后，单文件问题就单独处理，资源问题就降参数或拆批。不要因为怕麻烦就跳过命令行，它往往是省下几小时重试的唯一捷径。

漏文件的预防与核对

每批处理完，用文件数量对比输入和输出是否一致，不一致就定位缺失的那几首单独补跑。给输出文件按批次建子目录，避免不同批次同名覆盖造成"以为漏了其实被覆盖"的误判。长期大批量任务，建议做成"跑一批、核对一批、再下一批"的节奏，稳定可控。发现漏文件先别急着重跑整批，先找出缺失项针对性补，效率更高。

先命令行启动抓中断时的真实报错，再针对性修（显存、格式、路径）。拆小批次能同时解决卡死和漏文件。若单机太慢，回看「处理速度太慢」在稳定前提下提速。