不少人手里有一批“中配AI集群”，跑完本地LLM之后利用率就开始往下掉，甚至有人觉得这套机器快要被淘汰了。实际上我最近拿一套闲置的中配集群做视频转码，效果比预想中好很多。所谓“AI集群的终结”根本不存在，它只是找到了新工作：从给本地LLM做推理和微调，转向承接视频转码这类持续吞吐型任务。这篇文章就围绕这个场景，聊聊什么样的机器适合复用、转码任务怎么落地、参数怎么调、批量任务怎么排，以及哪些情况最好别勉强。

我建议对这类方案感兴趣的人，尤其是已经部署过本地LLM、但GPU和CPU整体负载并不饱和的团队，先把文章里的思路当成一次“算力复用实验”来跑，而不是一上来就搭完整的生产系统。核心要看的不是单一命令，而是任务调度、资源隔离、输出验证和失败重试。

1. 先搞清楚：这套集群到底在忙什么

要判断AI集群能不能顺手做视频转码，先别急着装组件，而是要把现有资源占用情况摸清楚。

1.1 本地LLM负载往往是“低占空比”的

我在实际部署本地LLM时发现一个规律：模型推理看起来占着显存，但很多时间GPU计算单元是空闲的。比如你起了一个对话服务，用户请求是间歇性的，真正连续打满算力的时候并不多。显存一直占着，但算力峰值和平均值差距很大。

这种情况下，如果单独给LLM配一台服务器，资源浪费非常明显。视频转码恰好相反，它更看重持续吞吐，CPU可以长时间满载，GPU硬件编码器也能稳定输出。把视频转码任务放到这套集群上，本质上是把一段时间的空闲算力利用起来。

关键不是“让LLM和转码同时抢资源”，而是按时间段、按资源类型错峰复用。比如白天LLM服务负载高，转码任务就压低并发；夜里LLM请求少，转码队列就可以放开跑。

1.2 中配集群的典型构成

这里说的中配集群，不是那种动辄几十张卡的大型计算中心，更接近一个小团队或实验室自己攒的机器。

常见构成大致是这样：

• CPU：20核到40核左右，消费级或入门级服务器CPU都可以。
• 内存：64GB到256GB之间。
• GPU：一张或几张消费级显卡，显存从8GB到24GB不等。
• 存储：机械硬盘或普通SSD，读写速度一般。
• 系统：Ubuntu、Debian这类Linux发行版占多数，也有少量Windows环境。

如果你的机器配置接近这个水平，可以重点关注显存、内存和转码耗时。原始材料没有给出明确版本，建议落地时先确认系统、驱动和组件版本。

1.3 先做一次资源画像

我的建议是，先跑一轮真实的LLM负载，同时记录CPU、内存、显存、磁盘IO的变化。连续观测一整天或者至少一个业务周期，你会得到三个关键数据：

• 平均CPU使用率。
• 平均GPU使用率和显存占用。
• 哪些时间段基本没有任务。

这三个数据直接决定转码任务能不能插进去。如果LLM服务本身已经把CPU打满，GPU也在持续推理，那这台机器就不太适合再接视频转码。如果只是显存占用高、算力空闲，那就可以优先考虑用GPU硬件编码器来转码，尽量少抢CPU。

2. 视频转码为什么适合AI集群这类机器

很多人觉得转码是视频网站和后期团队的事，跟AI服务器没关系。其实从任务特点看，这两类工作有很强的互补性。

2.1 转码是典型的“可排队、可中断、可恢复”任务

视频转码不像实时推理那样要求毫秒级响应。用户提交一批视频文件，系统把任务放进队列，逐条处理，失败了可以重试，中断了可以从进度点继续。这种任务非常适合放在资源波动的集群上。

本地LLM服务则是另一个极端：请求来了就要尽快响应，服务不能随便中断。所以两者如果混跑，必须给LLM服务设置更高优先级，或者直接限定转码任务使用的资源范围。

我在实测时一般会把转码进程的CPU亲和性和内存限制写进部署脚本。这样即使转码队列排得很长，LLM服务的响应也不会被拖垮。

2.2 硬件编码器是关键变量

