AI 集群这个说法，过去基本等于“烧卡训练大模型”。但这两年大家慢慢发现，真正能把手里几台机器用起来的场景，往往不是训练，而是两类：一类是本地 LLM 推理，一类是视频转码。

这次我们看的话题，不是某个具体开源项目，而是“中配 AI 集群”怎么从“终结”的讨论里走出来，找到新工作。所谓中配，指的是由几张消费级显卡或者入门级专业卡组成的机器，算不上顶级训练集群，但显存、算力、视频编解码能力都够用。这类机器跑大模型训练确实吃力，但跑本地 LLM 和视频转码，稳定性反而比云服务器更可控，批量任务的可调度性也更强。

这篇文章会围绕三件事展开：第一，为什么中配集群适合做本地 LLM 推理与视频转码；第二，怎么在这类硬件上把 Ollama、Dify、AnythingLLM、FFmpeg 这些工具串联起来；第三，怎么验证效果、观察显存占用、处理批量任务。硬件门槛我会按通用部署流程讲，不写死参数，因为不同机器、不同模型版本、不同转码规格，实际表现会有差异。适合的读者也很明确：手里有一台中配 GPU 机器、想跑通本地 LLM 服务，或者想用 GPU 硬件编码加速视频处理，同时希望整个链路可维护、可监控的开发者。

1. 核心能力速览

从整体定位看，中配 AI 集群的价值已经从“训练基础设施”变为“私有化推理和媒体处理节点”。下面这张表把这些能力整理出来，方便先判断自己的场景是否匹配。

能力项	说明
核心定位	本地 LLM 推理、知识库问答、Agent 服务、GPU 视频硬件转码
典型硬件	单卡或几张消费级显卡、入门级专业卡，具体以本机配置为准
显存需求	取决于模型体积与量化方式；7B 级别量化模型通常比全精度更节省显存
启动方式	命令行服务启动，或 Docker 启动；Ollama 提供原生 API 服务
主要功能	LLM 对话、文档知识库、Agent 工具调用、H.264/H.265/AV1 转码
批量任务	LLM 支持并发请求；转码可通过目录队列与脚本批量处理
接口能力	Ollama API、OpenAI 兼容接口；FFmpeg 命令行与脚本接口
适合场景	私有化知识库、企业文档问答、本地 Agent、视频素材转码
不适合场景	大规模模型训练、超长序列高并发推理、高强度 4K/8K 批量转码

从材料看，目前这套组合的吸引力在于“一套硬件同时服务两个任务”。LLM 推理和视频转码对 GPU 的利用方式不同，前者吃显存和计算，后者吃视频编码单元和显存带宽，因此两者可以共用一台机器，只要做好任务调度和资源配额。

2. 适用场景与使用边界

2.1 适用场景

中配 AI 集群的第一个典型场景，是私有化本地 LLM 服务。典型形态是 Ollama 或 vLLM 加载量化模型后，对内提供 OpenAI 兼容接口，上层接 Dify、AnythingLLM、Codex CLI 等应用。整个链路可以完全不依赖外部接口，模型权重也留在自己机器上，适合处理内部资料。

第二个典型场景是文档知识库。比如用 AnythingLLM 或 Dify 管理 Markdown、PDF、TXT 文档，先做向量化，再通过本地 LLM 做问答。这里需要注意，知识库的效果取决于文档切分策略、向量模型选择和 LLM 指令模板，硬件只是基础。

第三个典型场景是视频转码。GPU 的硬件编码器在短视频素材处理、课程视频压缩、监控录像归档等任务里，效率比 CPU 转码高很多，尤其是大批量转码场景，能明显节省时间。

2.2 使用边界与合规要求

这套组合不适合用来做大规模模型训练。中配集群的卡间互联、显存容量和训练稳定性，都撑不住千亿级模型训练。合理判断是：训练任务最多做一些微调实验，生产级训练还是交给专门的高性能集群。

使用合规方面需要注意三点：

1. 模型授权：下载和商用开源模型前，先确认模型仓库的 License，不同模型对商用、再分发的限制不同。
2. 数据合规：本地 LLM 知识库如果包含客户资料、个人隐私或内部文档，要保证服务只在可信网络内开放，并做好访问控制。
3. 视频版权与肖像权：转码只处理自己有权处理的素材。涉及人脸、声音、品牌素材时，必须确认授权链完整。

3. 环境准备与前置条件

在部署之前，先做一轮环境检查。中配集群未必是全新机器，可能是淘汰下来的算力节点，驱动和系统环境往往比较杂，先把基础环境理清楚，后面会省很多事。

3.1 检查清单

