如果你手上有一批中低配置的服务器、旧PC或者工控机，组了个小集群后发现跑不动大模型训练，先别急着淘汰。这篇文章要聊的，是把同一个集群重新定位成两个非常实际的生产工具：本地LLM推理服务和批量视频转码流水线。换句话说，AI集群并没有终结，它只是找到了更合适的岗位。

严格说，这不是某个刚发布的开源项目，而是一套很多内容团队和开发者已经在使用的部署思路。用不了多少新硬件，模型推理可以在CPU/GPU混合模式下跑，视频转码也可以按机器并行分发。文章会从硬件检查、环境准备、模型服务搭建、转码流水线、接口调用、资源占用到常见排错，整套走一遍。

适合哪些人看：手头有旧机器、想离线跑LLM、又需要处理批量视频素材的开发者。文中的命令都是通用模板，具体路径、模型名、端口要根据实际环境替换。

1. 核心能力速览

先把这套方案的整体规格放出来，方便快速判断值不值得继续往下看。

能力项	说明
方案类型	中低配置设备组成的本地AI集群，非特定开源软件项目
核心应用	本地LLM推理服务、并行视频转码
硬件要求	多机可用，单机也可跑；CPU+内存可起步，有NVIDIA显卡可选
网络要求	局域网内互通即可，千兆网络是更稳妥的基础门槛
主要工具	Ollama / llama.cpp / vLLM（按需选型）、FFmpeg、Python、可选Docker
是否支持API	支持，本地推理框架通常暴露OpenAI兼容接口
是否支持批量任务	支持，可通过目录扫描脚本或任务队列分发
核心优势	硬件复用、离线可用、数据不出内网
主要局限	不适合大模型训练、不适合超大规模分布式高并发推理
启动方式	命令行启动服务，无统一一键包

表格里没有写具体显存占用，因为不同模型量化等级、上下文长度、并发数差别太大。唯一能确定的是：中低配设备建议先从小参数量模型开始验证，再逐步往上加。

2. 适用场景与使用边界

2.1 这套方案适合谁

• 手里有几台旧电脑、小主机、中低配服务器的个人开发者，想把这些硬件重新利用起来。
• 团队内部需要离线LLM服务，数据不能出内网，希望用本地集群提供问答、内容摘要、文本分类等能力。
• 内容生产团队需要批量处理视频转码，比如把一批素材从高码率转成低码率、统一封装格式、生成预览文件。
• 预算有限，不想为每个小任务都租云服务器的场景。

2.2 能解决什么问题

最常见的问题是“机器单独看性能都不强，但合在一起不知道能干嘛”。这套方案给出两个方向：

• LLM服务：把不同模型按机器拆分，一台跑7B量化模型，另一台跑文档解析模型，互不干扰。
• 视频转码：把待处理视频文件分发到各台机器，每台机器按自身CPU核数和GPU能力并发转码。

两个业务可以错峰运行。白天给内部同事提供LLM问答接口，夜间把批量视频转码任务跑完。

2.3 不适合什么场景

• 大模型训练或微调。中低配集群的PCIe带宽、显存容量和网络互联通常都不够，强行做分布式训练容易变成“负优化”。
• 多机联合推理大模型。普通千兆/万兆网卡跑张量并行，通信开销会吃掉大部分收益，远不如单卡大显存机器。
• 需要极低延迟的在线服务。本地集群受限于硬件，无法和云上高并发GPU实例比延迟。

2.4 合规与安全边界

本地LLM和视频转码都涉及内容安全，需要特别注意几点：

• 部署LLM模型时，确认模型权重许可证允许你的使用场景。商用前逐一核对模型卡的License。
• 视频素材必须有合法来源，涉及人物肖像、品牌内容时确认授权。
• 本地接口服务要限制访问范围，不要直接暴露到公网。
• 转码过程中如果涉及客户数据，传输和存储要注意隐私保护。

从安全角度看，这套方案的优势是“数据不出内网”，但这不代表可以忽略权限控制。内网服务同样需要鉴权和访问白名单。

