Live Avatar离线部署方案：内网环境安装完整流程

Live Avatar离线部署方案：内网环境安装完整流程

1. 模型背景与适用场景

Live Avatar是由阿里联合高校开源的数字人生成模型，专注于高质量、低延迟的实时数字人视频生成。它不是简单的图像驱动或语音驱动动画，而是融合了文本理解、语音建模、图像生成与运动合成的端到端系统，能根据一段文字提示、一张参考人像和一段音频，自动生成口型同步、表情自然、动作流畅的短视频。

这个模型特别适合需要在内网隔离环境中运行数字人服务的场景：比如企业内部培训视频自动制作、政务大厅AI导办员部署、金融行业合规话术演示、教育机构个性化课件生成等。所有数据不出本地，模型完全离线运行，满足强安全、高可控、零外联的业务要求。

但必须坦诚说明一个关键现实：Live Avatar当前对硬件资源要求极高。它基于Wan2.2-S2V-14B大模型架构，参数量达140亿级，推理过程涉及DiT（Diffusion Transformer）、T5文本编码器、VAE解码器等多个重型模块协同工作。因此，显存是第一道硬门槛——目前官方验证可用的最低配置，是单张80GB显存的GPU（如NVIDIA A100 80GB或H100 80GB）。我们实测过5张RTX 4090（每张24GB），总显存120GB，依然无法启动，原因并非总量不足，而是模型并行机制带来的瞬时峰值压力。

这背后的技术本质在于FSDP（Fully Sharded Data Parallel）在推理阶段的“unshard”行为：模型加载时虽被分片到各卡，但实际推理前需将全部参数重组回内存；单卡分片约21.48GB，重组过程额外占用4.17GB，合计25.65GB，远超24GB卡的实际可用显存（约22.15GB）。这不是配置错误，而是当前架构下24GB卡的物理极限。

所以如果你正计划在内网部署，请先确认硬件清单——这不是软件优化能绕开的问题。下面的内容，将严格围绕“已有80GB GPU”这一前提展开，提供一套可落地、可复现、不依赖外网的完整离线部署流程。

2. 离线环境准备与依赖安装

内网部署的核心原则是：所有依赖必须提前下载、校验、打包、导入。不能有任何一步触发pip install或git clone对外网的请求。

2.1 基础系统与驱动

我们以Ubuntu 22.04 LTS为基准环境（其他Linux发行版逻辑一致，仅命令微调）：

# 确认系统版本 lsb_release -a # 更新本地源（使用内网镜像源，如公司私有apt仓库） sudo sed -i 's/archive.ubuntu.com/mirror.internal.company.com/g' /etc/apt/sources.list sudo apt update && sudo apt upgrade -y # 安装基础编译工具与CUDA依赖 sudo apt install -y build-essential python3-dev python3-pip git curl wget unzip vim

2.2 NVIDIA驱动与CUDA Toolkit

Live Avatar要求CUDA 12.1+，建议直接安装NVIDIA官方提供的离线.run包：

# 下载CUDA 12.1.1离线安装包（提前从nvidia.com下载，传入内网） # 验证SHA256校验和 sha256sum cuda_12.1.1_530.30.02_linux.run # 关闭图形界面，执行静默安装 sudo systemctl stop gdm3 # 或lightdm/sddm sudo sh cuda_12.1.1_530.30.02_linux.run --silent --override # 添加环境变量（写入/etc/profile.d/cuda.sh） echo 'export PATH=/usr/local/cuda-12.1/bin:$PATH' | sudo tee /etc/profile.d/cuda.sh echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH' | sudo tee -a /etc/profile.d/cuda.sh source /etc/profile.d/cuda.sh

2.3 PyTorch与torchvision离线安装

从pytorch.org下载对应CUDA版本的whl包（注意选择cu121后缀）：

# 提前下载以下两个文件至内网服务器 # torch-2.3.0+cu121-cp310-cp310-linux_x86_64.whl # torchvision-0.18.0+cu121-cp310-cp310-linux_x86_64.whl # 离线安装（确保pip已升级） pip3 install --no-index --find-links /path/to/wheel/dir/ --upgrade pip pip3 install torch-2.3.0+cu121-cp310-cp310-linux_x86_64.whl pip3 install torchvision-0.18.0+cu121-cp310-cp310-linux_x86_64.whl