• 操作系统：Linux 发行版或 Windows Server 均可，建议选团队熟悉、驱动支持良好的系统。
• GPU 驱动与 CUDA：本地 LLM 推理和硬件转码都依赖 GPU 驱动。NVIDIA 卡需要安装 NVIDIA Driver，尽量安装随卡支持的稳定版本。
• Python 环境：建议使用 miniconda 或 venv 建立独立环境，避免系统 Python 被改乱。
• 容器环境：如果准备用 Docker，需要安装 Docker Engine 和 NVIDIA Container Toolkit。
• 磁盘空间：LLM 模型文件动辄几 GB 到几十 GB，转码任务还会产生大量中间文件，建议准备大容量的存储目录。
• 端口规划：Ollama 默认 11434，Dify 默认端口较多，FFmpeg 本身不占固定端口，但批量任务脚本的日志服务可能占用端口，规划时避免冲突。

3.2 驱动与 CUDA 验证

Linux 下先检查驱动状态：

nvidia-smi

如果命令能输出 GPU 型号、驱动版本和显存信息，说明驱动正常。接着确认 CUDA 版本是否满足上层框架要求：

nvcc --version

如果机器上已经有多个 CUDA 版本，建议用 conda 或 Docker 隔离，不要让全局版本冲突影响服务。

4. 本地 LLM 部署与启动

4.1 使用 Ollama 启动本地 LLM

Ollama 是目前把本地 LLM 服务化最省事的工具之一。它内置模型管理、API 服务和 OpenAI 兼容接口，适合中配集群快速跑通。

安装命令以 Linux 为例：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，先启动服务：

ollama serve

然后拉取一个适合中配显存的量化模型。这里以通用指示模型为例：

ollama pull qwen2.5:7b

启动模型并进入交互模式：

ollama run qwen2.5:7b

在交互模式里输入测试文本，确认模型能正常回答，再退出。

4.2 用 Docker 部署 Ollama

如果不想污染宿主机环境，也可以直接跑容器：

docker run -d --gpus all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

进入容器执行模型拉取：

docker exec -it ollama ollama pull qwen2.5:7b

这里要注意，容器内的模型目录是挂载卷，如果换机器或换容器，模型文件不会丢，但首次拉取模型会比较耗时。

4.3 部署 Dify 或 AnythingLLM

本地 LLM 服务启动后，就可以接上知识库应用。

Dify 的部署一般用 docker compose。先下载项目：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

启动完成后，在 Dify 的后台设置里填入 Ollama 的接口地址，例如：

http://127.0.0.1:11434

然后配置一个 LLM 供应商，选择 Ollama，填入模型名 qwen2.5:7b ，保存后就能在应用里调用。

AnythingLLM 的部署也类似，默认 Web 端口是 3001。启动后导出一套工作目录，把文档放进去，再配置 LLM 和向量模型，就能做基于本地文档的问答。

这里有一个值得关注的思路，就是“LLM wiki”式的知识库管理。用 Markdown 文件维护文档库，配合 Obsidian 或 Git，再通过 Dify/AnythingLLM 做向量化和问答。好处是知识内容保持纯文本可追踪，坏处是文档多了以后需要维护切分策略。

5. 视频转码部署与启动

5.1 FFmpeg 与 NVENC

GPU 转码的常用方案是 FFmpeg 搭配 NVIDIA NVENC。首先要确认 FFmpeg 编译时带上了 NVENC 支持：

ffmpeg -encoders | grep nvenc

如果输出里能看到 h264_nvenc 、 hevc_nvenc ，说明可以启用硬件编码。

5.2 单文件转码命令

将输入视频转成 H.264，并限制码率：

ffmpeg -hwaccel cuda -i input.mp4 \
  -c:v h264_nvenc -b:v 4M \
  -preset p4 -c:a copy \
  output_h264.mp4

如果想转 H.265/HEVC，把编码器换成 hevc_nvenc ：

ffmpeg -hwaccel cuda -i input.mp4 \
  -c:v hevc_nvenc -b:v 3M \
  -preset p4 -c:a copy \
  output_hevc.mp4

中配集群上可以反复压测不同档位的 -preset 和码率，找到画质与速度的平衡点。不要一开始就上最高质量参数，先把最小可运行配置跑通，再逐步调优。

5.3 批量转码脚本

批量转码建议用一个 Python 脚本遍历输入目录，把每个视频丢给 FFmpeg 处理，并输出独立日志：

import subprocess
import pathlib

input_dir = pathlib.Path("./input_videos")
output_dir = pathlib.Path("./output_videos")
output_dir.mkdir(exist_ok=True)