3. 环境准备与前置条件

3.1 硬件与操作系统检查

建议先给每台机器做一次基础体检，确认配置再动手。

# CPU信息
lscpu

# 内存
free -h

# 磁盘
df -h

# 网卡地址
ip a

# 显卡信息（如果有NVIDIA显卡）
nvidia-smi

操作系统优先选择Linux，Ubuntu/Debian系比较省心，CentOS/Rocky需要注意仓库差异。Windows也能跑，但后续做多机脚本和定时任务会麻烦一些。

网络方面，各机器之间要能互相访问。最简单的验证方法：

ping 192.168.1.101

如果有多台机器，建议配置SSH密钥互信，后面分发任务文件时不用反复输密码：

ssh-keygen -t rsa -b 4096
ssh-copy-id user@192.168.1.101

3.2 驱动与运行时

如果使用NVIDIA显卡，先装好驱动和CUDA工具链。注意：驱动版本、CUDA版本、推理框架版本三者需要匹配，具体以各框架官方文档为准。

纯CPU推理不需要装CUDA，但内存要尽量大，模型量化要调低。

Docker不强制要求，但如果你希望快速隔离环境，可以统一安装。下面是一个通用安装示例，具体版本以官方文档为准：

sudo apt update
sudo apt install -y docker.io
sudo systemctl enable --now docker

3.3 安装FFmpeg

视频转码的底座是FFmpeg。各系统安装方式不同，通用命令如下：

# Ubuntu/Debian
sudo apt install -y ffmpeg

# 验证版本
ffmpeg -version

如果要做硬件编码，还需要确认FFmpeg是否编译了对应模块。验证方法：

ffmpeg -encoders | grep nvenc

没有输出表示当前版本不支持NVIDIA硬件编码，要么换显卡，要么换带硬件编码模块的FFmpeg构建包。

3.4 检查端口占用

后面要起LLM服务和转码监控服务，端口冲突很常见。提前检查：

ss -tlnp | grep -E "11434|8000|8080"

端口规划建议：

服务	默认端口（以实际框架为准）
Ollama	11434
llama.cpp server	8080
vLLM OpenAI接口	8000
自定义任务面板	9000

如果端口被占用，换一个端口再启动，不要硬怼。

4. 从本地LLM到推理服务部署

4.1 推理框架怎么选

中低配硬件选框架，主要看场景：

框架	适合场景	特点
Ollama	快速体验、命令行使用、内部小范围调用	安装简单，模型管理方便，提供OpenAI兼容接口
llama.cpp	自己控制线程数、CPU优化、GGUF量化模型	编译可控，资源占用低
vLLM	需要较高并发API服务的场景	吞吐量高，但显存和CPU要求更高

个人建议：第一次先上Ollama，验证流程最快。

4.2 Ollama部署示例

Ollama的完整安装命令以官方文档为准，常见Linux安装方式：

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

安装完成后先启动服务：

ollama serve

然后拉取一个适合中低配硬件的模型。模型标签按模型仓库实际可用的选择，示例：

# 拉取7B级别模型，具体标签以模型仓库为准
ollama pull qwen2.5:7b

# 运行模型
ollama run qwen2.5:7b

进入交互界面后，直接输入问题就能看到回复。按Ctrl+D退出。

如果机器配置比较低，优先选量化等级更高的模型。量化等级越低，体积越小，CPU跑起来越流畅，但生成质量会有一定损耗。这是取舍问题，不是配置越高越好。

4.3 多机集群怎么用才合理

中低配集群跑LLM，最合理的路线不是“把几台机器的显存拼起来”。普通网卡做张量并行，通信延迟会拖垮速度。

更务实的用法有两种：

• 每台机器各跑一个模型服务，对外提供多个不同功能的接口。
• 用任务队列把请求分发给不同机器，同一个模型起多个副本，提高并发。

推荐先用第一种方式。比如A机器跑一个7B通用对话模型，B机器跑一个更小的文档摘要模型，C机器留着晚上跑视频转码。

4.4 API服务启动验证

