[None][feat] VisualGen: async mp4 encode + fixed noise latent via env vars#15229
Conversation
|
@chang-l for review as well. |
📝 WalkthroughWalkthroughThe PR modifies the synchronous video-generation endpoint to conditionally offload the blocking ffmpeg encode step ( ChangesAsync Video Encoding
🎯 3 (Moderate) | ⏱️ ~15 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@zhenhuaw-me for fixed_latent from env variable change. |
…LM_VIDEO_ASYNC_ENCODE) Set TRTLLM_VIDEO_ASYNC_ENCODE=1 to offload the blocking ffmpeg mp4 encode to a thread-pool executor via run_in_executor, freeing the asyncio event loop to begin the next request's diffusion while the current video encodes. Without this, the encode (CPU libx264, ~1.7 s/video on GB300) serialises on the event loop and holds the server idle between generation and the next accept. With async offload, generation and encode overlap when >=2 requests are in flight per server, recovering the full encode latency from the cycle time. Default path (env var unset) is unchanged. Signed-off-by: Tin-Yin Lai <tinyinl@nvidia.com>
b901311 to
019f9d4
Compare
…ED_LATENT_PATH When TRTLLM_VIDEO_FIXED_LATENT_PATH points to a .pt file containing a pre-sampled noise tensor, WanPipeline loads it once at startup and reuses it across all T2V requests instead of sampling fresh random latents. Enables fully reproducible video generation for benchmarking (e.g. MLPerf Wan2.2-T2V-A14B offline scenario, where a fixed latent is required for consistent VBench accuracy evaluation across runs). I2V requests are unaffected (fixed latent is T2V-only). Signed-off-by: Tin-Yin Lai <tinyinl@nvidia.com>
019f9d4 to
0b77cff
Compare
|
/bot run --disable-fail-fast |
|
PR_Github #54724 [ run ] triggered by Bot. Commit: |
|
PR_Github #54724 [ run ] completed with state
|
…_ENCODE=0 to opt out Change the default from opt-in (TRTLLM_VIDEO_ASYNC_ENCODE=1 to enable) to opt-out (TRTLLM_VIDEO_ASYNC_ENCODE=0 to fall back to sync). Async offload via run_in_executor is now always active unless explicitly disabled. Signed-off-by: Tin-Yin Lai <tinyinl@nvidia.com>
|
/bot run --disable-fail-fast |
|
PR_Github #54901 [ run ] triggered by Bot. Commit: |
|
PR_Github #54901 [ run ] completed with state |
|
@chang-l can you help me merge this PR. I don't have permission. Thanks |
… vars (NVIDIA#15229) Signed-off-by: GitLab CI Bot <gitlab-ci@nvidia.com>
… vars (NVIDIA#15229) Signed-off-by: GitLab CI Bot <gitlab-ci@nvidia.com>
Summary
Video generation responses currently block the async server coroutine on
output.save()(libx264 mp4 encode, ~1.7 s/video) before the next requestcan start. This adds an opt-in to offload the encode to a thread-pool executor,
so the server can begin GPU generation for the next request while the previous
video is being encoded.
Change:
TRTLLM_VIDEO_ASYNC_ENCODE=1env var switchesoutput.save()torun via
asyncio.get_running_loop().run_in_executor(None, ...), making theawait non-blocking to the event loop.
Motivation
On GB300, each mp4 encode takes ~1.7 s (CPU libx264; no hardware encoder on
datacenter Blackwell). With the default synchronous path, this sits on the
critical cycle path — generation is idle during encode. With async overlap and
≥2 concurrent requests in flight, encode is fully hidden: measured +0.5%
end-to-end QPS at 4 GPUs in MLPerf Wan2.2-T2V-A14B offline scenario.
The flag is off by default (
"0"), so existing behavior is unchanged.Testing
TRTLLM_VIDEO_ASYNC_ENCODE=1: 0.0368 QPS (+0.5%)Summary by CodeRabbit
Release Notes