for video in input_dir.glob("*.mp4"):
    output_path = output_dir / f"{video.stem}_hevc.mp4"
    cmd = [
        "ffmpeg", "-hwaccel", "cuda",
        "-i", str(video),
        "-c:v", "hevc_nvenc",
        "-b:v", "3M",
        "-preset", "p4",
        "-c:a", "copy",
        str(output_path),
    ]
    print(f"processing: {video.name}")
    result = subprocess.run(cmd, capture_output=True, text=True)
    if result.returncode != 0:
        print(f"failed: {video.name}")
        print(result.stderr)
    else:
        print(f"done: {output_path.name}")

这个脚本可以作为批量任务的最小原型。要接任务队列，只需要把 glob 换成消息队列或目录监听。

6. 功能测试与效果验证

6.1 本地 LLM 基础生成测试

服务启动后，直接调用 Ollama API：

curl http://127.0.0.1:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5:7b",
    "prompt": "用一句话解释什么是本地LLM推理",
    "stream": false
  }'

判断标准：返回 JSON 中的 response 字段是否连贯， total_duration 是否在可接受范围。如果长时间无响应，先看 Ollama 日志和显存占用。

带流式输出的版本更适合接入对话类应用：

import requests

url = "http://127.0.0.1:11434/api/generate"
payload = {
    "model": "qwen2.5:7b",
    "prompt": "写一段关于视频转码技术栈的短文",
    "stream": True
}

with requests.post(url, json=payload, stream=True, timeout=300) as response:
    for line in response.iter_lines():
        if line:
            print(line.decode("utf-8"))

6.2 知识库问答测试

在 Dify 或 AnythingLLM 中上传一份 Markdown 文档，例如部署说明文档，然后提问：

根据文档内容，Ollama 默认监听哪个端口？

判断标准：回答是否引用了文档内容，而不是模型自由发挥。如果回答与文档无关，优先排查向量化是否成功、文档切分是否合理，以及检索结果是否真正返回了相关内容。

6.3 视频转码效果验证

转码完成后，用 FFmpeg 检查输出视频信息：

ffprobe -v error -show_entries format=duration,size \
  -show_entries stream=codec_name,width,height,bit_rate \
  -of json output_hevc.mp4

判断标准：

• 输出格式符合预期，编码器为 hevc 。
• 文件大小相对原始文件有合理的压缩比。
• 播放时无花屏、音画不同步。

转码失败时，重点看 stderr 中是否出现“No NVENC capable devices”或“Cannot load libcuda.so.1”，这通常表示 GPU 驱动或 FFmpeg 编译参数有问题。

7. 接口 API 与批量任务

7.1 OpenAI 兼容接口

Ollama 从较新版本开始提供 OpenAI 兼容的端点。以 /v1/chat/completions 为例：

import requests

url = "http://127.0.0.1:11434/v1/chat/completions"
payload = {
    "model": "qwen2.5:7b",
    "messages": [
        {"role": "system", "content": "你是一个视频编码助手。"},
        {"role": "user", "content": "推荐一种中等码率的 H.265 转码策略。"}
    ],
    "stream": False
}

response = requests.post(url, json=payload, timeout=300)
print(response.json())

Codex CLI 这类工具在接入本地模型时，通常也是填一个 OpenAI 兼容的 base URL 和模型名。也就是说，只要本地 LLM 服务提供 OpenAI 兼容协议，很多现成工具可以直接改配置接进来，不需要单独写适配层。

7.2 批量任务设计

LLM 批量推理和视频转码批量任务，建议分开设计。

LLM 批量任务要控制并发。显存足够时可以提高并发，显存不足时只能排队，否则会触发 OOM。可以保存待处理文本列表，逐条调用接口，失败重试两次，并将结果写入 jsonl 文件。

视频转码批量任务建议按“输入目录 -> 任务队列 -> 输出目录 -> 日志目录”的方式组织。每个任务保留一个独立日志，方便失败排查和断点续传。

8. 资源占用与性能观察

8.1 观察显存与 GPU 利用率

Linux 下最直接的方式是：

nvidia-smi dmon -s pucvmet

这条命令会周期性显示 GPU 利用率、显存使用率、温度、功耗等信息。观察时重点关注：

• LLM 加载模型后的显存占用是否稳定。
• 多次请求后显存是否持续上升，是否存在泄漏。
• 视频转码过程中 GPU 编码器利用率是否接近满载。

8.2 CPU 推理与 GPU 推理的差异

如果模型可以跑 CPU 推理，启动时取消 GPU 配置即可，但速度会明显下降。更稳妥的判断是：CPU 推理适合短文本、低并发、无实时要求的场景；GPU 推理适合对话、Agent、批量文档处理。

