我第一次在香港机房做大规模视频转码部署，是为了配合一家海外短视频平台的内容分发优化需求。他们希望将用户上传的视频快速转码为多码率、H.264/H.265 等格式，并尽可能在“边上传、边转码”的流程中实现最小延迟。

起初我以为：转码嘛，顶多开几个高线程 CPU VM，扔个 ffmpeg -i input.mp4，加点 preset 就能搞定。但当我看到任务调度中心的监控图：

• Intel Xeon Gold 6230 CPU 占用率 95% 常驻
• 负载平均值接近 70，系统濒临雪崩
• 每转一个 1080p 视频平均耗时 180 秒

我意识到，这种靠 CPU“堆资源”的方式不但效率低，还拖慢了其他业务服务。于是我开始重新设计系统架构，转向 基于 GPU 的转码加速，结合 FFmpeg 的 CUDA、NVENC 模块，全面释放硬件的真正潜力。

以下是我在 香港机房实战中的完整部署过程、踩坑经验和调优策略。

一、机房与硬件环境

1. 香港部署背景

• 机房：香港 MEGA-i 数据中心（Tier III，24/7 运营）
• 部署位置：1/2 机柜，冷通道布局
• 网络接入：BGP 多线（CMI + HGC + PCCW）
• 视频源：海外短视频平台 API 批量回源（10Gbps 接入）

2. 服务器配置

我们部署了两类服务器，分别承担不同角色：

A类：GPU转码节点（主力）

• 型号：Dell R750xa
• CPU：Intel Xeon Gold 6338 ×2（32c64t）
• GPU：NVIDIA A5000 ×2（24GB GDDR6）
• 内存：256GB DDR4
• 存储：2TB NVMe RAID1（OS）+ 8TB NVMe（缓存）
• 网络：双10GbE 光纤直连边缘交换机

B类：调度 & I/O 节点

• 无 GPU，专做任务队列、监控、文件收发
• Nginx + Redis + RabbitMQ + GlusterFS（同步至阿里云 OSS）

二、GPU 加速 FFmpeg 转码的部署与优化

1. 安装 NVIDIA 驱动与 CUDA 工具链

• 操作系统：Ubuntu 22.04 LTS
• GPU 驱动：470+
• CUDA 工具包：11.8

FFmpeg 版本：我们自己编译支持 NVENC（预编译版本有裁剪）

# 添加 NVIDIA 官方源
sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
sudo apt install nvidia-driver-470

# CUDA 安装（runfile 模式）
sudo sh cuda_11.8.0_*.run

# 编译支持 GPU 的 FFmpeg
sudo apt-get install libnpp-dev libx264-dev libx265-dev libfdk-aac-dev

./configure \
  --enable-nonfree \
  --enable-cuda \
  --enable-cuvid \
  --enable-nvenc \
  --enable-libx264 \
  --enable-libx265 \
  --enable-libfdk-aac

make -j$(nproc)
sudo make install

2. 验证 GPU 调用与转码效果

命令示例：H.264 NVENC 转码

ffmpeg -y -hwaccel cuda -hwaccel_output_format cuda \
  -i input.mp4 \
  -c:v h264_nvenc -preset slow -b:v 5M \
  -c:a copy output.mp4

关键参数说明：

• -hwaccel cuda：启用硬件加速解码（可大幅降低 CPU 开销）
• h264_nvenc：使用 NVIDIA 的 NVENC 编码器
• preset：选择编码效率（推荐 slow 或 p3，兼顾质量）
• b:v：码率设置，推荐使用固定码率 + CRF 调优

3. 实测结果对比

三、任务调度与多卡并发策略

1. FFmpeg 单卡并发控制

每块 NVIDIA GPU 默认支持最多 3~4 个并发转码 session。使用以下命令可以检测当前 session 数：

nvidia-smi encodersessions

为了避免卡死，我们给每个 FFmpeg 进程绑定具体 GPU：

CUDA_VISIBLE_DEVICES=0 ffmpeg -hwaccel cuda ...
CUDA_VISIBLE_DEVICES=1 ffmpeg -hwaccel cuda ...

2. 使用 nvidia-smi 实现动态调度脚本

我编写了一个调度器 gpu_scheduler.py，逻辑如下：

• 轮询所有 GPU 空闲状态；
• 将待转码任务排队；
• 如果有空闲卡则启动任务，并绑定 GPU；
• 转码完成后自动释放资源并更新 Redis 队列。

该脚本在每日处理约 4000~6000 段视频时表现稳定，几乎无异常中断。

四、优化与踩坑记录

问题 1：FFmpeg 启动失败，报错“Device not available”

原因：并发任务超过了 NVENC 的 session 限制（软限制）

解决：

每张 A5000 卡支持 5 个 session，控制并发任务上限；

通过 nvidia-smi 动态调度任务；

禁用掉桌面环境的 Xorg，避免 GPU 被占用。

问题 2：GPU 编码质量低于 CPU x264

问题表现：低码率下的图像噪点比 CPU 编码明显

解决方案：

将 -preset 设置为 slow 或 p4 以上；

对质量要求高的视频启用 二次编码（双 pass）；

开启 lookahead 和 rc-mode vbr_hq 参数提高码控质量：

-c:v h264_nvenc -preset p4 -rc vbr_hq -look_ahead 1 -cq 19

问题 3：转码时 NVMe 写入瓶颈

问题表现：当并发任务过多时，转码输出写入延迟上升，GPU 进入等待状态。

解决方案：

增加独立转码缓存盘：使用 Samsung PM9A3 NVMe

每个 GPU VM/容器绑定独立数据目录，避免 I/O 冲突

使用 ionice + taskset 限制 FFmpeg 写入优先级

五、后续扩展与监控

1. 可视化监控系统

我使用了如下组件进行实时监控：

• Prometheus + node_exporter：GPU/CPU/Mem 监控
• nvidia-dcgm-exporter：暴露 GPU 温度、功耗、session 占用
• Grafana：可视化面板，展示当前任务处理状态

每个 GPU 的利用率趋势一目了然，异常任务一眼识别。

六、GPU + FFmpeg，才是转码高效的未来

通过这套架构，我们实现了：

• 转码速度提升 6 倍，大幅降低视频处理延迟；
• CPU 使用率下降超 80%，释放系统资源给其他服务；
• GPU 利用率保持在 75~90% 高水位，效率最大化
• 转码成本下降近 60%，服务器资源利用率大幅提升

这次在香港服务器上的 GPU 转码优化实践，让我真正理解了“靠 CPU 堆性能”是过去时代的思路。想要在高并发、多格式、全球同步的跨境业务中站稳脚跟，必须走向更高性能、更智能的系统架构。