2.4 其他Python依赖离线打包

进入一台可联网的同版本Ubuntu机器，创建干净虚拟环境，安装Live Avatar所需全部包并打包：

python3 -m venv offline_env source offline_env/bin/activate pip install --upgrade pip # 安装Live Avatar requirements.txt中所有包（不含torch/torchvision） pip install -r requirements.txt --no-deps # 打包所有已安装的wheel pip wheel --no-deps --wheel-dir /tmp/wheels . # 打包依赖关系（生成requirements-freeze.txt） pip freeze > /tmp/requirements-freeze.txt

将/tmp/wheels/目录和requirements-freeze.txt整体拷贝至内网服务器，在目标机上执行：

pip install --no-index --find-links /path/to/wheels/ --upgrade --force-reinstall -r requirements-freeze.txt

3. 模型权重与代码的离线获取

Live Avatar本身开源，但其依赖的多个基础模型（T5-XXL、SDXL VAE、Wan2.2-S2V-14B DiT）均托管于Hugging Face Hub，内网无法直连。必须通过“代理机+缓存”方式完成全量下载。

3.1 在可联网机器上构建模型缓存

# 创建专用缓存目录 mkdir -p /mnt/hf_cache # 设置HF环境变量（临时） export HF_HOME=/mnt/hf_cache export HF_HUB_OFFLINE=0 # 使用huggingface-hub库批量下载（比git lfs更可靠） pip install huggingface-hub # 下载核心模型（按Live Avatar代码中model_path实际引用路径） python3 -c " from huggingface_hub import snapshot_download snapshot_download('Quark-Vision/Live-Avatar', local_dir='/mnt/hf_cache/Quark-Vision--Live-Avatar') snapshot_download('google/t5-xxl-lm-adapt', local_dir='/mnt/hf_cache/google--t5-xxl-lm-adapt') snapshot_download('stabilityai/sdxl-vae', local_dir='/mnt/hf_cache/stabilityai--sdxl-vae') snapshot_download('Quark-Vision/Wan2.2-S2V-14B', local_dir='/mnt/hf_cache/Quark-Vision--Wan2.2-S2V-14B') "

整个缓存目录大小约120GB。压缩后（tar -czf hf_cache.tar.gz /mnt/hf_cache）传入内网。

3.2 内网模型目录结构重建

在内网服务器解压后，按Live Avatar代码预期路径组织：

# 创建标准ckpt目录 mkdir -p ckpt/LiveAvatar ckpt/t5-xxl-lm-adapt ckpt/sdxl-vae ckpt/Wan2.2-S2V-14B # 软链接映射（避免修改代码） ln -sf /path/to/hf_cache/Quark-Vision--Live-Avatar ckpt/LiveAvatar ln -sf /path/to/hf_cache/google--t5-xxl-lm-adapt ckpt/t5-xxl-lm-adapt ln -sf /path/to/hf_cache/stabilityai--sdxl-vae ckpt/sdxl-vae ln -sf /path/to/hf_cache/Quark-Vision--Wan2.2-S2V-14B ckpt/Wan2.2-S2V-14B

3.3 项目代码获取与适配

从GitHub下载Live Avatar源码ZIP包（非git clone），解压后重点修改两处以彻底断网：

# 修改1：禁用所有自动下载逻辑 # 文件：inference/utils.py 中的 download_from_hf() 函数 # 替换为直接返回本地路径 def download_from_hf(repo_id, filename, local_dir): return os.path.join(local_dir, filename) # 直接拼接，不联网 # 修改2：硬编码模型路径 # 文件：inference/infinite_inference_single_gpu.sh 中的 --ckpt_dir 参数 # 改为绝对路径 --ckpt_dir "/home/user/liveavatar/ckpt/Wan2.2-S2V-14B" \

4. 单GPU 80GB完整部署与启动

确认硬件为单张A100 80GB或H100 80GB，并已正确识别：

nvidia-smi -L # 应显示 "GPU 0: A100-SXM4-80GB ..." nvidia-smi # 查看显存使用，空闲应>75GB

4.1 启动脚本精简与验证

