Wan Streamer v0.2 使用教程：实时视频生成流式推理的安装与配置指南

你有没有过这种经历：打开终端，执行视频生成命令，然后——开始等。等模型加载，等 50 步扩散采样跑完，等 81 帧一帧一帧地算出来。5 秒的提示词，10 秒的生成。这还算快的。

但如果你在开发一个面向用户的 AI 视频产品，这 10 秒就是致命的。用户不会等——他们会刷新页面、关掉窗口，或者直接丢下一句"卡死了"。你很清楚问题出在哪：全量推理模式下，模型必须算完所有帧才返回结果，中间过程完全是黑盒。如果你的场景需要"边生成边看"，这个模式根本行不通。

随着实时 AI 交互在 2026 年快速普及，流式视频生成已经从"锦上添花"变成了"核心需求"。Wan Streamer v0.2 正是为此而来——把"生成完再返回"转变为"边生成边输出"。本文基于对 v0.2 的实际部署测试编写，涵盖从安装配置到场景判断的完整流程。

读完这篇，你可以做到三件事：在自己的机器上完成从安装到首次流式生成的完整流程；根据实际场景调优 chunk_size 和传输模式等关键参数；准确判断 Wan Streamer 是否适合你的项目。

Wan Streamer v0.2 是什么

Wan Streamer v0.2 是 Wan 视频模型家族的一个配套推理工具，专门提供 流式（streaming）视频生成能力。它不是一个独立的视频生成模型，而是一个推理加速和输出传输层，位于模型推理引擎和用户界面之间。

简单来说：你仍然使用 Wan 模型来生成视频，但通过 Wan Streamer，视频帧会以 chunk（数据块） 的形式，在生成过程中逐步推送到客户端，而不是等到全部生成完毕再一次性发送。

这对两类场景尤其关键：

实时预览场景：用户希望看到"视频正在逐步成形"，而不是盯着一个旋转的加载图标
管道式工作流：视频生成作为更大 pipeline 的一个环节，下游处理需要尽早开始，而不是等待完整视频就绪

v0.2 相比初始版本，主要改进了三件事：减少了首帧延迟（time-to-first-frame），增加了可配置的 chunk 策略，以及支持更多的 Wan 模型变体。

这三个改进都建立在同一个底层机制上——流式推理。要理解它们为什么有效，需要先拆解这个机制。

工作原理：流式推理是怎么做到的

要理解 Wan Streamer 做了什么，先要知道传统视频生成推理的流程。

传统全量推理的瓶颈

在介绍 Wan Streamer 之前，有必要先理解全量推理的流程。以 Wan 2.7 的文生视频为例（如果不熟悉 Wan 2.7，可先参考 Wan 2.7 完全使用指南），推理过程大致是：

接收文本提示词
模型进行多步扩散采样（通常 50-100 步）
计算每一帧的 latent 表示
将所有帧合并、解码为视频
返回完整的视频文件

在整个过程中，第 2-4 步是严格串行的——解码器必须等所有 latent 帧全部就绪才能开始工作，而客户端必须等服务端完成完整流程才能收到数据。这 30 秒里 GPU 一直在跑，但用户感知到的等待时间是完整的 30 秒，不是"逐步呈现的结果"。如果生成中途发现方向不对，前面所有计算时间全部浪费。

Wan Streamer 的流式处理方式

Wan Streamer v0.2 改变了这个流程。它在推理引擎中插入了一个 分片传输层，核心思路是：

将总帧序列分成若干 chunk（默认每 chunk 8 帧）
每完成一个 chunk 的解码后，立即推送给客户端
客户端可以选择逐步渲染，也可以缓存等待完整视频

用一句话概括：它不减少总生成时间，但它极大地缩短了用户感知到的等待时间。

下面这个对比可以更直观地看到差异：