8.3 降低显存占用的思路

• 优先使用量化模型，例如 Q4_K_M、Q5_K_M 这类量化版本。
• 减少上下文长度，过长的上下文会线性增加 KV Cache 显存占用。
• 控制并发数，避免多个大请求同时挤占显存。
• 转码和 LLM 推理不要同时跑最重任务，错峰执行更稳定。

8.4 端口冲突与进程残留

服务启动失败时，优先检查端口是否被占用：

ss -tlnp | grep 11434

如果端口被残留进程占用，直接终止旧进程或修改服务端口。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
启动 Ollama 后模型拉取失败	网络问题或镜像源不可用	查看 Ollama 日志，检查模型仓库地址	更换可用镜像源或手动下载模型文件放入模型目录
显存不足导致 LLM 推理中断	模型体积超过显存容量	使用 nvidia-smi 查看显存使用	换小模型或量化版本，减小上下文长度，降低并发
CUDA 相关报错	驱动与 CUDA 版本不匹配	nvidia-smi 对比驱动支持版本	安装匹配的驱动，或使用容器环境隔离版本
FFmpeg 报 No NVENC capable devices	FFmpeg 未启用 NVENC 或驱动问题	执行 ffmpeg -encoders | grep nvenc	安装带 NVENC 的 FFmpeg，更新驱动
Dify 无法连接 Ollama	接口地址或模型名配置错误	curl 测试 Ollama API	确认地址、端口、模型名，检查网络策略
批量转码任务中途卡住	输出目录无权限或磁盘空间不足	查看任务日志和磁盘空间	释放磁盘空间，确保输出目录可写，增加失败重试
知识库回答与文档无关	向量化失败或切分不合理	查看向量数据库是否生成文档块	调整切分大小，重新生成向量，检查检索召回结果
接口超时	模型首字延迟高，或并发排队	观察显存与 GPU 利用率	降低并发，调大请求超时时间，使用流式输出

10. 最佳实践与使用建议

这套组合要长期稳定运行，建议从第一天就做好几个工程化习惯。

第一，第一次跑通时用小参数、小样本。LLM 用 7B 或更小的量化模型，转码用一分钟以内的短视频，全链路跑通后再放大规模。

第二，保留一套最小可运行配置。把 Ollama 的启动命令、Dify 的 docker compose、FFmpeg 转码命令分别记录下来，作为基准配置。机器出问题后，可以快速恢复到可用状态。

第三，目录与数据分区分开。模型文件、输入素材、输出结果、日志目录，分别放在明确的位置，不要混在一起。批量任务处理大量视频时，输入盘和输出盘尽量分物理盘或独立目录，避免磁盘 IO 相互干扰。

第四，接口服务必须做访问控制。本地 LLM 服务如果暴露到内网，要设置网络策略，避免被非授权用户调用。跨机器调用时，加密传输和鉴权不能省略。

第五，批量任务要加日志和失败重试。LLM 批量推理和视频转码都容易出现偶发失败，日志是排查的唯一依据。建议为每个任务写一个独立日志，并记录成功、失败、跳过三种状态。

第六，涉及人脸、声音、版权素材时必须确认授权。本地部署不代表可以随意处理素材，转码、剪辑、生成都只限自己有权处理的内容。

第七，发布或商用前要做效果复核。LLM 生成内容需要人工检查关键事实，转码后的视频要抽查画质和音画同步，不能只看日志输出成功。

11. 总结与下一步

中配 AI 集群的价值不在于挑战顶级训练集群，而在于把闲置计算资源变成可用的私有化服务。对于本地 LLM，关键是跑通“部署 -> 接口 -> 知识库 -> 批量任务”这条链路；对于视频转码，关键是用 NVENC 把 CPU 从繁重的编码任务中解放出来，并建立可追踪的批量处理流程。

如果手里正好有一台带 NVIDIA GPU 的机器，下一步建议先做两件事：一是用 Ollama 跑通一个 7B 量级的模型，验证 OpenAI 兼容接口能通；二是用 FFmpeg 把一个短视频从 H.264 转成 H.265，对比一下时间和文件大小。这两个验证做完，就能清晰判断这套组合在自己场景里是否值得继续投入。

再往后可以尝试把 LLM 服务接入 Dify 或 AnythingLLM 做文档知识库，也可以把 FFmpeg 批量脚本扩展成带任务队列的转码服务。最容易踩的坑其实就是并发和显存估计不足，先用小并发把整体链路跑稳，再逐步加量，整体会顺利很多。