使用官方提供的infinite_inference_single_gpu.sh，但需做三处关键调整：

#!/bin/bash # infinite_inference_single_gpu.sh （修改后） # 1. 显式指定GPU（避免多卡误识别） export CUDA_VISIBLE_DEVICES=0 # 2. 关闭所有网络检查（注释掉curl/wget相关行） # if ! command -v curl &> /dev/null; then ... -> 直接删除整段 # 3. 强制使用CPU offload（虽慢但稳，避免OOM） # 原 --offload_model False 改为 True python inference/infinite_inference.py \ --ckpt_dir "ckpt/Wan2.2-S2V-14B" \ --lora_path_dmd "ckpt/LiveAvatar" \ --prompt "A professional presenter in a studio, speaking clearly and smiling" \ --image "examples/portrait.jpg" \ --audio "examples/speech.wav" \ --size "704*384" \ --num_clip 50 \ --sample_steps 4 \ --offload_model True \ # 关键：启用CPU卸载 --num_gpus_dit 1 \ --ulysses_size 1

4.2 首次运行与日志观察

赋予执行权限并运行：

chmod +x infinite_inference_single_gpu.sh ./infinite_inference_single_gpu.sh > deploy.log 2>&1 & tail -f deploy.log

成功启动的关键日志特征：

• Loading model from ckpt/Wan2.2-S2V-14B...
• Model loaded on GPU:0, total params: 14.2B
• Using CPU offload for large tensors...
• Starting inference loop...

若卡在Loading T5 tokenizer...，检查ckpt/t5-xxl-lm-adapt路径是否正确；若报OSError: Can't load tokenizer，确认该目录下存在tokenizer.json和config.json。

4.3 Gradio Web UI离线启动

Web UI同样需断网适配。编辑gradio_single_gpu.sh：

# 注释掉所有在线检查 # python -c "import requests; requests.get('https://httpbin.org/get')" 2>/dev/null || exit 1 # 启动时绑定内网IP（非localhost），便于其他机器访问 python webui/gradio_app.py \ --server_name 192.168.10.100 \ # 替换为服务器内网IP --server_port 7860 \ --share False \ --enable_queue

启动后，局域网内其他机器浏览器访问http://192.168.10.100:7860即可操作，无需外网。

5. 内网安全加固与生产化建议

离线部署不等于安全无忧。以下是面向生产环境的加固要点：

5.1 权限最小化

• 创建专用用户运行服务，禁止root：

  sudo adduser --disabled-password --gecos "" liveavatar sudo usermod -aG video liveavatar # 加入video组以访问GPU sudo chown -R liveavatar:liveavatar /home/liveavatar/liveavatar/

• 服务以该用户身份启动，且工作目录权限设为750。

5.2 网络策略锁定

即使内网，也应限制服务暴露面：

• 仅监听内网IP（如192.168.10.100），禁止0.0.0.0
• 使用iptables封锁非必要端口：

  sudo iptables -A INPUT -p tcp --dport 7860 -s 192.168.10.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 7860 -j DROP

5.3 资源监控与告警

部署轻量级监控，避免显存耗尽导致服务僵死：

• 使用nvidia-ml-py3库编写Python脚本，每30秒检查GPU显存：

  import pynvml pynvml.nvmlInit() handle = pynvml.nvmlDeviceGetHandleByIndex(0) meminfo = pynvml.nvmlDeviceGetMemoryInfo(handle) if meminfo.used / meminfo.total > 0.95: # 发送邮件/企业微信告警，或自动重启服务

• 将脚本加入crontab定时执行。

5.4 备份与回滚机制

• 每次重大参数调整前，备份ckpt/目录和webui/配置；
• 制作Docker镜像（可选）：将整个环境打包为离线镜像，docker save -o liveavatar-offline.tar liveavatar:1.0，便于快速迁移。

6. 常见问题与内网特有问题解决

内网环境会放大一些在公网环境下不易察觉的问题，以下是高频故障及根因分析：

6.1 “No module named ‘bitsandbytes’” 错误

现象：启动时报错找不到bitsandbytes，但已离线安装。

根因：bitsandbytes是CUDA扩展，需与当前CUDA版本精确匹配，且编译环境必须一致。