消费级显卡通常都带硬件编码器，也就是常说的NVENC或AMD、Intel对应的硬件编码单元。这些硬件编码器跟CUDA核心是独立的。也就是说，即使显卡算力在跑LLM推理，编码器可能还在空闲。

视频转码里最重的一步是把原始视频重新编码。如果源视频的封装格式、编码格式能被硬件解码器直接处理，就可以大幅降低CPU占用。如果源视频是特殊编码或高分辨率高码率素材，硬件解码不一定支持，又得绕回CPU软解。

所以不能只看GPU型号，要确认编码器支持列表，尤其是源视频的编码格式是否在硬解范围内。

注意：硬编和硬解不是一个概念。硬编负责把视频编码成目标格式，硬解负责把源视频解出来。两者都可能在同一种GPU上存在，但支持范围不完全一致。

2.3 转码性能的衡量指标

很多人只关心“转得快不快”，这个说法太模糊。我在验证转码效果时会拆成几个指标：

• 转码耗时：单个视频从开始到输出完整文件的时间。
• 实时倍率：对比视频时长，比如一个10分钟的视频，2分钟转完，实时倍率就是5x。
• 资源占用：CPU、内存、显存、编码器利用率。
• 输出质量：用码率、分辨率、关键帧间隔和目测观感判断。
• 稳定性：连续处理100个文件，有多少个成功、多少个失败、失败原因是什么。

这些指标比单看一个速度参数有用得多。批量任务尤其要看“成功率”和“失败重试是否生效”。

3. 从本地LLM到视频转码：实际落地的调度思路

真正动手时，不建议把LLM服务和转码任务一股脑塞进同一份命令。先做资源隔离，再做队列调度，最后才上批量。

3.1 先静态隔离，再动态复用

最简单的方式是给转码任务划定固定的CPU核数和内存上限。比如这台机器有32个CPU线程、128GB内存，其中16个线程和48GB内存用于LLM服务，其余部分允许转码任务使用。用Linux的cgroup、容器资源限制或者systemd的CPUQuota都能实现。

GPU方面更复杂一些。消费级显卡没有专业卡那样的MIG切分能力，显存容易被单个进程占满。稳妥做法是：转码任务优先使用CPU软编，GPU编码器只在显存和算力双空闲时开启。或者用环境变量和参数限制特定进程的显存占用。

我在测试中比较喜欢用一个简单的“窗口期”调度：每天凌晨到早上6点，转码队列可以放开跑；白天只保留中低并发。这样LLM服务的日常体验不会受影响，视频转码任务也能在几小时内消化掉。

3.2 容器化让资源边界更清楚

如果原来已经用Docker或K8s部署本地LLM，那转码任务也建议容器化。两个主要好处：

• 资源限制明确：CPU、内存、进程数都可以在容器启动参数里限定。
• 依赖隔离：LLM环境里的CUDNN、PyTorch版本不会污染转码环境里的FFmpeg和驱动库。

容器化之后，转码镜像里只需要包含FFmpeg、输入输出目录挂载和环境变量。启动命令可以维护成一个脚本文件，新任务进来时调用脚本即可。

3.3 任务队列比“手动跑命令”可靠

至少我在实际项目中的感受是：手动跑一条FFmpeg命令很容易，但一旦要处理几十个、上百个文件，就必须有任务队列。

队列至少要记录四个状态：等待中、转码中、已完成、失败。失败任务还要记录错误日志和重试次数。不需要为了这个场景专门搭一套分布式任务平台，一个支持并发控制的队列脚本或轻量任务调度工具完全够用。

下面这个流程是通用的，不是某个固定产品的命令：

1. 扫描输入目录，把符合条件的文件加入任务列表。
2. 按并发限制启动多个转码进程。
3. 每个任务独立写日志，输出文件先写到临时目录。
4. 转码成功后将临时文件移动到输出目录，并更新任务状态。
5. 超过重试次数仍失败的任务单独标记，不让它阻塞后面的任务。

这套逻辑最大的价值是“失败不牵连”。单个视频文件损坏，最多就是那条任务报错，不会把整个批次都卡住。