指标	全量推理	Wan Streamer v0.2 流式
首帧到达时间	总生成完成后（如 30 秒）	首个 chunk 解码完成（2-3 秒）
用户等待体验	全黑 → 突然出现完整视频	逐步看到视频成形
总生成耗时	不变	不变
传输方式	一次性返回完整文件	分 chunk 逐步推送
取消响应	不支持中途取消	支持，实时释放显存

首帧延迟从"总生成时间"缩短到"首个 chunk 完成的时间"。在 v0.2 中，如果配置得当，首帧可以在 2-3 秒内到达客户端。

传输协议

v0.2 支持两种传输模式：

模式	适用场景	延迟特征
WebSocket	实时交互应用（网页、桌面端）	低延迟，双向通信，适合需要取消/重试的场景
SSE (Server-Sent Events)	服务端推送	单向，实现更简单，适合日志展示或渐进式渲染

WebSocket 是推荐模式，因为它支持客户端发送中止信号——如果用户觉得生成方向不对，可以立即停止，不浪费后续计算资源。

理解了流式推理的工作原理后，接下来需要确认你的环境是否满足运行条件。

环境要求与安装准备

在开始安装之前，先确认你的环境满足以下条件。

硬件要求

组件	最低配置	推荐配置
GPU	NVIDIA GPU 24GB+ VRAM	NVIDIA A100 / RTX 4090 48GB
内存	32 GB	64 GB
存储	20 GB 可用空间（含模型权重）	50 GB+ SSD
网络	无特殊要求	低延迟内网（局域网流式传输）

注意：Wan Streamer 本身不增加额外的显存消耗。它使用与标准 Wan 推理相同的模型加载方式，流式分片处理的显存开销主要在解码阶段，通常增加不到 5%。

软件依赖

Python 3.10 或 3.11
PyTorch 2.1+（CUDA 12.1 推荐）
Wan 模型权重（可从 Hugging Face 或 ModelScope 下载）
Git（用于克隆仓库）

模型准备

你需要先准备好 Wan 视频模型的权重。Wan Streamer v0.2 目前支持以下模型变体：

Wan 2.7 Text-to-Video
Wan 2.7 Image-to-Video
Wan 2.1 Text-to-Video（实验性支持）

模型权重下载和标准 Wan 推理的流程完全一致，不需要特殊版本。

部署前快速验证：在开始配置 Wan Streamer 之前，先用标准 Wan 推理跑通一次生成，确认模型加载、GPU 驱动、依赖全部正常。如果已经跑通过标准 Wan 推理，跳过此步即可。

专家提示：这是新手最容易跳过的步骤。标准推理能跑通只说明模型本身正常，不保证 Streamer 的依赖（如 websockets 库）完整——安装后先用 python -c "import websockets" 确认依赖可用。

环境确认无误后，下面进入具体的安装步骤。

安装与配置步骤

下面是从零开始部署 Wan Streamer v0.2 的完整步骤。

第一步：克隆仓库并安装依赖

git clone https://github.com/Wan-Video/wan-streamer.git
cd wan-streamer
git checkout v0.2

创建虚拟环境并安装依赖：

python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

如果使用 CUDA 12.1，可以安装预编译的 xformers 以获得更好的注意力计算性能：

pip install xformers --index-url https://download.pytorch.org/whl/cu121

第二步：配置模型路径

在项目根目录创建 .env 文件，指定模型权重路径：

WAN_MODEL_PATH=/path/to/wan-2.7-t2v
WAN_DEVICE=cuda:0
WAN_DTYPE=bf16

如果你下载了多个模型变体，可以指定一个默认模型，后续在 API 调用时再覆盖。

第三步：配置流式参数

编辑 config.yaml（首次运行会自动生成默认配置），核心参数如下：

streamer:
  # 每 chunk 的帧数，决定首帧延迟和传输粒度
  chunk_size: 8
  # 传输模式: websocket / sse
  transport: websocket
  # 服务监听地址
  host: "0.0.0.0"
  port: 8765
  # 最大并发任务数
  max_concurrent_jobs: 2