解法：

• 在内网服务器上，用nvcc --version确认CUDA版本；
• 下载对应bitsandbytes-cu121的whl包（非通用版）；
• 安装时加--force-reinstall：pip install bitsandbytes-0.43.3+cu121-cp310-cp310-linux_x86_64.whl --force-reinstall

6.2 Gradio界面加载缓慢或白屏

现象：浏览器打开http://ip:7860后长时间转圈，或显示空白。

根因：Gradio默认从jsdelivr CDN加载前端资源（如React、Bootstrap CSS），内网无法访问。

解法：

• 下载Gradio离线前端包（官方提供gradio-offline分支）；
• 或修改webui/gradio_app.py，在gr.Interface(...)前添加：

  import gradio as gr gr.themes.Default()._static_root = "file:///home/liveavatar/gradio_static"

• 提前将Gradio静态资源（CSS/JS）下载并解压至/home/liveavatar/gradio_static。

6.3 音频驱动失败：“ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear”

现象：启动时大量ALSA警告，但不影响功能；少数情况下导致音频处理异常。

根因：内网服务器常无真实声卡，ALSA配置缺失。

解法：

• 安装dummy声卡驱动：sudo modprobe snd-dummy
• 创建/etc/asound.conf：

  pcm.!default { type hw card 1 } ctl.!default { type hw card 1 }

6.4 模型加载后显存未释放，二次启动失败

现象：第一次运行成功，kill进程后再次启动报OOM。

根因：PyTorch的CUDA缓存未清，nvidia-smi显示显存仍被占用。

解法：

• 启动脚本末尾强制清理：

  # 在脚本最后添加 python3 -c "import torch; torch.cuda.empty_cache()"

• 或使用nvidia-smi --gpu-reset -i 0（需root权限，慎用）。

7. 性能调优与效果保障指南

在80GB单卡上，Live Avatar的性能并非固定值，而是可通过参数精细调控。以下是经实测验证的平衡点：

7.1 分辨率与帧率黄金组合

关键发现：分辨率从688×368提升到704×384，显存占用激增10GB，但视觉提升边际递减。建议将704×384留作关键汇报场景，日常批量生成用688×368。

7.2 提示词工程：内网环境的特殊性

公网用户可随时搜索SOTA提示词，内网用户需建立自己的提示词库。我们总结出三条铁律：

• 必含要素公式：[人物基础] + [核心动作] + [环境光效] + [风格参考]

  • "A Chinese female anchor in blue suit, reading news with confident tone, studio lighting with soft shadows, CCTV broadcast style"
  • ❌"a woman talking"

• 规避中文陷阱：模型训练数据以英文为主，中文提示词效果不稳定。坚持用英文写提示词，哪怕描述中文场景（如"Chinese news anchor"）。

• 长度控制：120词以内最佳。过长会导致T5编码器截断，丢失关键信息。

7.3 输入素材质量红线

• 参考图像：必须为正面、高清、中性光照、JPG格式。实测PNG透明背景会导致VAE解码异常，输出视频边缘出现灰边。
• 音频文件：必须为单声道WAV，16kHz采样率。MP3转WAV时，用ffmpeg -i input.mp3 -ac 1 -ar 16000 output.wav，不可省略-ac 1（双声道会导致口型不同步）。

8. 总结：一条可行的内网数字人落地路径

Live Avatar的内网部署，本质是一场与硬件边界、网络限制和工程细节的深度博弈。本文没有回避它的苛刻条件——单卡80GB是当前不可逾越的底线；也没有美化它的复杂度——从CUDA驱动到Gradio前端，每一步都需亲手缝合。

但正因如此，当你的内网服务器上第一次跑出那个微笑说话的数字人视频时，那种掌控感是无可替代的。你拥有的不仅是一个工具，而是一套完全自主、安全可信、可审计可追溯的数字人生产能力。

这条路径的核心价值在于：它把前沿AI从云上的黑盒，变成了你机房里的一台确定性设备。你可以精确知道每一帧由哪块GPU计算，每一字节数据存于哪块硬盘，每一个API调用止于哪道防火墙。

接下来，就是把它真正用起来。从制作第一条员工入职培训视频开始，让技术回归服务人的本质。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。