实时生成系统最常见的卡顿并不是平均帧率低，而是帧与帧之间的耗时波动太大。比如每一帧都执行固定20步去噪，简单画面可能12ms完成，复杂画面却要48ms。帧间隔忽高忽低，视觉上就会感到明显的抖动。要解决这个问题，不能只盯着平均帧率，而是要控制每一帧的耗时稳定在目标帧时间附近。

一、抖动来源：固定步数的负载波动

实时生成管线通常把采样步数写死在配置里，例如扩散模型每帧固定执行20步去噪。但画面内容不同，单步耗时并不相同。复杂纹理、高噪声区域、大运动矢量会让模型计算时间显著增加。于是每帧总耗时在12ms到48ms之间摆动。帧间隔一旦超过垂直同步周期，画面就会掉帧。只盯着平均帧率看不出问题，因为平均帧率可能仍保持在30fps左右，但帧时间分布极不均匀，体感卡顿明显。

从公式看，帧耗时约等于单步耗时乘以步数。若步数固定为S，单步耗时t受场景复杂度c影响，则帧耗时T等于S乘以t(c)。当c变化时，T线性变化。若想稳定T，要么让t固定，要么让S随t反向调整。实时场景中很难完全固定t，因此调整S成了更现实的路径。这里的关键是不要让步数阶跃式变化，否则画面质量会忽高忽低，反而产生新的视觉抖动。

另一个容易被忽略的因素是质量档位。不少实时生成管线会预设低、中、高三档，每档对应不同分辨率、CFG强度或模型精度。固定档位时，场景简单会造成算力浪费，场景复杂又可能超时。把步数和质量档位纳入同一个帧时间预算进行联动，可以更平滑地吸收负载波动。

二、自适应步数调度：以帧时间预算为核心

核心思路是维护一个目标帧时间T_target，例如30fps对应33ms。每一帧结束后，记录实际耗时，并计算单步平均耗时。下一帧可用步数由可用预算除以预测单步耗时得到。预测不能只看上一帧，否则容易受到瞬时波动影响。使用滑动窗口保存最近8到12帧耗时，取均值作为预测基础，能有效平滑毛刺。

假设最近10帧平均耗时是40ms，当前步数为20，则单步耗时约2ms。目标帧时间是33ms，可分配步数约为16步。此时应该把下一帧步数降到16。反过来，如果平均耗时只有20ms，单步耗时1ms，则可分配33步，但超过最大步数上限时只取最大步数，避免质量提升超过模型能力上限。

还需要考虑场景复杂度。画面变化剧烈时，下一帧单步耗时往往高于历史均值。可以引入复杂度系数c，由光流幅值、噪声估计或上一帧去噪残差计算得到。最终可用步数等于T_target除以t_avg乘以c的结果，再夹紧到最小步数与最大步数之间。这样在运动场景中会提前减少步数，在静态场景中则保留更多步数提升细节。

import time
from collections import deque
class AdaptiveStepScheduler:
    def __init__(self, min_steps=8, max_steps=30, target_frame_ms=33.0):
        self.min_steps = min_steps
        self.max_steps = max_steps
        self.target_frame_ms = target_frame_ms
        self.history = deque(maxlen=10)
        self.current_quality = 3
        self.keep_frames = 3
        self.frame_counter = 0
    def predict_steps(self, scene_complexity=1.0):
        if len(self.history) == 0:
            return self.max_steps
        avg_cost = sum(self.history) / len(self.history)
        per_step_cost = avg_cost / self.current_quality
        budget_per_step = per_step_cost * scene_complexity
        steps = int(self.target_frame_ms / max(budget_per_step, 1e-6))
        return max(self.min_steps, min(self.max_steps, steps))
    def update(self, actual_cost_ms, scene_complexity=1.0):
        self.history.append(actual_cost_ms)
        avg_cost = sum(self.history) / len(self.history)
        if avg_cost > self.target_frame_ms * 1.2 and self.current_quality > 1:
            if self.frame_counter <= 0:
                self.current_quality -= 1
                self.frame_counter = self.keep_frames
        elif avg_cost < self.target_frame_ms * 0.7 and self.current_quality < 3:
            if self.frame_counter <= 0:
                self.current_quality += 1
                self.frame_counter = self.keep_frames
        if self.frame_counter > 0:
            self.frame_counter -= 1
        return self.predict_steps(scene_complexity), self.current_quality

