WebSocket实现实时预览Sonic生成进度？前端可实现
在短视频创作与虚拟主播日益普及的今天，用户不再满足于“上传音频、等待几分钟、下载结果”这种黑盒式的AI视频生成流程。他们更希望看到正在发生什么——嘴型对得准不准？表情自然吗？头部会不会被裁掉？这些问题如果能在生成过程中得到即时反馈，将极大提升信任感和交互体验。
这正是WebSocket的价值所在。当我们将它与像Sonic这样的轻量级数字人生成模型结合，就能构建出一个真正“看得见”的AIGC系统：不仅推送进度条，还能实时回传中间帧画面，让用户边看边等，甚至决定是否继续。
Sonic是由腾讯联合浙江大学推出的一种端到端语音驱动口型同步模型，其最大特点在于仅需一张静态人脸图 + 一段音频，即可生成唇形高度对齐的说话视频。相比传统依赖3D建模或多人视角输入的方法，Sonic大幅降低了使用门槛，同时保持了出色的视觉自然性。
它的技术路径走的是“三段式”流水线：
- 音频编码：通过Wav2Vec 2.0这类预训练模型提取语音中的时序特征；
- 面部运动建模：利用时空注意力机制预测每一帧中面部关键点的变化，尤其是嘴部区域的开合节奏；
- 图像渲染：借助GAN或扩散模型将关键点序列转化为连续高保真视频帧。
整个过程无需显式姿态估计或三维重建，参数量控制在100M以内，在RTX 3060级别显卡上能实现接近实时的推理速度（约25 FPS）。更重要的是，它支持多分辨率输出，并已接入ComfyUI生态，可通过节点化方式灵活集成风格迁移、背景融合等功能。
但再快的模型也逃不过“长任务”的本质问题——一段30秒的视频可能需要数秒到十几秒来生成。在这段时间里，如果前端没有任何反馈，用户体验就会迅速滑向焦虑：“是不是卡住了？”、“服务器崩了吗？”、“我已经提交三次了……”
这时候，HTTP轮询已经显得笨重且低效。每秒发起一次请求查询状态，既浪费资源又难以保证及时性。而WebSocket提供了一种更优雅的解法：建立一次连接后，服务端可以主动“喊话”，把每一个进展都第一时间告诉前端。
设想这样一个场景：用户上传完图片和音频，点击“开始生成”。页面立刻弹出一个预览窗口和进度条。不到半秒，第一帧模糊的画面出现了；随后每过200毫秒，新的中间帧刷新一次，嘴型逐渐清晰起来。进度条稳步前进，旁边还显示着“预计剩余时间：4.7秒”。这一切的背后，就是WebSocket在默默工作。
从协议角度看，WebSocket的核心优势是全双工、低延迟、持久连接。客户端和服务端一旦握手成功（基于HTTP Upgrade机制），就可以自由地互相发送消息，不再受限于“请求-响应”模式。这意味着服务端可以在任何时刻推送数据——比如Sonic每完成5帧合成，就立即封装一条JSON消息发给前端。
下面是一个典型的实现结构：
from fastapi import FastAPI, WebSocket import asyncio from PIL import Image import io import base64 app = FastAPI() @app.websocket("/ws/generate") async def websocket_generate(websocket: WebSocket): await websocket.accept() total_frames = 150 for frame_idx in range(total_frames): await asyncio.sleep(0.1) # 模拟处理耗时 # 生成示例图像（实际应来自模型缓存） img = Image.new('RGB', (640, 640), color=(73, 109, 137)) buf = io.BytesIO() img.save(buf, format='JPEG', quality=60) jpeg_data = buf.getvalue() frame_b64 = base64.b64encode(jpeg_data).decode('utf-8') message = { "progress": int((frame_idx + 1) / total_frames * 100), "current_frame": frame_idx + 1, "total_frames": total_frames, "preview": f"data:image/jpeg;base64,{frame_b64}" } await websocket.send_json(message) await websocket.send_json({ "status": "completed", "video_url": "/outputs/sonic_output.mp4" })这段代码用FastAPI搭建了一个WebSocket路由。每当有前端连接进来，它就模拟Sonic逐帧生成的过程，并将每一阶段的状态打包为JSON发送出去。其中preview字段携带的是Base64编码的JPEG缩略图，可以直接赋值给HTML的<img>标签进行展示。
对应的前端逻辑也非常简洁：
<script> const ws = new WebSocket("ws://localhost:8000/ws/generate"); ws.onmessage = function(event) { const data = JSON.parse(event.data); if (data.progress !== undefined) { document.getElementById("progress-bar").style.width = data.progress + "%"; document.getElementById("progress-text").textContent = `生成中... ${data.progress}%`; } if (data.preview) { document.getElementById("preview-frame").src = data.preview; } if (data.status === "completed") { const link = document.createElement("a"); link.href = data.video_url; link.textContent = "点击下载生成视频"; link.target = "_blank"; document.body.appendChild(link); } }; </script> <div class="progress-container"> <div id="progress-bar" style="width:0%; background:green; height:20px;"></div> <span id="progress-text">等待连接...</span> </div> <img id="preview-frame" alt="实时预览" style="max-width:400px;" />前端只需监听onmessage事件，解析不同类型的推送内容，动态更新UI元素即可。整个过程无需刷新页面，也没有定时轮询带来的延迟和负载压力。
当然，在真实生产环境中还需要考虑更多工程细节：
推送频率要合理。不是每帧都推——那样会压垮网络和浏览器渲染。建议每5~10帧或每200ms推送一次，既能保证流畅感知，又不会造成性能瓶颈。
预览图必须压缩。中间帧不需要高清画质，缩放到320×320、JPEG质量设为60%左右，单帧体积可控制在20KB以内，显著降低带宽消耗。
错误处理不可少。网络中断、服务重启都可能导致连接断开。前端应监听
onerror和onclose，并提供一键重连或状态恢复机制。并发控制要到位。多个用户同时生成任务时，GPU资源容易争抢导致OOM。推荐引入Redis+Celery的任务队列系统，实现异步调度与优先级管理。
安全防护不能忽视。必须校验Origin来源、限制单IP连接数、对敏感操作做身份认证，防止恶意连接拖垮服务。
这套架构的实际价值远不止“让进度可见”。它打开了通向交互式生成的大门。试想未来某天，用户在预览中发现表情太僵硬，可以直接滑动调节dynamic_scale参数；或者发现头部偏移过多，点击“重新居中”按钮，指令通过WebSocket反向传回服务端，模型即时调整后续帧的生成逻辑——这才是真正的“所见即所得”创作体验。
目前已有部分SaaS化的数字人平台开始尝试类似设计。尤其是在虚拟客服、在线教育等领域，客户对生成效率和可控性的要求越来越高。谁能率先做到“透明化+可干预”，谁就能在产品体验上拉开差距。
值得一提的是，这种模式也为自动化质量监控提供了可能。例如，服务端可以在生成过程中计算每一帧的唇形误差评分、头部稳定性指数等指标，并随状态一并推送。一旦发现异常趋势（如连续多帧对齐偏差超过阈值），系统可自动触发告警或启用备用策略，从而提升整体输出的可靠性。
把AI生成变成一场“直播”，而不是一封“待查收的邮件”，这是当前AIGC产品演进的重要方向之一。Sonic本身的技术先进性固然重要，但真正打动用户的，往往是那些细腻的交互瞬间：当你看到自己的虚拟形象第一次张嘴说话，哪怕只是模糊的一帧，那种期待感也是无可替代的。
而WebSocket所做的，就是守护这份期待——不让它消失在漫长的等待里。
