
显存压力刚过阈值就砍并发,稍一回落又全放开,下一轮又打满。控制器看似一直在工作,系统却被它推着振荡。指标有噪声、上报有延迟,推理任务结束也不是开关一关就立刻释放全部资源。
平滑和迟滞负责不同问题
平滑减少单次采样的影响;迟滞让收紧和恢复使用不同阈值。二者都不能替代静态硬上限。若指标断连,控制器还要进入保守策略,不能把缺失值填成零后宣布“负载很低”。HPA 文档中的周期控制和稳定处理,也说明扩缩决策需要考虑观测与执行之间的时间差。

public class Demo {
static class Controller {
double ewma = 0.5;
boolean tight;
void sample(double pressure) {
if (!Double.isFinite(pressure) || pressure < 0 || pressure > 1) {
throw new IllegalArgumentException("invalid sample");
}
ewma = 0.5 * pressure + 0.5 * ewma;
if (!tight && ewma >= 0.8) tight = true;
else if (tight && ewma <= 0.3) tight = false;
}
int limit() { return tight ? 4 : 8; }
}
public static void main(String[] args) {
Controller c = new Controller();
c.sample(1); if (c.tight) throw new AssertionError("single spike switched");
c.sample(1); if (!c.tight || c.limit() != 4) throw new AssertionError();
c.sample(0); if (!c.tight) throw new AssertionError("recovered too soon");
c.sample(0); if (c.tight || c.limit() != 8) throw new AssertionError();
double before = c.ewma;
boolean rejected = false;
try { c.sample(Double.NaN); }
catch (IllegalArgumentException expected) { rejected = true; }
if (!rejected || c.ewma != before) throw new AssertionError();
System.out.println("smoothing, hysteresis and invalid-sample rejection checked");
}
}
保存为 Demo.java,执行 javac --release 11 Demo.java、java Demo。0.8、0.3、4 和 8 都是方便观察的教学参数,没有来自 GPU 压测。它只是模式控制器,不是已经接入令牌桶的完整限流器。
降低上限不会瞬间撤销在途请求
并发上限从 8 变成 4 时,如果已有 7 个任务运行,应阻止新增,等待自然下降,而不是把许可计数重置成 4 再多放四个。排队任务还要有截止时间和明确失败出口,不能把所有压力都藏进无限队列。
验证时至少覆盖尖峰、持续高压、回落、缺失采样、过期采样和执行延迟。记录每次调整的输入、模式和实际接纳量,避免只看到限流率却不知道为什么限。本文未连接推理引擎或 GPU,没有证明任何吞吐与延迟收益;离线检查确认的是控制规则不会在一次高低采样之间立刻来回翻转。
本地运行环境为 Java/javac 12.0.1,使用 --release 11 编译并执行了文中的检查;没有安装新依赖。该结果只覆盖示例列出的逻辑,不代表真实模型、浏览器或生产链路已经验证。
博客探讨了在GPU推理场景下自适应反压控制器因指标噪声与延迟导致的振荡问题,提出引入迟滞机制(不同收紧/恢复阈值)与平滑处理(如指数加权移动平均)协同解决。强调并发上限调整不可撤销在途请求,需配合排队截止机制;指出静态硬上限不可替代,且控制器须对采样缺失、过期、执行延迟等异常具备保守应对能力。

435

被折叠的 条评论
为什么被折叠?