上面的调度器把质量档位假设为1到3的整数，per_step_cost用avg_cost除以当前质量，这只是近似建模，实际系统中可以由性能剖析器直接给出单步耗时。帧计数器keep_frames用于滞回，避免质量档位在阈值附近来回切换。使用时每帧调用update，把实际耗时传进去，拿到下一帧建议步数和质量档位。

三、质量动态调整与滞回控制

如果每帧都根据耗时调整步数，步数可能频繁变化，造成画面锐度和噪声水平波动。滞回控制的思想是：只有连续若干帧超出预算一定比例时才降低质量，只有连续若干帧低于预算一定比例时才提升质量。通过设置不同阈值，例如超预算15%降档，低于预算25%升档，可以减少来回切换。

质量档位可以和模型分辨率绑定。例如高档使用完整分辨率，中档使用0.75倍分辨率加一次快速上采样，低档使用0.5倍分辨率。也可以切换CFG引导强度、注意力切片大小或latent精度。质量调整的粒度越细，帧率越容易稳定，但也会增加调度复杂度。实践中通常设置3到5档即可。

另一个工程技巧是给质量切换加最小保持帧数，比如切换后至少保持5帧再评估，否则可能在两档之间震荡。画面静态时，调度器会逐步升档；画面突然运动时，先降步数，再降质量档位；如果仍然超时，最后才考虑跳帧。这种分级响应能最大程度保留视觉质量。

// CUDA流式生成中的动态步数与质量联动
int resolve_steps(float frame_budget_ms, float avg_step_ms, int min_steps, int max_steps) {
    int steps = static_cast<int>(frame_budget_ms / avg_step_ms);
    if (steps < min_steps) steps = min_steps;
    if (steps > max_steps) steps = max_steps;
    return steps;
}
void render_frame_async(cudaStream_t stream) {
    float budget = 33.0f;
    float avg_cost = profiler.avg_step_cost_ms();
    int steps = resolve_steps(budget, avg_cost, 8, 30);
    QualityProfile profile = QUALITY_HIGH;
    if (steps < 12) {
        profile = QUALITY_LOW;
    } else if (steps < 20) {
        profile = QUALITY_MEDIUM;
    }
    set_quality_profile(profile);
    diffusion_launch(stream, steps, profile);
    profiler.record_frame_cost();
}

这段伪代码展示了异步推理流中如何把步数解析和质量档位选择放在同一处。真实实现中，profiler.avg_step_cost_ms()可以通过CUDA事件或nsys指标得到，不建议在GPU内核执行期间读取CPU计时器，否则会受到流水线异步影响。步数解析函数里的除法要防止avg_step_ms为0，这里为了简洁省略了保护判断。

四、工程落地与参数整定

参数整定需要先确定目标帧时间和可接受的质量下限。先在目标设备上固定档位跑一段代表性场景，记录单步耗时分布。最小步数通常设置为质量损失的底线，最大步数则可以略高于默认步数，防止低负载时步数无限增加导致边际收益递减。

不同硬件差异很大。在RTX 4090上，同样步数可能只占10ms，而在移动端SoC上可能超过40ms。滑动窗口长度也要根据帧率调整，30fps下窗口设为10帧，60fps下可以设15到20帧。窗口太长响应慢，太短容易受单帧毛刺影响。

最后要评估画面质量。建议对静态、慢速运动、快速运动三类场景分别统计帧时间P95和LPIPS指标。好的调度器应该在快速运动时优先保证帧率稳定，在静态场景中逐步恢复细节。通过把步数和质量解耦再联动，实时生成系统可以在不增加硬件成本的前提下显著降低帧率抖动。