Ollama启动后，默认监听11434端口。可以验证本机接口是否正常：

curl http://127.0.0.1:11434/api/tags

如果返回JSON列表，说明服务正常。

也可以用一条curl测试对话接口，注意路径以实际框架版本为准：

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5:7b",
    "messages": [{"role": "user", "content": "用一句话介绍本地LLM"}]
  }'

响应里会包含模型返回的文本内容。如果超时，先看模型是否还在加载，再检查内存和显存占用。

5. 从集群到视频转码流水线

5.1 FFmpeg基础转码命令

单机先跑通，再上集群。

CPU转码通用命令：

# 从input.mp4转成h.264编码，中档画质
ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac output.mp4

如果显卡支持NVIDIA硬件编码，可以这样：

# 使用NVIDIA硬件编码
ffmpeg -i input.mp4 -c:v h264_nvenc -preset p5 -cq 23 -c:a aac output.mp4

-cq 类似于质量系数，数字越小质量越高，文件越大。具体参数需要按素材测试，没有固定最优值。

5.2 多机并行转码

多机转码的核心思路：把文件分发到各台机器，每台机器按自己的资源情况设置并发数。

简单做法是共享目录：

• 有NAS就直接挂载到各机器。
• 没有NAS，用rsync同步文件。

示例：把本机素材同步到另一台机器：

rsync -avz ./input/ user@192.168.1.102:/data/input/

转码完成后把结果拉回来：

rsync -avz user@192.168.1.102:/data/output/ ./output/

这种做法适合离线批量任务，不需要写复杂的调度系统。文件量大了以后，再考虑用消息队列或者任务管理面板。

5.3 核数与并发控制

视频转码是CPU密集任务，并发数必须控制。

一个稳妥的经验值：并发任务数约为CPU物理核数的一半。比如8核机器，先开4个转码任务，观察CPU占用和温度再调整。

设置FFmpeg线程数：

ffmpeg -i input.mp4 -threads 4 -c:v libx264 -preset medium -crf 23 output.mp4

如果机器同时跑LLM服务，转码并发更要保守。否则LLM响应会被转码任务拖慢，两边体验都不好。

5.4 与LLM服务错峰调度

最省事的调度方案是按时间段分配：

• 白天：LLM推理服务为主，转码暂停或只跑1个任务。
• 夜间：停止LLM服务或保留低负载模型，把剩余算力全给转码。

如果不想手动操作，可以用cron定时启动和关闭任务：

# 凌晨2点启动批量转码脚本（示例）
0 2 * * * /usr/bin/python3 /opt/transcode/batch_run.py

6. 接口 API 与批量任务

6.1 LLM接口调用示例

本地LLM服务本质是HTTP接口，可以接到自己的工具、脚本甚至IM机器人里。用Python调用一个OpenAI兼容接口的通用模板如下，实际路径以部署框架为准：

import requests

url = "http://127.0.0.1:11434/v1/chat/completions"

payload = {
    "model": "qwen2.5:7b",
    "messages": [
        {"role": "user", "content": "把下面这段文字总结成3个要点：本地AI集群可以跑LLM，也可以做视频转码，关键是合理分配硬件资源。"}
    ],
    "temperature": 0.3
}

resp = requests.post(url, json=payload, timeout=180)
data = resp.json()

if "choices" in data:
    print(data["choices"][0]["message"]["content"])
else:
    print(data)

这个模板里没有鉴权参数。如果服务暴露到内网其他机器，建议加上API Key或IP白名单。纯本机测试可以暂时忽略。

6.2 批量转码脚本模板

把一批MP4文件从输入目录转到输出目录，用Python脚本循环调用FFmpeg：

import subprocess
from pathlib import Path

INPUT_DIR = Path("./input")
OUTPUT_DIR = Path("./output")
OUTPUT_DIR.mkdir(exist_ok=True)