4. 单条转码命令怎么跑通

在并发和批量之前，先把单条视频转码跑通。这是整个方案里最基础、也是最容易暴露问题的一步。

4.1 环境准备清单

转码本身依赖FFmpeg，但完整流程还涉及输入文件检查、输出目录权限、磁盘空间和日志目录。

我一般会先确认这几项：

• FFmpeg是否安装并能正常调用硬件编码器。
• 输入视频文件是否完整，能不能被FFprobe读取基本信息。
• 输出目录是否存在、是否有写入权限。
• 磁盘剩余空间是否大于源文件预估体积，最好留出两倍余量。

如果FFmpeg是系统自带的旧版本，可能会缺少某些编码器或滤镜。建议自己确认版本后再决定是否升级。

4.2 一个比较稳妥的通用命令示例

下面这个命令是常见用法，可以直接作为第一个测试样例：

ffmpeg -i input.mp4 \
  -c:v libx264 \
  -preset medium \
  -crf 23 \
  -c:a aac \
  -b:a 128k \
  -movflags +faststart \
  output.mp4

参数解释：

• -c:v libx264 ：使用软件编码器，兼容性最好。
• -preset medium ：编码速度和文件大小的平衡档位，可以换成 fast、slow 等。
• -crf 23 ：质量系数，数字越小质量越高，文件越大。常用范围是18到28。
• -c:a aac ：音频转成AAC格式。
• -b:a 128k ：音频码率，按需求调整。
• -movflags +faststart ：把MP4的元数据移到文件头部，方便在线播放。

这条命令不代表最优参数，但能验证基本链路是否通畅。跑完之后，先看输出文件能否播放、时长是否正确、码率是否符合预期。

4.3 如何确认单条命令真正成功

不能只看命令有没有报错。有些情况下FFmpeg会把错误信息吞掉或者只输出警告，最后生成一个损坏的文件。

验证顺序建议这样：

1. 检查退出码是否为0。
2. 用FFprobe读取输出文件信息，确认时长接近源文件。
3. 检查输出文件的音视频流是否都存在。
4. 用播放器或者抽帧方式目测关键画面。
5. 对比源文件和目标文件的文件大小，差距异常时再看日志。

其中最容易忽略的是时长差异。如果源文件10分钟，输出文件只有5分钟，多数情况下是源文件本身有问题，或者转码过程中跳过了某些帧。这时候先去调查输入文件，不要直接改编码参数。

5. 转码参数怎么调：并发、码率、分辨率、显存分配

单条任务跑通之后，才会进入更重要的环节：批量环境下的参数调优。

5.1 并发数：不要一上来就拉满

并发数的选择跟“能承载多少任务”是两回事。真正要回答的是：在保证LLM服务稳定的前提下，还能开多少转码进程。

我建议先按资源比例估算：

• 纯CPU软编：每个线程一般负责一段编码，具体效率取决于CPU单核能力。可以先从“CPU空闲线程数的一半”试起。
• 使用GPU硬件编码：并发更多受编码器会话数和显存限制，不一定需要太多进程。
• 内存方面，每个FFmpeg进程根据视频分辨率会占用一定内存，不要让总内存使用超过物理内存的80%。

更稳妥的做法是逐个增加并发数。先开2个进程，观察CPU、内存和任务失败率；稳定后再加到4个、6个。

注意：如果这时候LLM服务还在持续推理，就要把转码并发往下调。不要只看FFmpeg单条命令消耗的资源，还要看整体系统是否还有余量。

5.2 码率和CRF如何选择

码率分固定码率CBR和可变码率VBR。固定码率适合推流或平台对接，文件大小可控；可变码率能根据画面复杂度分配码率，压缩效率更高。

CRF属于可变码率的一种控制方式。常见取值范围是18到28，18画质最好，28已经能看出压缩痕迹。如果是存档用，我会选18到20；如果是平台分发或内部预览，23到26足够。

音频码率也要根据来源调整。普通对白内容128k够用，音乐或高质量素材可以提到192k或256k。不要一味追求高码率，很多视频内容在128k和192k之间差别很小，但体积增加明显。