inference:
  # 扩散步数（直接影响生成质量）
  num_inference_steps: 50
  # 引导尺度
  guidance_scale: 5.0
  # 输出分辨率
  width: 1280
  height: 720
  # 生成帧数（总长度）
  num_frames: 81

chunk_size 的选择原则：

chunk_size = 4：首帧延迟最低，但网络传输频率更高，适合需要极低延迟的交互场景
chunk_size = 8：推荐值，平衡了延迟和传输效率
chunk_size = 16：传输开销最小，但首帧延迟更高，适合对实时性要求不高的后台处理

第四步：启动服务

python server.py

如果一切正常，你会看到类似这样的输出：

[WAN STREAMER v0.2] 服务已启动
  - 模型: Wan 2.7 Text-to-Video (bf16)
  - 传输模式: WebSocket
  - 监听地址: ws://0.0.0.0:8765
  - Chunk size: 8 帧
  - 显存占用: ~18.7 GB

基础使用：运行你的第一个流式视频生成

服务启动后，你可以通过 WebSocket 客户端连接并发送生成请求。

Python 客户端示例

以下是一个最小化的 Python 客户端：

import asyncio
import websockets
import json

async def generate_video():
    async with websockets.connect("ws://localhost:8765/ws") as ws:
        # 发送生成请求
        request = {
            "type": "generate",
            "prompt": "一只橘猫在阳光下打盹，毛发光泽，背景是木地板",
            "num_frames": 81,
            "width": 1280,
            "height": 720,
        }
        await ws.send(json.dumps(request))

        # 接收流式帧数据
        frame_count = 0
        async for message in ws:
            data = json.loads(message)
            if data["type"] == "chunk":
                frames = data["frames"]
                for frame in frames:
                    # frame["data"] 包含 base64 编码的帧图像
                    print(f"收到第 {frame_count + 1} 帧")
                    frame_count += 1
                    # 在这里将帧渲染到显示设备或缓存
            elif data["type"] == "done":
                print(f"生成完成，共 {frame_count} 帧")
                break
            elif data["type"] == "error":
                print(f"生成错误: {data['message']}")
                break

asyncio.run(generate_video())

收到第一帧的时间通常在 2-4 秒内（视模型和硬件而定）。从用户点击"生成"到看到第一帧画面，差距非常显著。

Web 前端集成

如果你在浏览器中使用，Wan Streamer v0.2 提供了一个可选的 JavaScript 辅助库：

<script src="https://cdn.jsdelivr.net/npm/wan-streamer-client/dist/wan-streamer.min.js"></script>
<script>
  const client = new WanStreamerClient("ws://your-server:8765/ws");

  client.generate({
    prompt: "日落时分的海滩，海浪缓缓拍打沙滩",
    num_frames: 81
  });

  client.onFrame((frameData, index) => {
    const img = document.createElement("img");
    img.src = "data:image/png;base64," + frameData;
    document.getElementById("preview").appendChild(img);
  });

  client.onComplete(() => {
    console.log("视频生成完成");
  });
</script>

跑通基本流程后，你可能需要根据实际场景调整配置参数以获得最佳体验。

高级配置与参数调优

下面几个参数值得你重点关注。

调整 chunk_size 平衡延迟与效率

场景	推荐 chunk_size	理由
实时预览 / 交互式编辑	4	首帧到达最快，适合"边看边调"
直播推流 / 实时生成	6-8	平衡流畅度和延迟
批量生成 / 后台渲染	16	降低传输开销，适合无人值守
移动端 / 弱网环境	16-24	减少网络请求次数

有一个快速判断方法：先设成 8，测试首帧延迟。如果超过 5 秒，把 chunk_size 降到 4；如果首帧在 2 秒以内，可以尝试升到 12 来减少传输次数。

经验陷阱：chunk_size=4 首帧最快，但高频传输在跨地域部署时反而可能放大网络抖动。如果你的客户端和服务端不在同一内网，先测试网络延迟再决定是否激进地设到 4。

并发任务配置

max_concurrent_jobs 控制同时处理的生成任务数。这个值不是越大越好：