for src in INPUT_DIR.glob("*.mp4"):
    dst = OUTPUT_DIR / src.name
    cmd = [
        "ffmpeg", "-y",
        "-i", str(src),
        "-c:v", "h264_nvenc",
        "-preset", "p5",
        "-cq", "23",
        "-c:a", "aac",
        str(dst)
    ]
    print(f"transcoding: {src.name}")
    result = subprocess.run(cmd, capture_output=True, text=True)
    if result.returncode == 0:
        print(f"success: {src.name}")
    else:
        print(f"failed: {src.name}")
        print(result.stderr[-2000:])

需要注意几点：

• 脚本没有做失败重试，生产环境建议结合日志重试三次。
• 如果CPU转码，把 h264_nvenc 改成 libx264 ，并去掉 -preset p5 。
• 输出文件已经存在时， -y 会直接覆盖，按需决定是否保留。

6.3 简单任务队列设计

批量任务多了以后，建议不要把几百个任务直接一次性循环。更稳妥的方式是“目录扫描+状态管理”：

./input/       # 待处理文件
./processing/  # 正在处理的文件
./done/        # 处理成功
./failed/      # 处理失败

脚本流程：

1. 扫描 input/ ，把文件移动到 processing/ 。
2. 调用FFmpeg转码到输出目录。
3. 成功则把源文件移动到 done/ 。
4. 失败则移动到 failed/ ，记录错误日志。

这样即使脚本中途断了，重启后也能从剩余文件继续处理，不会重复转码。

6.4 失败重试建议

转码失败最常见原因是编码器参数不支持、源文件损坏、磁盘空间不足。重试脚本只需要对 failed/ 目录里的文件再跑一遍。是否跳过已存在文件，取决于你的需求。

接口API调用失败的原因则多倾向于模型未加载完、请求超时、上下文超长。调用方建议设超时时间，不要无限等。

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

如果频繁超时，要么换更小的模型，要么减少单次请求的文本长度。

7. 资源占用与性能观察

7.1 显存和内存怎么看

LLM推理过程中，建议常开两个观察窗口：

watch -n 1 nvidia-smi
htop

nvidia-smi 看显存、GPU利用率、温度； htop 看CPU和内存总占用。

中低配机器跑LLM，显存很容易成为瓶颈。如果显存不够，模型的一部分层会落到CPU内存里，推理速度明显变慢。观察指标就是显存是否接近上限。

7.2 哪些参数会影响资源占用

LLM推理方面：

• 模型参数量
• 量化等级：比如4bit、8bit
• 上下文长度：越长占显存越多
• 并发请求数：并发越高，KV Cache占用越大

视频转码方面：

• 输入分辨率
• 编码器类型：硬件编码占用GPU，软件编码占用CPU
• 输出码率或CRF/CQ值
• 并发任务数

这些参数没有统一最佳值，必须用实际素材测试。建议记录一组“最小可运行配置”，比如用128 token上下文、低分辨率测试视频，先把流程跑通，再逐步加压。

7.3 如何降低显存占用

如果LLM推理显存不足，优先级从高到低：

1. 换量化等级更高的模型。
2. 降低上下文长度。
3. 减少并发数。
4. 开启推理框架的CPU offload选项。

如果转码和LLM同时跑导致资源竞争，最简单的办法就是错峰。不要指望一台8G显存的中配卡既跑大模型又做硬件编码能同时拉满。

7.4 进程和端口检查

服务启动后检查监听端口：

ss -tlnp | grep 11434

如果服务崩溃或端口残留，先查进程：

ps aux | grep ollama
ps aux | grep ffmpeg

杀残留进程：

kill 12345

需要强制结束再带 -9 ，但优先用普通kill。

8. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
LLM服务启动后一直加载	模型文件较大或首次加载需要时间	查看日志、观察CPU/内存/磁盘读取	等待模型完全加载后再请求；换更小量化模型
显存报错或进程被杀	显存不足	nvidia-smi 查看显存占用	换小模型、降上下文、减少并发、开启内存offload
API请求超时	模型未加载完或并发过高	看服务日志，检查请求时间	延长超时时间、降低并发、换小模型
多机访问不到Ollama	服务只绑定了本机回环地址	检查监听地址，检查防火墙	按官方文档绑定局域网地址；开放对应端口
FFmpeg提示找不到nvenc	FFmpeg版本没有硬件编码模块	ffmpeg -encoders 检查	换带硬件编码的FFmpeg构建包；或改用CPU编码
转码任务卡住	输入文件损坏或参数异常	查看FFmpeg输出日志	限制日志长度，记录失败文件到failed目录，人工检查
批量任务跑一半中断	脚本被kill或机器重启	查看目录状态， processing/ 是否有残留	按“待处理/处理中/成功/失败”目录恢复，重新执行
本地LLM输出质量不稳定	温度参数高、提示词不明确	降低temperature，细化提示词	固定参数，把常用提示词模板化
磁盘空间突然占满	转码输出文件过大或日志累积	df -h 查看分区	定期清理输入/输出文件，日志轮转
安装依赖失败	系统包版本较低或网络源问题	查看包管理器日志	换镜像源，按官方文档指定版本安装

9. 最佳实践与使用建议

9.1 先跑通最小闭环

第一次不要直接上集群。先在一台机器上完成：安装Ollama、拉一个7B模型、调用一次接口、用FFmpeg转一个短视频。整个流程跑通后，再扩展到多机。

最小闭环的验收标准：

• LLM接口返回正常文本。
• 转码命令成功生成输出文件。
• 资源占用没有被打满导致机器卡死。

9.2 目录结构规划

建议所有机器使用同样的目录结构，避免脚本到处找路径：

/opt/local-ai/
├── models/        # 模型文件或模型下载脚本
├── inputs/        # 待转码素材
├── outputs/       # 转码结果
├── logs/          # 任务日志
└── scripts/       # 调度脚本和API调用脚本

9.3 任务日志与失败重试

批量转码和LLM调用都要加日志。至少记录：

• 任务开始时间
• 输入文件
• 输出文件
• 退出码
• 错误信息最后500字符

有了日志，第二天早上看一遍就能定位大部分问题。

9.4 接口安全限制

本地LLM接口不要裸奔暴露到公网。常见做法：

• 只监听内网地址。
• 设置访问白名单。
• 资源充足时在反向代理上加API Key验证。

9.5 模型与工作流文档化

多机集群时间长了容易“只有自己看得懂”。建议把每台机器的配置、已部署模型、API端口、常用命令整理成一份LLM wiki文档，用Markdown维护即可。

内容至少包括：

• 每台机器的IP、角色、显存/内存配置。
• 已经安装的推理框架和版本。
• 当前运行的模型标签和量化等级。
• 视频转码的常用命令模板。
• 历史踩坑记录。

这样新同学接手，或者三个月后自己回来看，也能快速恢复状态。

9.6 版权与授权提醒

无论跑LLM还是转码，都要守住内容合规底线。模型权重有许可证要求；视频素材有版权和肖像权问题；接口输出内容也要审查。商用前做一次完整的合规检查，不要等出问题再补救。

10. 总结与下一步

AI集群没有终结，它只是换了个方向。中低配设备跑大模型训练确实吃力，但做本地LLM推理服务和批量视频转码，反而能够物尽其用。整个方案的性价比体现在硬件复用、离线部署、内网数据安全三个点上。

如果你现在手边已经有几台旧机器，建议按这个顺序操作：

1. 在一台机器上装好FFmpeg和Ollama，跑通一条LLM接口请求。
2. 用单条命令完成一个视频文件转码。
3. 把转码脚本改成目录扫描模式，处理一批文件。
4. 再考虑多机分发、错峰调度和API接入。

最容易踩的坑就是并发开太大。LLM推理和视频转码叠加在一起，资源竞争非常明显。先用最小参数验证，逐步加负载，比一开始就拉满要稳得多。

下一步可以做的方向很多：给批量转码脚本加一个简单的任务管理页面；把LLM接口接到内部工单系统；用监控工具观察各台机器的温度、显存、CPU占用。先把今天这套最小流程跑起来，集群才算真正“找到了新工作”。