5.3 硬件编码器和软件编码器怎么选

这是一个很容易纠结的点。

软件编码器，比如libx264、libx265，压缩率更高，参数灵活，但速度慢、CPU占用高。硬件编码器，比如NVENC、QSV、AMF，速度快、CPU占用低，但同码率下画质通常不如软件编码器。

判断标准很简单：如果CPU空闲、转码量不大、追求画质，优先软件编码。如果任务量大、CPU要留给LLM服务、对画质要求不极端，优先硬件编码。

也可以做混合策略：源视频分辨率较高的任务，先用硬件解码降低CPU负载；编码阶段按需选择软编或硬编。这样能兼顾速度和画质，但FFmpeg参数会复杂一些，需要根据硬件支持情况调整。

5.4 参数测试的记录方式

我建议每次调整参数后都记录一组固定信息：

• 输入文件时长和分辨率。
• 编码器名称和preset。
• CRF或码率。
• 并发数。
• 转码耗时。
• 输出文件大小。
• CPU峰值占用和内存占用。
• 是否有失败任务。

把这些信息写在一个表格里，比凭感觉调参靠谱得多。尤其多人共用集群时，不同任务负责人很容易重复踩同样的参数坑。

6. 批量任务怎么设计：命名、重试和进度恢复

单条任务跑通只是起点。真正体现AI集群复用价值的是批量处理，因为批量任务会把资源利用率拉起来。但批量任务如果不做状态管理，很容易出现“转了一半，不知道哪些成功、哪些失败、哪些重复转”的混乱局面。

6.1 输入目录和输出目录要分离

我见过不少人直接在源视频文件旁边生成输出文件，结果批量任务一旦反复执行，就会覆盖或混淆。更稳妥的方式是建立两个独立目录：

/workspace/videos/input/
/workspace/videos/output/

输入目录只放原始视频，输出目录只放转码结果。这样任务脚本扫描输入目录时，不会把已经生成的输出文件再次当作输入。

6.2 输出命名要保持可预测

命名规则决定了失败重试时能不能快速定位。我一般会用“原文件名加后缀”的方式：

source_video_01.mp4 -> source_video_01_1080p.mp4

如果目标是生成多种分辨率，可以再加分辨率标识。命名越可预测，脚本就越容易判断“这个输出文件是否已存在”。

6.3 失败重试要设置上限

批量任务失败的原因千奇百怪，有些是源文件损坏，有些是磁盘空间不足，有些是编码器临时不可用。

我建议：

• 每一条任务允许重试2到3次。
• 每次重试之间等待几秒，避免瞬时资源波动造成连环失败。
• 超过重试次数后，把任务标记为失败，并记录完整错误日志。
• 不要因为一个文件失败就终止整个批次。

还需要考虑“断点续跑”。如果因为机器重启或磁盘满导致任务中断，重新启动脚本后，应该能跳过已成功的任务，只处理未完成的。这个能力在长时间批量任务里非常重要。

7. 典型问题和排查链路

转码场景的错误和LLM推理错误不太一样。LLM报错往往集中在依赖、显存、模型路径；转码报错则更可能出现在输入格式、编码器支持、磁盘空间和参数冲突上。

下面按我自己的排查顺序列一个通用链路。

7.1 先看现象是“报错”还是“异常结果”

有些问题根本不是命令层面的报错，而是结果不对。比如：

• 输出文件损坏，播放器打不开。
• 输出文件时长不对。
• 输出文件音画不同步。
• 任务没有报错，但输出目录里什么都没有。

如果命令直接报错，错误信息已经能指出大部分方向。如果命令没报错但结果异常，就要更细地检查输入文件和编码过程。

7.2 从输入文件和日志开始排查

我会按这个顺序排查：

1. 先检查输入视频是否存在、路径是否正确。很多“转码失败”其实是路径写错了。
2. 用FFprobe查看输入视频的编码格式、分辨率、帧率、声道数和码率，确认源视频是不是特殊格式。
3. 查看FFmpeg的完整日志。不要只看最后几行，把带“Error”“Invalid”“Unsupported”的行找出来。
4. 确认输出目录是否有写入权限和足够空间。
5. 检查CPU、内存、显存占用。如果资源被占满，先停掉部分任务再测试。

