实现方式
Vflash 用自己的 PyTorch、Triton 运行时执行 H3 Transformer、LoRA 残差、调度更新和输出头。Ref4/T2VA 完整 Python 链路还协调明确列出的官方编码器、VAE 适配器和 MP4 输出，不导入 LightX2V 推理框架。
数据流
编译权重 + LoRA + 调度数据
↓
条件包 → 原生会话 → 视频和音频潜变量条件包包含编码后的文本与参考素材、序列布局和初始噪声，原生会话仍可独立使用。SM89 的 Ref4/T2VA 完整链路在前后接入固定版本的 Diffusers / Transformers 编码、官方音视频 VAE 和 FFmpeg 输出：
提示词 + 可选图片 → 官方编码适配器 → 原生核心 → 官方 VAE → MP4权重编译器独立读取所选配置的官方原始权重和固定 LoRA，打包保持精度的 BF16 矩阵，并预先计算固定调度的精确 AdaLN 表。模型准备不包含参考图或请求采集，基础权重和 LoRA 的来源分别绑定。
模型、LoRA、调度和硬件版本必须匹配。仅修改配置名称，不能转换资源或改变已编译请求的计算方式。
每层管理自己的资源
| 层次 | 管理内容 | 生命周期 |
|---|---|---|
| CLI 或 HTTP 服务 | 请求校验、任务状态、输出路径 | 一次命令或服务进程 |
| Ref4/T2VA 完整链路 | 编码器、VAE、原生会话和临时媒体 | 多个串行视频请求复用 |
| 原生会话 | 固定配置、显卡组、已加载的运行时 | 多个串行请求复用 |
| 单次执行 | 条件张量、工作潜变量、进度 | 一次 generate 调用 |
native/runner.py 是共同的会话入口；native/h3_native_conditioning_runtime.py 将校验后的输入交给计算模块。HTTP 服务通过独立 worker 进程调用同一个引擎，不另建一套模型执行流程。
NativeEngineSession 支持 with，也可显式调用 close()。关闭时先等待本会话的显卡完成工作，再关闭通信并释放持有的权重；调用方继续保存已关闭的 Python 对象，也不会因此保留这些权重。CUDA 上下文和分配器缓存仍属于进程，随 worker 退出释放。
HTTP worker 在推理失败后退出。Python 调用方应关闭失败的会话，不再继续使用。如果无法确认显卡已完成工作或清理成功，应退出该 worker，不能复用其 CUDA 上下文。任务记录与计算资源的生命周期分开：公开服务只保存内存中的任务状态，持久数据、身份认证和多机调度由上层应用提供。
避免反复加载和拷贝
张量存储对象索引一个不可变的 safetensors 文件，不长期占用文件描述符。分组读取一次校验所需张量的形状，然后直接写入最终 CPU 张量内存，避免反复解析同一文件头以及先分配字节缓冲、再克隆张量的拷贝。返回的张量独立持有数据，文件关闭后仍可使用。
分块推理采用有明确作用域的另一条加载路径：临时内存映射提供编译权重，数据复制到跨块共享的分段锁页内存后便关闭映射。跨块分配减少了内存对齐和分配粒度造成的浪费。大文件哈希在资源发布时校验；worker 保留格式、身份和大小检查，不在每次请求中重读整个模型计算哈希。
完整链路中的官方编码器与原生去噪器之间还有一个更窄的可信边界。两个阶段由同一进程串行持有，因此新捕获的请求使用经过校验、仅可消费一次的张量交接，不再生成临时条件文件；消费前会再次校验，并释放原生阶段不需要的捕获张量。持久化或跨进程条件数据仍使用 manifest 和内容哈希。
选择内存策略
48 GB 版 4090 默认让权重常驻显存。Python 集成可以显式选择 weight_residency="block-ring"，为中间计算结果留出更多显存。占用更多显存是否更快，应根据实际请求测量，分别记录首条和后续请求。
Ref4/T2VA 完整链路明确采用分块加载，让编码器、核心和 VAE 轮流使用同一张卡。这是完整链路的内存配置，不改变原生会话单独运行时的默认值。
20 GB 版 3080 将权重保存在锁页系统内存中，通过两个显存缓冲区交替加载。复制事件确认数据就绪，计算事件确保前一次读取完成后才能覆盖缓冲区。多个请求复用同一组资源。
两种内存策略共用计算接口，但不保证不同 GPU 架构的性能或结果逐位一致。
融合逐元素 kernel 根据张量的形状和步幅选择 32 位或 64 位索引。检查同时覆盖非连续 AdaLN 视图与 FFN/QKV 打包输入，它们实际访问的范围可能超过逻辑输出大小。大偏移在乘法之前拓宽，小张量保留 32 位实现；BF16 运算和舍入顺序不变。寻址安全不代表某个请求已通过显存容量或完整链路资格验证。
两张显卡协作
重视一次请求等待时间的 3080 服务，建议先使用双卡 sequence-head。第二张卡由调用方显式选择；单卡会话仍可用，Vflash 不会自行占用其他显卡。
双卡会话管理两个显存缓冲环、两个提交计算的 CPU 线程和一个局部 NCCL 通信组。sequence-head 共享一份主机权重，投影时划分序列行，再交换注意力数据，让每张卡处理所分配注意力头的完整序列。tensor 则加载权重分片，归约各卡的投影结果，包括 LoRA 分支。无需全局 torch.distributed 状态或分布式启动器。
精确 sequence-head 路径使用四个可重叠 collective 分块传输 Q、K、V。直接 Triton 重排按照 normalized tensor 的 stride 读取，并一次写入 destination-major send buffer；返回路径也直接把四个 received buffer 合并为全局 head 顺序。它不改变既有 BF16 数值和 NCCL wire layout，同时去掉 stack、 permute 和 concat 的物化中间张量。该路径已分别在 SM86 与 SM89 上执行，详见 Sol-Engine 对齐。
两种方式都执行完整配置，并以事件保护缓冲区。任一卡失败时会中止另一卡。分片改变浮点归约顺序，因此双卡结果不一定与单卡逐位相同；已测范围见性能测量。
0.4.0 仅将同一套 block-ring sequence-head 实现扩展到两张匹配的 SM89 48 GB 显卡上的 Base16 I2VA/L2VA/FL2VA。其他 SM89 profile 和 tensor 会被拒绝，调用方仍必须显式选择两张卡。这是范围有限的低延迟选项，不是自动调度或默认吞吐策略；有两个就绪请求时，两个独立 worker 仍更合适。
优化准入
Vflash 把保持语义的布局/生命周期优化与近似模型执行分开。精确优化必须保持所选 profile 的 attention、 精度、schedule 和 BF16 舍入合同；即便如此，仍需目标硬件和完整请求验证，单个更快的 microkernel 不足以晋级。
近似 attention、跨步 cache、量化通信和低精度线性计算必须使用新的显式 profile。在每种受支持架构上的 解码视频/音频、稳定性、延迟与回滚全部通过前，它们保持默认关闭。不同 GPU 或步数下的上游结果只能形成 实验假设，不能成为本项目资格证据。
LoRA 属于运行配置
已发布的 Turbo 配置保留基础权重之外原有的低秩残差计算。编译后的 LoRA 和调度在会话期间固定；切换需要兼容的资源和新会话，不能绕过校验逐请求替换。
精确注意力描述的是实现方式，不代表蒸馏 Turbo 配置等同基础模型的画质。最终结果应对照任务与参考素材评估，张量相似度不能代替成片质量。