AI 推論系統
GCache Allocates Diffusion Caching Based on End-to-End Error Impact, Cutting Wan2.1 LPIPS to 0.0316 at the Same Speed
GCache no longer decides whether to recompute based on local similarity between adjacent denoising steps. Instead, it searches for a cache-reuse schedule with the lowest impact on final image quality. On Wan2.1, it substantially reduces deviation while maintaining a 2.17× speedup, but policy search requires multiple H100 GPUs and the implementation has not yet been released.
The GCache study submitted on August 13 reframes diffusion-model caching from step-by-step threshold decisions into a global scheduling problem. Methods such as TeaCache and ERTACache typically compare features or residuals between adjacent denoising steps and then decide whether previous computations can be reused. The authors argue that the same local error can propagate to the final image with different magnitudes depending on when it occurs, so the position that appears “most similar right now” is not necessarily the safest place for reuse.
GCache first derives an upper bound on error accumulation along the denoising trajectory, then learns propagation weights using a Bernstein formulation. An inner dynamic-programming loop selects cache refresh points under a fixed recomputation budget K, while an outer Bayesian optimization loop aligns the weighted-error proxy with the actual loss in generation quality. Once the policy has been computed, inference only needs to reuse residuals according to a fixed schedule, without adding an extra error-estimation network.
The study covers Open-Sora 1.2, CogVideoX-2B, Wan2.1-1.3B, and FLUX.1-dev. The main latency tests use a single A800 80GB GPU and report averages across five random seeds. In Wan2.1’s 81-frame, 480p setting, GCache completes generation in 91.6 seconds, delivering a 2.17× speedup over the full 50-step inference process. Compared with ERTACache at the same speedup, it reduces LPIPS from 0.1095 to 0.0316. A more aggressive configuration reaches a 3.01× speedup, but LPIPS rises to 0.0828. FLUX.1-dev records an LPIPS of 0.1825 at a 2.87× speedup.
This is not a free, general-purpose runtime optimization: a policy must first be searched for each backbone and compute budget. For Wan2.1, the search takes approximately 13.5 to 17.5 hours on eight H100 GPUs. The method also uses a fixed refresh budget and a precomputed error proxy, without adapting at runtime to individual prompts or highly dynamic trajectories. Neither the code nor the policy files have been released, so its engineering value still depends on whether the results can be reproduced across different schedulers, quantized variants, and new resolutions.