8GB显存跑h3lite视频生成，从编译到出片

事情的起因很简单，想在本地跑视频生成，数据不出门，也不用排队。手里只有一张RTX 4060 Ti，8GB显存。2026年这个节点，主流视频模型基本20GB显存起步，8GB属于边缘配置。

后来看到Rimagination/h3lite这个项目，官方支持low-vram-w4a8路线，明确说8GB可以跑，就决定试一下。这篇文章就是整个部署过程的记录，包括遇到的坑和怎么解决的，希望能给同样配置的人省点时间。

一、环境

显卡，NVIDIA RTX 4060 Ti 8GB（sm89） 系统，Ubuntu 24.04 LTS，驱动595.84 Python 3.11.15独立venv，PyTorch 2.13.0+cu130，ComfyUI 0.33.0 模型，h3lite low-vram-w4a8量化方案，一共6个文件约21GB，包括12GB的量化主模型（w4a8）、Qwen3-VL 4B视觉编码器、视频VAE、音频VAE、ClipProj和lightx2v turbo LoRA

下载倒是顺利，断点续传，没出幺蛾子。

二、部署过程

按官方component-sets文档的Set A组件集来装，5个custom_nodes，ComfyUI启动日志Import times显示全部成功导入，0失败，/object_info里H3相关节点全部注册。到这一步都很顺，我一度以为这事儿没那么难。

三、坑一，SageAttention 2.2.0源码编译

ComfyUI的KJNodes节点依赖SageAttention 2.x，但PyPI上最新只有1.0.6，缺2.x的get_cuda_arch_versions API，装上直接报错。只能从源码编译。

编译需要CUDA工具链，系统里只有驱动没有完整toolkit，于是手工拼装CUDA 13.0工具链，一个坑接一个坑：

1. 缺nvcc编译器，从NVIDIA官方deb包提取
2. 缺cicc（nvcc底层编译器），同样从deb提取，这个文件不在标准路径，容易漏
3. 缺thrust/cub头文件，从CCCL发行版和venv的include目录补齐
4. 缺cudaEmulationSpecialValuesSupport、cudaEmulationMantissaControl类型定义，整个替换library_types.h才解决
5. 链接阶段找不到-lcudart，排查发现libcudart.so.13只有符号链接，实体库文件缺失，符号链接不算实体，ld照样找不到，下载官方cuda-cudart deb解包补齐

单独看每个都不难，难在它们层层叠叠，编译报错，查缺什么，补上，再报错，循环了五六轮。编译通过生成wheel，pip安装，KJNodes终于能加载SageAttention。

四、坑二，systemd-oomd内存杀手

模型全装好，第一次提交生成任务，ComfyUI加载模型到一半崩溃，没有任何CUDA报错，日志干干净净，进程直接没了。

查dmesg才找到凶手，systemd-oomd。low-vram模式加载主模型时进程峰值RSS约13.8GB，机器30GB物理内存被各种常驻服务占掉一大半，MTA后端、OpenViking、Dify、PostgreSQL，加上ZFS ARC缓存无上限增长能吃掉10GB以上，内存压力一大，oomd直接收割。

解法是给内存做减法，swap从8GB扩到24GB（fstab持久化），ZFS ARC上限限制到4GB（modprobe配置持久化，释放约6GB），vm.swappiness从60调到10。调整后可用内存从5GB回到18GB。

五、结果

重新提交，一次成功。5.17秒视频，640x352，24fps，568KB，输出正常。给朋友生成的问候视频也一次通过。

六、给同配置玩家的建议

1. 直接用官方low-vram-w4a8工作流模板，别自己搭，模型引用容易错
2. SageAttention 2.2.0必须源码编译，提前备好完整CUDA工具链，实体库文件（不是符号链接）要验证存在
3. 生成前查内存余量（free -h），峰值13GB+是常态，swap要留够
4. 崩溃且无CUDA报错时，先查dmesg确认是不是oomd收割，别在CUDA层面浪费时间
5. 机器上常驻服务多的话，优先处理ZFS ARC这类无上限吃内存的组件

总结就一句话，8GB显存跑视频生成可行，代价是内存管理要精细，swap要大、缓存要限、常驻服务要克制。量化模型加SageAttention加合理内存水位，小显存也能出片。