很多问题看起来是编码器参数不对，实际是输入文件的编码格式太冷门，导致硬件解码或某些滤镜不支持。这种情况下，要么换软件解码，要么先对源视频做一次格式预处理。

7.3 GPU显存或编码器会话耗尽

当开了很多个使用硬件编码的任务时，可能遇到“编码器会话已满”或显存不足。消费级显卡的编码器并发会话数有限，不是开多少进程就能跑多少路。

这时候的调整方向：

• 减少同时使用GPU编码的进程数。
• 把一部分任务切到CPU软编。
• 限制FFmpeg进程的显存占用，比如不做额外的GPU滤镜处理。
• 确认是否真的需要GPU编码，短时间转少量视频时，CPU软编的稳定性往往更好。

7.4 批量任务卡住或速度越来越慢

批量任务越跑越慢，很少是单条命令变慢了，更多是资源竞争和磁盘写入下降。

如果输出目录和输入目录在同一块机械硬盘上，大量文件同时读写时，磁盘IO会拖垮整体吞吐。建议：

• 输入目录和输出目录放在不同物理磁盘上。
• 输出先写到SSD临时目录，任务完成后批量移动到最终目录。
• 监控磁盘IO，而不是只看CPU。

任务卡住时，先确认是FFmpeg没有进度，还是队列系统把任务挂起了。查看当前运行进程、输出日志和输出文件大小，比重启整个队列更有用。

8. 什么场景适合复用集群转码，什么场景还是别勉强

最后聊边界。这套方案不是万能的，也不是所有AI集群都适合接视频转码。

8.1 适合的场景

如果满足以下条件，可以放心尝试：

• 本地LLM服务的资源占用有明显的低峰期。
• 视频转码任务是可以等待的离线任务，不需要实时反馈。
• 输入视频格式相对统一，比如都是MP4或MOV，编码以H.264、H.265为主。
• 团队需要处理几十到几千个视频文件，量级不算特别大。
• 已经有现成的任务队列和日志系统，或者愿意花半天搭建一个简单的批次流程。

这种场景下，AI集群的闲置算力是真的能被盘活的。尤其是那些已经配备消费级显卡和较多CPU核数的小团队，转码需求又时不时出现，专门买一台转码服务器反而不划算。

8.2 不适合的场景

如果遇到以下情况，建议谨慎评估：

• LLM服务本身已经让CPU和GPU长期接近满载，没有真正的空闲资源。
• 视频转码要求极低延迟，比如直播转码、实时推流。这类任务需要专门的流媒体服务和超低延迟网络，不是用FFmpeg批量跑就能解决的。
• 分辨率极高，比如8K、多轨ProRes RAW等专业影视素材。这类任务对存储带宽、CPU单核能力和编码器参数要求非常高，普通中配集群容易成为瓶颈。
• 需要精细的调色、特效、字幕、语音转写等后期处理。普通转码只做编码格式转换，做不了复杂的非线性编辑流程。
• 任务量极大，且每天都有固定交付期限。这时需要认真计算算力、电费、运维成本和购买专业转码设备之间的差异。

8.3 先算一笔账，再决定是否投入

我建议在改造方案之前先做一个粗略计算：

• 这台AI集群如果不开转码，每天有多少小时在闲置。
• 转码这批视频，如果交给云端转码服务，费用是多少。
• 本地跑转码，机器电费、磁盘损耗、维护成本是多少。
• 转码任务占用的资源，会不会影响LLM服务的正常使用。

如果云端费用很低，或者本地资源根本没有富余，就不必为了“复用”而硬接新任务。相反，如果机器大量时间闲置，视频转码又能容忍排队等待，那这套思路就能把固定成本的机器变成多用途工具。

踩过几次之后我发现，很多问题不是工具能力不够，而是前置环境和输入材料没有处理干净。AI集群做本地LLM和视频转码之间并没有天然冲突，真正需要处理的，是任务调度、资源隔离和失败重试。把这些基础整理清楚，中配机器也能在多个任务角色之间来回切换。