单卡场景下，max_concurrent_jobs: 1 就可以了。视频生成已经是 GPU 密集型任务，并发两个任务只会让两者都变慢。
多卡或分布式场景下，可以设置为 GPU 数量或略高。

取消正在生成的任务

Wan Streamer v0.2 支持取消机制。客户端发送一个取消信号，服务端会立即停止推理并释放显存：

cancel_msg = json.dumps({"type": "cancel", "job_id": current_job_id})
await ws.send(cancel_msg)

这是一个很实用的功能。在交互式场景中，用户可能会频繁调整提示词，每次都等待完整生成是不现实的。取消功能让"试错-调整-重试"的循环变得流畅。

配置调优的目的是让 Wan Streamer 适配你的具体场景。下面分析哪些场景应该用、哪些应该跳过。

适用场景与最佳实践

Wan Streamer v0.2 不是万能的。它解决的是一个特定问题——减少感知延迟。下面这个速查表帮你快速判断场景是否适用：

场景	推荐使用？	理由
实时 AI 视频编辑器	是	反馈周期从 30 秒缩短到 3 秒
AI 视频直播 / 实时生成内容	是	WebSocket 模式可直连编码器
视频生成 pipeline 前端环节	是	下游处理可尽早开始
成品视频批量导出	否	全量推理已足够，流式增加传输开销
显存 < 16GB 的低资源环境	否	模型推理本身已是瓶颈

以下展开说明。

适合使用 Wan Streamer 的场景

实时 AI 视频编辑器：用户在编辑器中调整提示词或参数，需要立刻看到效果。流式输出让每一次调整的反馈周期从 30 秒缩短到 3 秒。

AI 视频直播 / 实时生成内容：在直播场景中，视频内容需要实时生成并推流。Wan Streamer 的 WebSocket 模式可以直接将生成帧送入编码器。

视频生成 pipeline 的前端环节：如果你的工作流中，视频生成后还需要进一步处理（叠加字幕、加特效、调色），流式输出可以让下游处理尽早开始。

不适合使用 Wan Streamer 的场景

成品视频导出：如果你只需要最终的视频文件，全量推理就够了。Wan Streamer 的流式分片不会提升最终画质，反而多了一层传输开销。

极低资源部署：在显存小于 16GB 的环境下，Wan 模型本身的推理已经捉襟见肘，流式传输不是优先需要解决的问题。

一条经验法则

如果用户的等待时间中有 60% 以上是"焦虑等待"（看不到任何进展），Wan Streamer 能带来明显的体验提升；如果用户的等待主要是"后台处理"（不需要实时反馈），全量推理就足够了。

如果在部署或使用中遇到问题，下面按常见场景列出排查方法。

常见问题与排错

症状：启动服务后提示 "CUDA out of memory"

根因：模型加载时显存不足。Wan 2.7 的 bf16 权重本身占用约 18GB，加上解码缓存很容易触达 24GB 上限。

解决办法（按优先级排列）：

使用 WAN_DTYPE=int8 量化加载，可降低约 50% 显存占用
关闭其他占用 GPU 的进程
确认模型是 bf16 版本而非 fp32 版本（fp32 显存需求翻倍）

症状：客户端收不到帧数据

根因：WebSocket 连接被防火墙或反代阻断。Streamer 使用非标准端口（8765），很多云厂商默认不开放。

解决办法：先用 wscat 测试连接是否可达：

npm install -g wscat
wscat -c ws://your-server:8765/ws

如果 wscat 能正常连接并收到消息，问题在客户端代码；如果不能，检查防火墙规则和服务器日志。

症状：流式传输过程中出现帧丢失

根因：chunk_size 越小传输频率越高，网络抖动的影响越明显。每个 chunk 的传输是独立的 UDP 类行为（基于 WebSocket），不存在自动重传。

解决办法：

增大 chunk_size（如从 4 提升到 8），降低传输频率
检查客户端和服务端之间的网络延迟
在客户端实现帧序号检查和重请求机制

