先说一个这两年很常见的尴尬场景。
某团队前几年买了一批中配GPU服务器，初衷很明确：跑大模型训练。等到真正上手才发现，从数据清洗、分布式训练到参数调优，每一步都比预想中复杂。更现实的问题是，这批“不上不下”的卡在几百亿参数的模型面前，几乎插不上手。于是团队里开始流传一个说法：AI集群的算力终结了，买的这些机器成了“电子垃圾”。
我的判断截然相反。
中配GPU集群不但没有终结，反而在另外两条更务实的赛道上找到了稳定工作：一条是本地LLM推理，另一条是GPU视频转码。这两个方向的算力需求特征是“持续吞吐”，而不是“峰值训练”。你不需要重新训练任何模型，只需要把已经训练好的开源模型跑起来；也不需要做复杂算法创新，只需要把大量视频从一种编码格式转换成另一种。这两类任务天然适合那种规模不大、单卡性能尚可、机器数量还行的中配集群。
这篇文章会先讲清楚中配AI集群的真实处境，再说清楚为什么推理和转码是它的正确赛道。然后分别给出两套可落地方案：本地LLM部署（含环境准备、模型选择、推理框架、文档知识库场景）和GPU视频转码（FFmpeg加速、批量任务调度）。最后是一份常见问题排查清单和工程建议。无论你手上正好有一批机器不知怎么用，还是正在盘算下一步应该买什么硬件，这篇文章都值得读完再做决定。
1. 这篇文章真正要解决的问题
先明确一点：我所说的“中配AI集群”，不是一个严格的硬件分类，而是一类尴尬的存量资产。
它可能是几台RTX 3090/4090服务器，可能是少量数据中心级GPU卡组出来的小集群，也可能是云上租来的GPU实例组。共同点是：单卡性能不错，但机器总量不够大，显存和算力不足以支撑百亿甚至千亿参数大模型的完整训练。
这类资产的典型困境有三个。
第一，训练大模型时发现算力不够。哪怕用DeepSpeed、ZeRO这些分布式优化手段，参数量一旦上去，中配集群也会在多机通信、显存交换、训练稳定性上消耗大量时间。很多时候时间花在集群调优上，而不是模型收敛上。
第二，只跑推理任务又觉得“浪费”。不少团队认为推理用单卡就能做，为什么要维护一个集群？这个认知其实不准确。推理如果只是脚本里调用几下，单卡确实够；但一旦涉及多路并发、知识库问答、大批量文档处理，单卡很快会成为瓶颈，集群的价值就体现出来了。
第三，闲置意味着持续赔钱。服务器即使在空闲，也在消耗机柜、电力、运维精力和折旧成本。与其让机器跑着空转的监控脚本，不如把它放入真正能产生收益的任务里。
所以要解决的问题很简单：如何让一批已经买回来、又暂时派不上“训练大模型”用场的GPU机器，重新跑出价值。
答案是两个方向：本地LLM推理服务和视频转码集群。
2. 中配AI集群的处境：训练跑不动，推理和转码却能吃得下
先说训练为什么难。
大模型训练不只是“把模型放到显卡里跑”。它需要模型并行、数据并行、张量并行、流水线并行等手段，把一个大模型的参数分布到多张卡上。卡与卡之间要高频交换梯度，通常依赖NVLink、InfiniBand这类高速互联。中配集群往往只具备普通万兆网络，交换带宽不足，训练效率会直线下降。
推理和训练完全不是一回事。
推理是已经训练好的模型，对输入进行一次前向计算，输出结果。它的核心要求是“延迟低、吞吐稳”。显存足够装下模型，计算卡能完成矩阵运算，网络带宽不要求那么极端。也就是说，中配集群做推理，短板没那么短。
视频转码就更是标准的“规模化并行任务”了。
一段视频转码可以切成多个片段，每个片段独立处理，几乎不需要卡与卡之间通信。NVIDIA的NVENC/NVDEC硬件编解码单元就集成在GPU里，用GPU转码比CPU转码在速度上有数量级差异。中配GPU集群完全可以作为一组“并行转码工人”，把大批量视频均匀分发到每张卡上执行。
所以从算力特征看，中配AI集群真正的天花板不在“能不能跑”，而在“愿不愿意放下训练执念，让机器去做更适合它的活”。
我给出一个明确判断：中配AI集群的正确出路，是用它跑“规模化确定计算”，而不是“探索式训练”。推理和转码正是这类计算。
3. 本地LLM部署：核心概念、硬件需求与环境准备
在动手部署之前，要先理解几个LLM推理的基础概念。掌握这些概念，你才知道自己的集群能跑多大的模型，也才知道该选什么推理框架。
3.1 模型大小与显存的关系
LLM的参数量决定了它需要的显存。一个直观的估算公式是：模型大小（GB）约等于参数量乘以精度字节数。
如果使用FP16精度，即每个参数占用2个字节，那么一个7B参数模型约占14GB显存。这只是模型权重的占用，推理过程中还需要KV Cache、计算中间状态，通常还要再留出一些余量。所以7B模型用FP16跑，单张16GB显存的卡比较稳妥；13B模型用FP16，基本需要24GB以上显存。
这就解释了为什么中配GPU集群非常适合7B到13B量级的开源模型。大多数中端卡配备16GB到24GB显存，正好覆盖这个范围。
3.2 量化：用精度换容量
如果显存不够，还有一种常见手段叫量化。量化是把模型的权重从FP16压缩到INT8、INT4等更低的精度。
量化等级可以用Q4、Q8、F16表示。Q4意味着每个参数只占约0.5字节，7B模型量化后只需要大约4GB多显存，普通消费级显卡也能跑。代价是生成质量会有轻微下降，但在大多数业务场景里几乎感知不到。
GGUF是社区里广泛使用的量化模型格式。Ollama、llama.cpp等工具都能直接加载这种格式。你不需要自己量化模型，直接从模型仓库下载别人量化好的GGUF文件即可。
3.3 推理框架选择
部署本地LLM，最常见的三个框架是：
| 框架 | 特点 | 适合场景 |
|---|---|---|
| Ollama | 安装简单，命令行友好 | 个人使用、小团队快速验证 |
| vLLM | 高吞吐、PagedAttention | 多路并发、正式API服务 |
| llama.cpp | CPU/GPU混合推理，轻量 | 资源有限或需要嵌入其他程序 |
Ollama适合第一轮验证，几分钟就能跑起一个模型。vLLM适合需要对外提供OpenAI兼容接口、并发请求较多的生产场景。本文会以这两个框架做示例。
3.4 环境准备
本地LLM推理对环境的要求并不苛刻。
操作系统建议使用Ubuntu 20.04或22.04 LTS。GPU驱动和CUDA版本必须匹配推理框架的要求。NVIDIA驱动安装完成后，用nvidia-smi确认GPU可见，并记录CUDA版本。
还需要安装Docker。vLLM官方提供了Docker镜像，用Docker部署可以省去很多Python依赖冲突问题。如果选择Ollama，官方脚本会自动安装好环境。
一套最简前置条件如下：
# 检查GPU驱动和CUDA版本 nvidia-smi # 检查系统架构 uname -m # 确认Docker已安装 docker --version如果系统里还没有Docker，可以按Docker官方文档安装。版本不必追求最新，稳定即可。
4. 在中配集群上部署本地LLM服务
这一章是操作核心。我会先用Ollama跑通一个最小可用的LLM问答服务，再用vLLM把它升级成支持高并发的OpenAI兼容API，最后补充文档知识库场景的实际接入方式。
4.1 用Ollama一分钟跑起本地模型
第一步，安装Ollama。
curl -fsSL https://ollama.com/install.sh | sh安装完成后，拉取一个开源模型。以Qwen2.5 7B为例：
ollama pull qwen2.5:7b第一次拉取会下载模型文件，大小约4GB到7GB，取决于是否使用量化版本。拉取完成后，直接运行：
ollama run qwen2.5:7b进入交互式命令行后，输入任意问题，模型就会在本机生成回答。这是最简单的验证方式。
如果要作为服务对外提供，需要让Ollama监听外部IP。默认情况下Ollama只监听127.0.0.1。可以通过环境变量修改监听地址：
OLLAMA_HOST=0.0.0.0 ollama serve如果希望永久生效，以systemd方式运行Ollama时，可以编辑服务文件：
# /etc/systemd/system/ollama.service.d/override.conf [Service] Environment="OLLAMA_HOST=0.0.0.0" Environment="OLLAMA_MODELS=/data/ollama/models"OLLAMA_MODELS用于指定模型文件存储位置，建议放到容量足够的磁盘目录。
修改后执行：
sudo systemctl daemon-reload sudo systemctl restart ollama此时其他机器就可以访问该节点：
curl http://<服务器IP>:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释为什么GPU适合推理", "stream": false }'返回结果中会包含response字段，就是模型生成的文本。注意自己在文中替换服务器IP。
这里真正容易踩坑的地方是stream参数。默认值为true，会让HTTP连接以流式方式返回文本，curl直接请求时会看到一段一段数据而不是完整JSON。调试时建议显式设置为false。
Ollama的优势是安装简单、架构清晰，适合小团队快速验证。但它对多路并发请求的支撑能力不如vLLM。如果需要面向整个部门甚至公司提供服务，建议换用vLLM。
4.2 用vLLM搭建高吞吐推理服务
vLLM是当前开源社区比较流行的LLM推理框架。它的核心优化是PagedAttention，可以让显存利用率显著提升，支持更高的并发吞吐，并提供兼容OpenAI的API格式，接入现有应用的成本很低。
用Docker启动vLLM服务，命令如下：
docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --ipc=host \ vllm/vllm-openai:latest \ --model /models/qwen2.5-7b-instruct \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9逐项解释一下关键参数：
--model：指定模型路径或模型名。如果模型在Hugging Face上，vLLM会自动下载；如果已经下载到本地目录，则直接指向该目录。--served-model-name：对外暴露的模型名称，客户端调用时使用这个名字。--tensor-parallel-size：张量并行卡数。如果一张卡放不下模型，可以设为2或更大，模型会被切分到多张GPU上。--gpu-memory-utilization：允许使用显存的比例。不要设为1.0，留出一点余量给CUDA上下文和其他进程。
启动后，vLLM会提供一个与OpenAI兼容的接口。用curl验证：
curl http://<服务器IP>:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-7b", "prompt": "什么是向量数据库？请给出通俗解释。", "max_tokens": 256, "temperature": 0.7 }'响应中choices[0].text就是生成的答案。
vLLM还支持/v1/chat/completions接口，适合以对话形式接入，格式与OpenAI官方接口一致。
4.3 多机上组建推理集群
如果单台服务器装不下模型或并发不够，vLLM支持跨多机的张量并行。假设有两台机器，每台4张卡，可以组合成8卡并行。
关键参数是--tensor-parallel-size 8，同时需要为集群配置分布式通信环境。vLLM基于Ray或NCCL处理多节点通信，需要保证各节点之间网络互通，并且使用相同的Docker镜像和模型路径。多机部署比单机复杂，建议先把单机跑通，再考虑扩展。
更稳妥的方式是以“实例池”思路使用集群：每台机器单独启动一个vLLM服务，上层用负载均衡或代理把请求分发到不同机器。这样横向扩展容易，一个实例挂掉也只会损失部分容量。
4.4 结合文档知识库：处理PDF、Markdown与私有文档
只部署一个裸模型，其实远不够解决真实业务问题。这也是很多团队误以为“LLM部署完就能用了”然后失望的原因。
真正高频的场景是：公司内部有大量PDF、Word、Markdown文档，希望员工能用自然语言提问，快速定位并总结出答案。要解决这个问题，单纯靠模型Prompt是做不到的，因为模型没有见过这些私有文档。正确路线是“文档向量化 + 检索 + LLM生成”，也就是RAG流程。
一条最基本的RAG链路是：
- 解析文档：把PDF、Markdown、Word提取为纯文本。
- 切片：把长文本按固定长度切为多个chunk。
- 向量化：用Embedding模型把每个chunk变成向量。
- 检索：用户提问时，用Embedding模型把问题向量化，在向量数据库中做相似度检索。
- 生成：把检索到的chunk拼进Prompt，交给LLM生成回答。
在集群上实现这条链路，最直接的方式是使用现成的开源平台，比如AnythingLLM或Dify。这些平台自带文档上传、知识库管理、向量存储和模型接入配置，可以把刚才部署的Ollama或vLLM配置为底层模型。
以vLLM为例，在Dify中添加模型时，填写vLLM的OpenAI兼容API地址即可：
https://<服务器IP>:8000/v1然后选择对应的served-model-name。这样知识库问答不再是一个demo，而是真正能被业务方使用的服务。
社区里还有一种个人知识库玩法，比如把Obsidian笔记通过LLM Wiki的方式维护起来，把md文档批量导入向量库，再让本地LLM回答问题。它和公司知识库在技术链路上是同构的，只是规模更小。如果你的中配集群暂时没有业务负载，可以先从这类轻量场景开始验证机器和框架的稳定性。
5. 用GPU集群做视频转码：FFmpeg与并行任务
本地LLM是中配集群的“智能工作”，视频转码则是它的“体力工作”。很多团队忽略了这个场景，但实际上视频转码对吞吐的要求极高，GPU集群在这里的价值非常直接：快、稳、省CPU。
5.1 为什么视频转码适合GPU
视频编码是高度并行的计算任务。NVIDIA GPU内置了NVENC/NVDEC硬件单元，专门负责H.264、HEVC等编码格式的硬件级处理。
用GPU转码，CPU的压力大幅降低，编码速度通常比纯CPU转码快几倍到几十倍。对于日产出几十上百小时的视频素材、录播课、直播回放、监控视频等场景，中配GPU集群可以并行处理大量文件。这也解释了为什么很多公司的“剪辑机”和“训练服务器”最终会在转码任务上相遇——因为GPU硬件成本已经被摊销过，转码边际成本非常低。
5.2 FFmpeg基础转码命令
FFmpeg是最常用的视频处理工具。要启用NVENC，需要在编译时带上了对应组件，大多数主流发行版或社区构建版都支持。
单文件转码命令示例：
ffmpeg -hwaccel cuda -i input.mp4 \ -c:v h264_nvenc -preset p4 -b:v 4M \ -c:a copy output.mp4参数含义说明：
-hwaccel cuda：启用CUDA硬件加速解码。-c:v h264_nvenc：使用NVIDIA硬件编码器输出H.264。-preset p4：NVENC的预设档，平衡质量和速度，p4是较常用的档位。-b:v 4M：视频码率设为4Mbps。-c:a copy：音频流直接复制，不重新编码，节省时间。
如果要转成HEVC/H.265格式，把编码器换成hevc_nvenc即可：
ffmpeg -hwaccel cuda -i input.mp4 \ -c:v hevc_nvenc -preset p5 -b:v 3M \ -c:a copy output_hevc.mp4HEVC在同等画质下码率更低，适合存储空间有限的场景。
这里真正容易踩坑的地方是-preset参数。NVENC的preset档位与x264不同，不是fast、medium这种名称，而是p1到p7。老版本FFmpeg可能用-preset fast、-preset medium这类写法，新版本推荐使用p1到p7，具体以你的FFmpeg版本帮助输出为准。
5.3 批量并行转码
单文件转码只是热身。集群的价值在于批量并行处理。
一个简单的多文件转码脚本：
#!/bin/bash # 批量将目录下所有MKV文件转成H.264 MP4 for f in /data/videos/input/*.mkv; do ffmpeg -hwaccel cuda -i "$f" \ -c:v h264_nvenc -preset p4 -b:v 4M \ -c:a copy "${f%.mkv}.mp4" & done wait这个脚本用&把多个转码任务放在后台并行，wait等待全部完成。但如果机器GPU数量少，任务过多会导致显存不足或编码器过载。
更稳妥的方式是按GPU数量控制并发度。例如8张GPU的集群，同时运行8个任务：
#!/bin/bash input_dir=/data/videos/input output_dir=/data/videos/output max_concurrency=8 for f in "$input_dir"/*.mkv; do while [ "$(jobs -r | wc -l)" -ge "$max_concurrency" ]; do sleep 2 done ffmpeg -hwaccel cuda -i "$f" \ -c:v h264_nvenc -preset p4 -b:v 4M \ -c:a copy "$output_dir/$(basename "${f%.mkv}").mp4" & done wait这个脚本每次最多启动8个转码进程，每当有进程结束就启动下一个，保证GPU数量与任务数匹配。
如果转码任务量很大，还可以引入消息队列或任务编排工具。常见做法是用Redis作为任务队列，消费端每取到一个任务就执行一个FFmpeg命令。这种做法比直接跑shell脚本更可控，能看到进度、支持失败重试，也方便后期扩展。
5.4 一个推理与转码共存的负载规划
实际运维中，中配GPU集群不太可能只跑一种任务。更常见的情况是白天推理服务有业务压力，夜里转码任务批量执行。
可以按时间段做简单的负载规划。比如用cron在凌晨启动转码任务，白天只跑LLM推理服务。这比把所有任务都堆在一起更稳妥，因为NVENC和NVDEC虽然独立于CUDA核心，但转码过程中也会占用部分GPU计算资源，与推理服务同时高负载时可能相互影响。
也可以更精细地把集群分区：一部分GPU固定跑LLM推理，一部分GPU固定跑视频转码。两种任务不会抢显存。如果你用的是支持MIG切分的GPU，还能在同一张卡上隔离出不同算力区域，但这要看具体GPU型号是否支持。
6. 运行结果与效果验证
部署完成后，要有一套明确的验证标准，不能只看“能跑能输出”。
6.1 LLM推理验证
推理服务的验证包括三方面。
第一，接口连通性。用curl请求Ollama或vLLM接口，确认返回200和预期文本。
第二，并发能力。用简单的并发测试工具同时发出10个、20个请求，观察接口是否正常，显存是否被打满。如果你的部署目标是支撑部门级使用，建议至少验证20路并发稳定不崩溃。
第三，显存余量监控。用nvidia-smi观察每张卡的显存使用情况。如果显存占用超过95%，说明模型或并发配置偏紧，需要降低批量或增加--gpu-memory-utilization的余量。如果显存占用很低，说明还可以适当增大并发。
一个简单的循环监控命令：
watch -n 1 nvidia-smi通过输出可以看到GPU利用率、显存占用和温度，这是判断部署是否健康的最直观依据。
6.2 视频转码验证
视频转码的验证重点不在“有没有输出文件”，而在三个指标：编码速度、画质可接受度、CPU释放程度。
编码速度可以用FFmpeg自带的日志查看。转码完成后，FFmpeg会输出运行时间。对比一下同一文件在CPU转码和GPU转码下的耗时，就能直观看出差距。
画质方面，建议抽查转码后的视频关键帧，检查是否出现明显的压缩噪声、花屏或音画不同步。NVENC在不同preset下的画质差异很大，p4和p5是稳妥起点，追求更高画质可以往p1、p2方向调。
CPU释放程度可以用top或htop观察。GPU转码时，CPU使用率应该明显低于纯CPU转码，这正是GPU硬件编解码的价值所在。
7. 常见问题与排查思路
以下是我认为在中配GPU集群跑LLM和转码任务时最高频的问题，整理成表格方便对照排查。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Ollama启动后其他机器访问不了 | 服务只监听了127.0.0.1 | 查看Ollama启动日志或ss -lntp | 设置OLLAMA_HOST=0.0.0.0并重启服务 |
| vLLM提示CUDA out of memory | 模型太大或并发过高 | 查看nvidia-smi显存占用，确认模型量化等级 | 换成量化模型、降低--gpu-memory-utilization、减少并发数 |
| 推理速度很慢，GPU利用率低 | 单卡模型装了多机并行，通信开销大 | 在单机上先跑通，观察多卡利用率 | 优先单机多卡，避免不必要的跨机张量并行 |
| 请求vLLM接口报超时 | 模型首次加载冷启动慢 | 查看容器日志 | 提前发送一个预热请求，让模型加载完成 |
FFmpeg报encoder h264_nvenc not found | FFmpeg版本没有编译NVENC支持 | 执行`ffmpeg -encoders | grep nvenc` |
| 转码速度没有明显提升 | 文件较小或CPU成为瓶颈 | 任务管理器查看CPU占用 | 使用更大的视频文件测试，检查-hwaccel cuda是否生效 |
| 转码时推理服务响应变慢 | 两种任务共享GPU资源 | 观察两个任务的GPU占用曲线 | 按时间段隔离任务，或将集群分区专用 |
| 模型回答质量差 | 使用了低量化等级或温度参数不合理 | 对比不同量化版本和temperature取值 | 在质量敏感场景优先使用Q8或FP16，降低temperature |
| 知识库检索结果不对 | 切片的chunk太小或Embedding模型选择不当 | 检查检索命中文本与问题是否存在语义相关 | 调整切片长度、换更强Embedding模型、补充重排序环节 |
排查时记住一个原则：先看监控数据，再动配置。不要凭感觉反复重启服务，而是用nvidia-smi、ss -lntp、FFmpeg日志和vLLM容器日志拿到事实依据，再决定调整方向。
8. 最佳实践与工程建议
8.1 模型与硬件的匹配原则
选择模型之前，先算一笔显存账。用FP16精度跑7B模型，普通16GB显卡可以；跑13B模型，建议24GB显存起步；如果要跑70B模型，单卡基本放不下，必须使用多卡并行。
如果显存不够，优先尝试量化模型，而不是强行扩集群。量化到Q4通常能把显存需求降到原来的四分之一左右，损失的质量在大多数业务场景可以接受。更稳妥的选择是先跑一个最小量化版本验证流程，再根据质量反馈决定是否升级到更高精度。
8.2 服务配置与命名规范化
LLM推理服务一旦面向团队开放，就不再是“自己跑一跑”的脚本了。
建议为每个模型建立独立目录，命名规则类似/data/models/qwen2.5-7b-instruct/。vLLM启动脚本要固化到仓库里，用配置文件管理--tensor-parallel-size、--gpu-memory-utilization等关键参数，避免每次启动都手动敲命令，更不要在启动参数上随手改数值。
Ollama服务建议用systemd托管，设置开机自启和自动重启。日志统一输出到固定目录，方便排查。
8.3 转码任务的工程化
批量转码不能只靠一个shell脚本跑到底。脚本适合几十个文件的临时需求，如果每天都有大量新增视频，建议上一套任务队列：一个生产者扫描新增文件，写入Redis队列；多个消费者拉取任务，执行FFmpeg命令并记录状态。
同时要做到三点：
第一，转码任务要支持断点重试，避免某个文件因为编码参数错误导致整个队列卡住。
第二，转码输出必须先写入临时目录，完成后再移动到正式目录，避免生成一半的文件被业务方读取。
第三，转码参数建议用配置文件管理，不同渠道的视频可能需要不同码率、不同编码格式，中心化配置能减少维护成本。
8.4 安全边界与权限控制
这类服务在安全方面的底线是：内网可访问不等于外网可访问。
LLM推理服务如果团队内部使用，建议只绑定内网IP，不要直接暴露到公网。如果必须跨网访问，用公司统一的反向代理和认证体系，而不是裸奔一个8000端口。vLLM和Ollama都不内置复杂的用户认证机制，生产环境接入时要在前面加一层API网关或认证代理。
视频转码涉及文件读写时，要注意目录权限最小化。转码任务通常需要访问原始视频和写入输出目录，不要让服务进程拥有整个文件系统的读写权限。临时文件目录要定期清理，避免转码中断后残留大量半成品占用磁盘。
8.5 监控与容量规划
中配集群虽然规模不大，但也要建立最基本的监控。
至少需要收集四类指标：GPU显存使用率、GPU利用率、温度、磁盘IO。这些指标可以用Prometheus + node_exporter + nvidia_gpu_exporter组合采集，再接入Grafana看板。没有条件搭完整监控时，至少写一个定期巡检脚本，将nvidia-smi输出持久化到日志文件。
容量规划方面，建议预留20%到30%的显存和算力余量，不要跑满。推理服务的请求量大概率会波动，转码任务也可能突然涌入一批大文件。把集群跑在80%负荷以内，遇到突发任务时才有缓冲空间。
9. 结语
把中配GPU集群从“训练不了大模型的电子垃圾”变成“本地LLM推理服务 + 视频转码任务池”，本质上是一次视角转换：不要问机器能不能做最前沿的事，而要看它能在哪些重复、量大、要求稳定的任务里产生真实价值。
本地LLM部署解决的是数据隐私和可控性问题，让私有文档知识库、内部代码助手、业务对话服务不再依赖外部API；视频转码解决的是成本和时间问题，让GPU硬件编解码单元在内容生产流程里持续工作。两个场景都不需要模型训练能力，却都实实在在消耗GPU的性能。
如果你手头正好有一批“吃灰”的机器，先从跑通一个小模型开始，再用FFmpeg转几段长视频，记录下GPU利用率和耗时。不出半天，这批机器的价值就会重新浮现。
下一步值得深入的方向有三个：RAG知识库的检索质量调优、vLLM的多节点水平扩展、以及用任务队列把转码和推理统一编排起来。工具链一直在变，但“让硬件做它最擅长的事”这个原则不变。
