如果你也和我一样想把 InfiniteTalk 这套基于 Wan2.1 的数字人方案完整落到本地 A800 服务器上那这篇文章应该能帮你跳过最难受的“依赖地狱”阶段。我拿到那台 A800 时信心很足以为 80GB 显存能把所有模型都塞进去结果前三天基本都在跟驱动、CUDA、gcc、PyTorch、diffusers、flash-attn 这几个东西组成的版本矩阵死磕。整篇内容适合两类人一是准备在 A800 或类似数据中心显卡上部署 Wan2.1 数字人项目的开发者二是已经被各种依赖报错折磨过、想要一份能直接抄作业的完整清单的人。1. 开机第一件事摸清 A800 的显存底牌给 InfiniteTalk 建一份预算表1.1 A800 与 A100/H800 的差异很多人的第一反应是“A800 不就是阉割版的 A100 吗”。这话对但不够准确。A800 的 sm_80 架构和 A100 几乎一致FP16/BF16 算力基本没缩水显存同样是 80GB HBM2e单卡跑大模型推理完全够用。但它和 A100 最明显的区别在于 NVLink 桥接带宽A100 能做到 600GB/sA800 被限制到 400GB/s多卡 tensor parallel 的通信损耗会比 A100 环境明显更高。我这个 InfiniteTalk 落地场景是单卡推理所以 NVLink 的影响可以忽略。但如果你后续想让多个数字人实例并行跑建议走“一实例一卡”的路子而不是把多张 A800 强行拼成一张逻辑大卡去跑 tensor parallel。多卡并行在这种场景下不仅收益有限还会引入额外的通信瓶颈和调度复杂度。1.2 显存预算表和我的初期误判我最初的设想非常粗暴Wan2.1 是 14B 参数BF16 权重差不多 28GB加上 TTS 和唇形同步模型80GB 显存怎么都够了。这个判断大方向没错但实际跑的时候我差点翻车。当我同时把 Wan2.1 的 transformer、VAE、TTS、唇形模型全部执行.to(cuda)之后显存直接逼近 60GB再叠加中间激活和临时视频帧缓冲很容易在生成到一半时触发 OOM。我的建议是先给整个系统做一份显存预算表心里有数再动手模块模型规模示例单卡显存占用BF16Wan2.1 I2V 14B transformer约 14B 参数28~32GB推理时激活峰值可到 42GB 左右VAE 编解码约 1~2B 参数3~4GBTTS 语音合成模块0.5~2B 参数3~5GB唇形同步模型0.3~1B 参数2~4GBCUDA context 与临时 buffer不随模型增大2~4GB按照这个表全量加载的峰值大概在 45~55GB。A800 的 80GB 显存虽然能扛但如果你把每个模型都常驻显存一旦视频帧尺寸调大、batch 或 num_frames 调高显存余量就会变得很紧张。后面我换成了“分时复用”策略先完成 Wan2.1 视频生成并释放模型句柄再加载唇形同步模型去对齐嘴型。峰值显存从接近 60GB 降到 45GB 左右剩余空间充裕很多长任务也稳定不少。1.3 开机自检三件套拿到服务器后不要急着装环境。先跑三组命令nvidia-smi nvidia-smi -q -i 0 -d COMPUTE lscpunvidia-smi看驱动版本和显存总量nvidia-smi -q -i 0 -d COMPUTE确认 GPU 是否识别成 Compute Capability 8.0lscpu确认 CPU 核数这会影响后续编译 flash-attn 时的MAX_JOBS设置。如果 CPU 核心很多编译并行度太高可能直接吃满内存所以这个信息必须提前掌握。接着执行nvidia-smi -pm 1开启持久化模式。这一步单看不重要但它能避免 GPU 驱动在每次 CUDA 调用时重复初始化。实际运维中如果没开 persistent mode程序退出后显存有时不会立刻回收表现就是“进程已经杀了但显存还是被占着”下一轮推理直接 OOM。这种问题排查起来非常恼火所以最好从一开始就把它打开。2. 依赖地狱第一层驱动、CUDA 与 gcc 的三角关系2.1 驱动版本决定上限驱动是整套环境的天花板。如果服务器上的驱动还是 470 或者 460那么 CUDA 12.x 工具链基本跑不起来PyTorch 官方 wheel 也会报出各种底层库找不到的错误。A800 上建议驱动至少 525 以上我最终用的是 545 系列。Ubuntu 22.04 上可以直接走 NVIDIA 官方 apt 源安装sudo apt update sudo apt install -y nvidia-driver-545 sudo reboot重启后nvidia-smi右上角会显示一个 CUDA Version比如 12.3。注意这个数字只是驱动能够支持的最高 CUDA 版本并不代表系统已经装了对应的 CUDA Toolkit。很多人把这里的 12.3 当成“CUDA 已经装好了”结果后面编译 flash-attn 时找不到 nvcc就会一头雾水。驱动是 runtime 基础nvcc 是编译工具二者不是一件事。2.2 系统 gcc 为什么突然变成瓶颈依赖地狱的第二个伏笔是系统编译器。Ubuntu 22.04 默认 gcc 可能是 11 或 12看起来没问题但当你安装某些 CUDA 扩展、或者编译 flash-attn 这类包含 CUDA 源码的包时nvcc 对宿主 gcc 的版本有严格限制。一旦 gcc 过新编译过程中会出现一串莫名其妙的语法错误甚至报gcc: error: unrecognized command-line option -no-gcc-compatible-march这种让人摸不着头脑的东西。原因在于 nvcc 会调用宿主 gcc 做预处理和链接新版 gcc 引入的参数或函数签名老版 nvcc 不一定认识。我的做法是把 gcc/g 固定到 11sudo apt install -y gcc-11 g-11 update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 100 update-alternatives --install /usr/bin/g g /usr/bin/g-11 100然后gcc --version确认。别小看这一步我那次排错两个小时最后才发现是 gcc 版本过新导致的编译失败。对于一个追求稳定的推理环境编译器版本也是需要锁定的依赖。2.3 conda 里重建一套独立 CUDA 工具链我不会直接去动系统的/usr/local/cuda而是给 InfiniteTalk 单独建一个 conda 环境然后在这个环境里装完整 CUDA 工具链conda create -n infinitetalk python3.10.14 -y conda activate infinitetalk conda install -c nvidia cuda-toolkit12.4 cudnn8.9 -y为什么不在安装 PyTorch 之后用它的自带 CUDA runtime 就够了因为 PyTorch 的 wheel 里通常只包含 runtime 库不携带 nvcc。编译 flash-attn 时需要 nvcc 和头文件没有完整 toolkit 就会卡在第一步。conda 里装 cuda-toolkit 以后当前环境的bin/下自然会有 nvcc 和 ptxas后面 triton 需要 ptxas 时也能直接用。这里有一个很重要的操作纪律不要为了让系统识别 CUDA 而手动往LD_LIBRARY_PATH里添加/usr/local/cuda/lib64。一旦你机器上同时存在多个 CUDA 版本混在一起就是经典的libcudart.so.11 与 libcudart.so.12 冲突现场。conda 环境的默认库搜索路径会优先找到环境内自己的库所以保持不手动改LD_LIBRARY_PATH反而是最安全的选择。3. 版本锁才是真正的胜负手Python、PyTorch 与 diffusers 的一一对应3.1 用确定的版本号替代 pip install 的“随缘”依赖地狱最常见的入口就是无脑pip install diffusers、pip install transformers然后期待一切顺利。我第一次就是这么干的结果把 diffusers 拉到了 0.34 以上的新版本再加载 Wan2.1 权重时直接报KeyError: transformer这个错误表面看是代码问题本质是 diffusers 内部组件映射与 Wan2.1 的模型配置错位了。Wan2.1 的 pipeline 对 diffusers 版本有特定要求太新反而可能和权重 config 不相容。我最终锁定的关键版本如下pip install torch2.4.1 torchvision0.19.1 torchaudio2.4.1 --index-url https://download.pytorch.org/whl/cu124 pip install diffusers0.32.2 transformers4.46.3 accelerate safetensors einops sentencepiece这个组合在我这里可以稳定加载 Wan2.1 I2V 14B 模型。锁版本不是强迫症而是开源模型迭代太快导致的客观现实。Wan2.1 刚发布时diffusers 对应 API 还在快速变化等新版本把组件命名改掉后旧权重配置文件就和新代码对不上了。你要么跟着模型源码走要么用官方验证过的依赖版本锁定方案二选一。3.2 triton 和 ptxas 之间的隐性锁另一个常见炸点是 triton。PyTorch 2.4.1 会依赖特定版本的 triton而 diffusers 或 flash-attn 在运行时会通过 triton 编译一些算子这时候会调用 CUDA 的 ptxas。如果PATH里的 ptxas 来自另一个 CUDA 版本或者干脆找不到 ptxas就会出现error: unknown argument: --ptxas-options-v解决办法是显式告诉 triton 该用哪个 ptxas。在 conda 环境里ptxas 路径一般在export TRITON_PTXAS_PATH/opt/conda/envs/infinitetalk/bin/ptxas把这句话写到项目启动脚本里而不是临时在命令行执行。如果不设置等跑长视频生成到一半再崩出来重新加载模型的时间成本非常高。这个隐性锁是那种“不遇到没事遇到一次就浪费半天”的坑。3.3 完整依赖清单与理由我把最终稳定的依赖版本列成一张表方便大家对照检查包名选定版本理由Python3.10.143.12 对部分扩展包兼容性差编译容易失败torch2.4.1cu124与 flash-attn 2.6.3 有比较好的兼容性diffusers0.32.2Wan2.1 pipeline 对应关系稳定transformers4.46.3与 diffusers 0.32.2 匹配einops0.7Wan 的注意力实现依赖opencv-contrib-python-headless4.10.x避免缺少 libGL 的报错imageio / imageio-ffmpeg最新稳定版用于导出视频帧Python 版本我特别强调 3.103.11 理论上也可以但我在 3.11 下编译某个 TTS 依赖时遇到过 wheel 缺失省事起见直接用 3.10。如果服务器上已经有其他项目在用 3.12千万不要图省事把两个项目塞进同一环境依赖隔离能少掉 80% 的版本冲突问题。4. Wan2.1 模型落盘权重目录、分片文件和校验缺一不可4.1 在服务器上直接拉取官方权重模型权重下载这一步看似简单实际也能踩坑。比如下载中断导致文件不完整加载时却报一些和内存、显存相关的奇怪错误。我建议用 ModelScope 官方 SDK 下载并自动落盘到本地目录from modelscope import snapshot_download model_dir snapshot_download( Wan-AI/Wan2.1-I2V-14B-480P, local_dir/data/models/Wan2.1-I2V-14B-480P ) print(model_dir)如果你拿来练手的是小显存机器可以先选 Wan2.1-T2V-1.3B 或 I2V-1.3B 这类小模型。1.3B 版流程完全一致只是画质低一些适合先把链路跑通。最后再上 14B 版。项目正式落地我默认以 14B-480P 为基准720P 版也可以跑但显存和生成耗时都会明显上涨。4.2 本地目录结构长什么样权重落盘后不要急着写代码先把目录结构检查一遍。一个完整的 Wan2.1 I2V 权重目录至少应该有这些部分/data/models/Wan2.1-I2V-14B-480P/ ├── model_index.json ├── scheduler/ │ └── scheduler_config.json ├── text_encoder/ │ ├── config.json │ └── model.safetensors ├── tokenizer/ │ ├── tokenizer_config.json │ └── vocab.json ├── transformer/ │ ├── config.json │ └── diffusion_pytorch_model.safetensors └── vae/ ├── config.json └── diffusion_pytorch_model.safetensors如果某个子目录缺失加载时报的错误不一定是“文件不存在”而是一串和 token 或 config 相关的晦涩信息。比如 tokenizer 没下全可能直接报 token 相关异常让人完全联想不到是下载不完整。所以下载完成后建议看一下总目录大小和模型卡页面上的文件大小做粗略比对心里有个底。4.3 加载不到模型的三种典型症状我在实际部署中遇到过几种典型症状这里列出来供大家对照OSError: model_index.json not found指定路径不对或者只下载了部分目录。确认local_dir是否指向包含model_index.json的那一层。ValueError: Unrecognized configdiffusers 版本不匹配或者某个 config.json 文件损坏。先检查版本锁再重新下载对应文件。加载过程没问题但一进入生成就CUDA error或直接段错误权重文件不完整。用snapshot_download重新拉取并确认磁盘空间足够。这三种问题都不需要去动模型代码90% 的情况是权重文件不完整或目录层级不对。先把数据层检查干净再往上层排查效率最高。5. flash-attn 编译全程记录A800 的算力代码被默认检测坑惨了5.1 为什么非编译不可Wan2.1 这类扩散模型的 transformer 大部分是 attention 结构PyTorch 自带的 eager attention 也能跑但显存占用和速度都比较吃亏。flash-attn 对 attention 的前向计算和显存占用有明确优化尤其当数字人视频生成长序列时num_frames拉到 81 帧甚至更高注意力部分的序列长度不短装了 flash-attn 之后生成耗时和显存峰值都能得到明显改善。在 A800 单卡上我测试下来同样 30 步、81 帧、480P 分辨率eager attention 大约需要 300 秒左右峰值显存接近 46GB换成 flash-attn 之后耗时能压缩到 240 秒上下峰值显存也降到 42GB 左右。这个差距在批量生成时会被放大所以别偷懒跳过这一步。5.2 真正有效的编译步骤编译 flash-attn 时最大的坑是算力代码。A800 的 compute capability 是 8.0但编译脚本默认可能探测到 9.0或者从别人的环境中复制了错误的TORCH_CUDA_ARCH_LIST导致编译时报Unsupported gpu architecture compute_90解决办法很简单显式指定为 8.0export TORCH_CUDA_ARCH_LIST8.0 export MAX_JOBS4 pip install flash-attn2.6.3 --no-build-isolationMAX_JOBS4是为了限制编译并行度。如果你服务器 CPU 核心很多默认并行编译会把内存吃满轻则编译变慢重则直接把机器卡死。编译时间大约 20 分钟如果内存紧张就降到 2。编译完成后记得验证import flash_attn print(flash_attn.__version__)5.3 与 eager attention 的实际对比我在同一台 A800 上做了简单对照运行模式30步 81帧 480P 耗时峰值显存eager attention约 300 秒约 46GBflash-attn约 240 秒约 42GB这个数据会随具体参数略有浮动但趋势是稳定的。flash-attn 在长序列场景下提升非常明显尤其是嘴型同步那一层还要处理逐帧图片特征整个链路末端省出来的时间更宝贵。6. 从一句话到一条 30 秒视频InfiniteTalk 全链路实践6.1 管线分层对话、语音、视觉、合成InfiniteTalk 本质上是把多个本地模型串成一个数字人系统。我把它分成四层来理解和调试对话/文案层决定数字人说什么。可以接本地 LLM也可以直接输入固定口播稿。语音合成层把文本转换成自然语音并输出音频文件。视觉生成层用 Wan2.1 的 I2V 能力输入一张首帧形象图生成带神态和动作的视频。唇形同步与合成层把语音驱动出的嘴型动作对齐到视频上最后用 FFmpeg 合并音轨和画面。每一层都跑在本地服务器上这就是“数字人本地模型”的核心价值声音、形象、对话都可以不出服务器隐私可控接口可定制。6.2 核心代码TTS 到 Wan2.1 视频再到唇形同步先说语音层。TTS 模块我用了支持本地部署的方案类似 CosyVoice2 或 GPT-SoVITS 这个量级的模型。最简单的调用方式是把文本输入得到 wav 文件同时拿到大概的时间戳信息from cosyvoice_infer import CosyVoiceWrapper tts CosyVoiceWrapper(model_dir/data/models/cosyvoice2) audio_path tts.synthesize(text大家好我是你的本地数字助手。, output_dir/data/output)视觉生成是重头戏。Wan2.1 的 I2V 模型输入一张首帧图和一个 prompt输出一段视频。这里用 diffusers 的自动 pipeline 加载import torch from diffusers import AutoPipelineForImage2Video from diffusers.utils import export_to_video pipe AutoPipelineForImage2Video.from_pretrained( /data/models/Wan2.1-I2V-14B-480P, torch_dtypetorch.bfloat16, variantbf16, ) image load_actor_image(/data/assets/actor.jpg) video_frames pipe( imageimage, promptthe woman is speaking naturally, head moving slightly, lip shape following the audio, negative_promptdistorted, flickering, low quality, static, height480, width832, num_frames81, num_inference_steps30, guidance_scale5.0, ).frames[0] export_to_video(video_frames, /data/output/base_video.mp4, fps16)这里有几个参数要解释。num_frames81配合fps16大约是 5 秒的视频。30 秒的视频可以拆成几段分别生成再拼接不要一次性把num_frames拉到几百显存和稳定性都扛不住。guidance_scale5.0是我测试下来比较稳的取值太低画面容易崩太高会让动作僵硬。num_inference_steps30是质量和耗时之间比较折中的档位。Wan2.1 原生 I2V 其实不直接吃音频所以数字人的嘴型对齐还需要一层唇形同步模型。我把上一步生成的视频和 TTS 音频一起丢给唇形同步模块sync_result lipsync.align( video_path/data/output/base_video.mp4, audio_path/data/output/voice.wav, output_path/data/output/sync_video.mp4 )最后用 FFmpeg 把同步后的视频和原始音频合并得到最终数字人视频ffmpeg -y -i /data/output/sync_video.mp4 -i /data/output/voice.wav \ -c:v libx264 -crf 18 -c:a aac -b:a 192k /data/output/final.mp46.3 单卡 A800 实测耗时我在 A800 上跑 30 秒口播视频的耗时大致如下阶段耗时估算TTS 语音合成2~3 秒Wan2.1 I2V 生成 6 段 x 81 帧每段约 240 秒合计约 24 分钟唇形同步约 20~30 秒FFmpeg 合成5 秒以内如果采用逐段生成再拼接的方式30 秒视频总耗时接近半小时如果只生成一个较短片段实时性会更好。相比 4090 上跑同类参数动不动一小时起步A800 已经算是很舒服的生产环境。不要指望数字人视频能做到纯实时生成当前开源扩散模型的推理耗时就在这里合理的工程策略是“预生成 缓存 按需替换内容块”。7. 我踩过的七个坑以及最终上线前的验证方法7.1 踩坑记录表这三天里我踩了不少坑挑七个最典型的记录下来后面再遇到可以直接照方抓药报错或现象根因解决办法torch.cuda.OutOfMemoryErrorWan、TTS、唇形模型同时常驻显存分时复用生成完 Wan 再加载唇形模型并执行torch.cuda.empty_cache()CUDA error: device-side assert triggered图像宽高或 num_frames 与模型要求不一致确保 width/height 是 16 的倍数num_frames 按4*n1规律设置Unsupported gpu architecture compute_90flash-attn 编译时算力代码探测错误export TORCH_CUDA_ARCH_LIST8.0后再编译ImportError: libGL.so.1opencv 依赖系统图形库安装libgl1 libglib2.0-0或改用 opencv-contrib-python-headlessKeyError: transformerdiffusers 版本与 Wan2.1 配置不匹配锁定 diffusers0.32.2 和 transformers4.46.3Error: unknown argument: --ptxas-options-vtriton 调用错误 CUDA 版本下的 ptxas设置TRITON_PTXAS_PATH指向 conda 环境内的 ptxasdocker 跑生成任务时/dev/shm空间不足docker 默认共享内存太小启动容器时加--shm-size16g宿主机关闭无关进程其中device-side assert triggered这个坑最隐蔽。它不是下载或者配置问题而是输入尺寸不合法触发 CUDA 内核的断言稍不留神就会以为显卡坏了实际上改一下宽高就能解决。7.2 从单条生成到连续多轮的验证路径环境装好、跑出一条视频后千万不要急着上线。先用一个简单脚本连续生成 3 条不同内容的视频观察显存是否会随着轮次增长for i in range(3): generate_clip(prompt_list[i]) torch.cuda.empty_cache()如果连续三轮都能稳定输出再测一下长文本和长时间视频。如果中途出现显存碎片化导致的 OOM大概率是某个模块没有在每一轮结束后释放或者VARIANTbf16没有正确开启导致模型被加载成 fp32。用nvidia-smi全程观察显存曲线比看日志更直观。7.3 上线前调优清单最后分享一份我每次部署数字人服务都会过一遍的检查清单打开nvidia-smi -pm 1避免显存回收不及时。用nvidia-smi dmon -s m -d 5做一段时长的显存监控记录峰值和波动。把 TTS、Wan2.1、唇形同步拆成独立进程通过消息队列或缓存文件解耦避免一个模块崩溃拖垮整条链路。长视频分段生成再拼接不要试图在单个 pipeline 调用里生成几百帧。如果在 docker 里部署一定要显式设置/dev/shm大小否则多进程视频编解码容易挂。对于更严格的低显存场景可以启用pipe.vae.enable_tiling()牺牲一点边缘画质换取显存余量。我在实际部署中的体会是A800 的硬件能力完全足够真正的风险全在软件依赖这层。先锁版本、再编译、再把流程拆成独立可验证的小块这套思路不仅适用于 InfiniteTalk 和 Wan2.1任何本地大模型项目都能受益。只要你在每一步都保留一个能跑通的最小结果依赖地狱就困不住你。