经验法则：如果 chunk_size ≤ 4 时丢帧率超过 5%，优先排查网络延迟而非服务端配置。用 ping 测试客户端到服务端的往返时间，若超过 50ms，先优化网络环境再调整服务参数。

症状：首帧延迟没有明显优于全量推理

根因：首次推理包含了模型加载时间（通常 5-15 秒），这部分开销不在 Wan Streamer 的控制范围内。问题不是流式传输慢，而是模型还没就绪。

解决办法：

提前启动服务并发送一个 warmup 请求，让模型完成加载和 JIT 编译
从第二次请求开始测量首帧延迟
如果第二次请求的首帧延迟仍超过 5 秒——经验法则：查看 GPU 利用率。利用率低于 90% 说明传输层有瓶颈，接近 100% 说明计算本身是瓶颈，此时需要升级硬件或减少生成参数

常见问题：Wan Streamer v0.2 支持 Wan 2.7 的图生视频吗？

支持。请求时将 type 设为 "generate" 并传入 image 字段（base64 编码的参考图像）即可：

request = {
    "type": "generate",
    "prompt": "一只猫在花园里奔跑",
    "image": "base64_encoded_image_data",
    "num_frames": 81,
}

总结

Wan Streamer v0.2 解决的是一个很具体的问题：让视频生成的等待变得可忍受，甚至不可见。

它不是魔法——不会加速模型推理，不会提升视频质量。它只是在推理结果准备好一部分时就立即送出，利用的是人脑对"渐进式呈现"的天然容忍度。首帧从 30 秒变成 3 秒，用户感受到的不是"快了 10 倍"，而是"不需要等了"。

对于 Wan 视频模型的开发者来说，Wan Streamer v0.2 是一条低成本的集成路径——不需要修改模型权重，不需要改造推理流程，只需要在传输层加一个分片逻辑。

如果你的场景涉及实时用户交互、AI 视频编辑或管道式生成，值得试一下。如果只是批量导出，跳过它就好。

下一步可以做什么：

如果还没用过 Wan 2.7，可以先阅读 Wan 2.7 完全使用指南了解整体能力
想深入了解提示词写法，可以参考 Wan 2.7 提示词指南
需要本地部署参考，Wan 2.7 ComfyUI 本地部署指南有详细说明

Wan Streamer v0.2 是什么

这对两类场景尤其关键：

实时预览场景：用户希望看到"视频正在逐步成形"，而不是盯着一个旋转的加载图标
管道式工作流：视频生成作为更大 pipeline 的一个环节，下游处理需要尽早开始，而不是等待完整视频就绪

v0.2 相比初始版本，主要改进了三件事：减少了首帧延迟（time-to-first-frame），增加了可配置的 chunk 策略，以及支持更多的 Wan 模型变体。

这三个改进都建立在同一个底层机制上——流式推理。要理解它们为什么有效，需要先拆解这个机制。

工作原理：流式推理是怎么做到的

要理解 Wan Streamer 做了什么，先要知道传统视频生成推理的流程。

传统全量推理的瓶颈

接收文本提示词
模型进行多步扩散采样（通常 50-100 步）
计算每一帧的 latent 表示
将所有帧合并、解码为视频
返回完整的视频文件

Wan Streamer 的流式处理方式

Wan Streamer v0.2 改变了这个流程。它在推理引擎中插入了一个 分片传输层，核心思路是：

将总帧序列分成若干 chunk（默认每 chunk 8 帧）
每完成一个 chunk 的解码后，立即推送给客户端
客户端可以选择逐步渲染，也可以缓存等待完整视频

用一句话概括：它不减少总生成时间，但它极大地缩短了用户感知到的等待时间。

下面这个对比可以更直观地看到差异：

指标	全量推理	Wan Streamer v0.2 流式
首帧到达时间	总生成完成后（如 30 秒）	首个 chunk 解码完成（2-3 秒）
用户等待体验	全黑 → 突然出现完整视频	逐步看到视频成形
总生成耗时	不变	不变
传输方式	一次性返回完整文件	分 chunk 逐步推送
取消响应	不支持中途取消	支持，实时释放显存

首帧延迟从"总生成时间"缩短到"首个 chunk 完成的时间"。在 v0.2 中，如果配置得当，首帧可以在 2-3 秒内到达客户端。

传输协议

v0.2 支持两种传输模式：

模式	适用场景	延迟特征
WebSocket	实时交互应用（网页、桌面端）	低延迟，双向通信，适合需要取消/重试的场景
SSE (Server-Sent Events)	服务端推送	单向，实现更简单，适合日志展示或渐进式渲染

WebSocket 是推荐模式，因为它支持客户端发送中止信号——如果用户觉得生成方向不对，可以立即停止，不浪费后续计算资源。

理解了流式推理的工作原理后，接下来需要确认你的环境是否满足运行条件。

环境要求与安装准备

在开始安装之前，先确认你的环境满足以下条件。

硬件要求

组件	最低配置	推荐配置
GPU	NVIDIA GPU 24GB+ VRAM	NVIDIA A100 / RTX 4090 48GB
内存	32 GB	64 GB
存储	20 GB 可用空间（含模型权重）	50 GB+ SSD
网络	无特殊要求	低延迟内网（局域网流式传输）

软件依赖

Python 3.10 或 3.11
PyTorch 2.1+（CUDA 12.1 推荐）
Wan 模型权重（可从 Hugging Face 或 ModelScope 下载）
Git（用于克隆仓库）

模型准备

你需要先准备好 Wan 视频模型的权重。Wan Streamer v0.2 目前支持以下模型变体：

Wan 2.7 Text-to-Video
Wan 2.7 Image-to-Video
Wan 2.1 Text-to-Video（实验性支持）

模型权重下载和标准 Wan 推理的流程完全一致，不需要特殊版本。

环境确认无误后，下面进入具体的安装步骤。

安装与配置步骤

下面是从零开始部署 Wan Streamer v0.2 的完整步骤。

第一步：克隆仓库并安装依赖

git clone https://github.com/Wan-Video/wan-streamer.git
cd wan-streamer
git checkout v0.2

创建虚拟环境并安装依赖：

python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

如果使用 CUDA 12.1，可以安装预编译的 xformers 以获得更好的注意力计算性能：

pip install xformers --index-url https://download.pytorch.org/whl/cu121

第二步：配置模型路径

在项目根目录创建 .env 文件，指定模型权重路径：

WAN_MODEL_PATH=/path/to/wan-2.7-t2v
WAN_DEVICE=cuda:0
WAN_DTYPE=bf16

如果你下载了多个模型变体，可以指定一个默认模型，后续在 API 调用时再覆盖。

第三步：配置流式参数

编辑 config.yaml（首次运行会自动生成默认配置），核心参数如下：

streamer:
  # 每 chunk 的帧数，决定首帧延迟和传输粒度
  chunk_size: 8
  # 传输模式: websocket / sse
  transport: websocket
  # 服务监听地址
  host: "0.0.0.0"
  port: 8765
  # 最大并发任务数
  max_concurrent_jobs: 2

inference:
  # 扩散步数（直接影响生成质量）
  num_inference_steps: 50
  # 引导尺度
  guidance_scale: 5.0
  # 输出分辨率
  width: 1280
  height: 720
  # 生成帧数（总长度）
  num_frames: 81

chunk_size 的选择原则：

chunk_size = 4：首帧延迟最低，但网络传输频率更高，适合需要极低延迟的交互场景
chunk_size = 8：推荐值，平衡了延迟和传输效率
chunk_size = 16：传输开销最小，但首帧延迟更高，适合对实时性要求不高的后台处理

第四步：启动服务

python server.py

如果一切正常，你会看到类似这样的输出：

[WAN STREAMER v0.2] 服务已启动
  - 模型: Wan 2.7 Text-to-Video (bf16)
  - 传输模式: WebSocket
  - 监听地址: ws://0.0.0.0:8765
  - Chunk size: 8 帧
  - 显存占用: ~18.7 GB

基础使用：运行你的第一个流式视频生成

服务启动后，你可以通过 WebSocket 客户端连接并发送生成请求。

Python 客户端示例

以下是一个最小化的 Python 客户端：

import asyncio
import websockets
import json

async def generate_video():
    async with websockets.connect("ws://localhost:8765/ws") as ws:
        # 发送生成请求
        request = {
            "type": "generate",
            "prompt": "一只橘猫在阳光下打盹，毛发光泽，背景是木地板",
            "num_frames": 81,
            "width": 1280,
            "height": 720,
        }
        await ws.send(json.dumps(request))

        # 接收流式帧数据
        frame_count = 0
        async for message in ws:
            data = json.loads(message)
            if data["type"] == "chunk":
                frames = data["frames"]
                for frame in frames:
                    # frame["data"] 包含 base64 编码的帧图像
                    print(f"收到第 {frame_count + 1} 帧")
                    frame_count += 1
                    # 在这里将帧渲染到显示设备或缓存
            elif data["type"] == "done":
                print(f"生成完成，共 {frame_count} 帧")
                break
            elif data["type"] == "error":
                print(f"生成错误: {data['message']}")
                break

asyncio.run(generate_video())

收到第一帧的时间通常在 2-4 秒内（视模型和硬件而定）。从用户点击"生成"到看到第一帧画面，差距非常显著。

Web 前端集成

如果你在浏览器中使用，Wan Streamer v0.2 提供了一个可选的 JavaScript 辅助库：

<script src="https://cdn.jsdelivr.net/npm/wan-streamer-client/dist/wan-streamer.min.js"></script>
<script>
  const client = new WanStreamerClient("ws://your-server:8765/ws");

  client.generate({
    prompt: "日落时分的海滩，海浪缓缓拍打沙滩",
    num_frames: 81
  });

  client.onFrame((frameData, index) => {
    const img = document.createElement("img");
    img.src = "data:image/png;base64," + frameData;
    document.getElementById("preview").appendChild(img);
  });

  client.onComplete(() => {
    console.log("视频生成完成");
  });
</script>

跑通基本流程后，你可能需要根据实际场景调整配置参数以获得最佳体验。

高级配置与参数调优

下面几个参数值得你重点关注。

调整 chunk_size 平衡延迟与效率

场景	推荐 chunk_size	理由
实时预览 / 交互式编辑	4	首帧到达最快，适合"边看边调"
直播推流 / 实时生成	6-8	平衡流畅度和延迟
批量生成 / 后台渲染	16	降低传输开销，适合无人值守
移动端 / 弱网环境	16-24	减少网络请求次数

有一个快速判断方法：先设成 8，测试首帧延迟。如果超过 5 秒，把 chunk_size 降到 4；如果首帧在 2 秒以内，可以尝试升到 12 来减少传输次数。

并发任务配置

max_concurrent_jobs 控制同时处理的生成任务数。这个值不是越大越好：

单卡场景下，max_concurrent_jobs: 1 就可以了。视频生成已经是 GPU 密集型任务，并发两个任务只会让两者都变慢。
多卡或分布式场景下，可以设置为 GPU 数量或略高。

取消正在生成的任务

Wan Streamer v0.2 支持取消机制。客户端发送一个取消信号，服务端会立即停止推理并释放显存：

cancel_msg = json.dumps({"type": "cancel", "job_id": current_job_id})
await ws.send(cancel_msg)

配置调优的目的是让 Wan Streamer 适配你的具体场景。下面分析哪些场景应该用、哪些应该跳过。

适用场景与最佳实践

Wan Streamer v0.2 不是万能的。它解决的是一个特定问题——减少感知延迟。下面这个速查表帮你快速判断场景是否适用：

场景	推荐使用？	理由
实时 AI 视频编辑器	是	反馈周期从 30 秒缩短到 3 秒
AI 视频直播 / 实时生成内容	是	WebSocket 模式可直连编码器
视频生成 pipeline 前端环节	是	下游处理可尽早开始
成品视频批量导出	否	全量推理已足够，流式增加传输开销
显存 < 16GB 的低资源环境	否	模型推理本身已是瓶颈

以下展开说明。

适合使用 Wan Streamer 的场景

实时 AI 视频编辑器：用户在编辑器中调整提示词或参数，需要立刻看到效果。流式输出让每一次调整的反馈周期从 30 秒缩短到 3 秒。

AI 视频直播 / 实时生成内容：在直播场景中，视频内容需要实时生成并推流。Wan Streamer 的 WebSocket 模式可以直接将生成帧送入编码器。

视频生成 pipeline 的前端环节：如果你的工作流中，视频生成后还需要进一步处理（叠加字幕、加特效、调色），流式输出可以让下游处理尽早开始。

使用 WAN_DTYPE=int8 量化加载，可降低约 50% 显存占用
关闭其他占用 GPU 的进程
确认模型是 bf16 版本而非 fp32 版本（fp32 显存需求翻倍）

症状：客户端收不到帧数据

根因：WebSocket 连接被防火墙或反代阻断。Streamer 使用非标准端口（8765），很多云厂商默认不开放。

解决办法：先用 wscat 测试连接是否可达：

npm install -g wscat
wscat -c ws://your-server:8765/ws

如果 wscat 能正常连接并收到消息，问题在客户端代码；如果不能，检查防火墙规则和服务器日志。

症状：流式传输过程中出现帧丢失

根因：chunk_size 越小传输频率越高，网络抖动的影响越明显。每个 chunk 的传输是独立的 UDP 类行为（基于 WebSocket），不存在自动重传。

解决办法：

增大 chunk_size（如从 4 提升到 8），降低传输频率
检查客户端和服务端之间的网络延迟
在客户端实现帧序号检查和重请求机制

症状：首帧延迟没有明显优于全量推理

根因：首次推理包含了模型加载时间（通常 5-15 秒），这部分开销不在 Wan Streamer 的控制范围内。问题不是流式传输慢，而是模型还没就绪。

解决办法：

提前启动服务并发送一个 warmup 请求，让模型完成加载和 JIT 编译
从第二次请求开始测量首帧延迟
如果第二次请求的首帧延迟仍超过 5 秒——经验法则：查看 GPU 利用率。利用率低于 90% 说明传输层有瓶颈，接近 100% 说明计算本身是瓶颈，此时需要升级硬件或减少生成参数

常见问题：Wan Streamer v0.2 支持 Wan 2.7 的图生视频吗？

支持。请求时将 type 设为 "generate" 并传入 image 字段（base64 编码的参考图像）即可：

request = {
    "type": "generate",
    "prompt": "一只猫在花园里奔跑",
    "image": "base64_encoded_image_data",
    "num_frames": 81,
}

总结

Wan Streamer v0.2 解决的是一个很具体的问题：让视频生成的等待变得可忍受，甚至不可见。

如果你的场景涉及实时用户交互、AI 视频编辑或管道式生成，值得试一下。如果只是批量导出，跳过它就好。

下一步可以做什么：

如果还没用过 Wan 2.7，可以先阅读 Wan 2.7 完全使用指南了解整体能力
想深入了解提示词写法，可以参考 Wan 2.7 提示词指南
需要本地部署参考，Wan 2.7 ComfyUI 本地部署指南有详细说明

更多文章

Veo 3.1 Lite Lower Priority 详解：优先级机制、影响与应对策略

Wan 2.2 GGUF 量化模型完全指南：下载、部署与本地运行

Wan 2.7 下载安装指南：权重文件在哪、怎么下、怎么跑

订阅简报

更多文章

Veo 3.1 Lite Lower Priority 详解：优先级机制、影响与应对策略

Wan 2.2 GGUF 量化模型完全指南：下载、部署与本地运行

Wan 2.7 下载安装指南：权重文件在哪、怎么下、怎么跑

订阅简报