SGLang 从 0.2 升级到 0.3 后出现内存增长，往往不是模型本身变大，而是框架默认行为改变。升级后首先要做的不是调小最大请求长度，而是确认 `--chunked-prefill` 参数在当前版本中到底默认是开启还是关闭，以及实际请求是否显式传入了这个参数。
升级后内存增长，优先排查 chunked-prefill 默认值变化。通过启动参数 `--help` 和运行日志确认生效值，用控制变量法显式设置该参数对比显存变化。若显存回落，再微调 chunk 大小；若未见回落，需要同时检查并发、context 长度和 KV cache 分配策略，并做回归验证。
先确认当前版本的实际默认值
不要依赖升级前记录的启动命令，因为 0.3 可能改变了 `--chunked-prefill` 的默认值。先查看当前版本支持该参数的类型和默认值：
python -m sglang.launch_server `--help` 2>&1 | grep -i chunk如果命令不是这样启动，换成你的实际启动入口。输出里会显示参数默认值，例如 default=...。如果输出里没有这个参数，说明该版本可能改名或合并进其它配置，需要再查其它相关参数，比如 chunk size 或 prefill 相关项。同时，查看服务启动日志，有些版本会打印关键配置。也可以使用 ps 命令查看实际跑起来的进程参数，确认是否有显式指定：
ps aux | grep sglang注意：如果启动脚本里写了旧值，那么升级后的行为其实是显式值决定的，与默认值变化无关。这种情况下要回到启动脚本检查。
用控制变量验证 chunked-prefill 的影响
确认默认值后，建议用相同模型、相同请求集和相同并发数，做一次 A/B 对比。不要同时调整多个参数。先记录当前显存峰值和稳态值，然后显式设置 `--chunked-prefill` 为 true 或 false 各跑一轮。
- 当前显式值：如果启动命令里已写明，先按原值测试；
- 分别测试 true 和 false 两种状态，观察显存曲线；
- 如果其中一种状态使显存回落，并接近升级前的水平，那基本可以判断是默认值变化导致；
- 如果两种状态下显存都继续增长，说明问题来自其它环节。
监控建议用 nvidia-smi 定时采集显存，并记录请求结束后显存是否释放。SGLang 的日志里也有显存分配信息，可以对照。
按需调整 chunk 大小
如果确定显式开启或关闭 `--chunked-prefill` 能让行为回到预期，那就把它固定在启动参数中。之后如果需要进一步控制峰值，再调整 chunk 大小参数。具体参数名在不同版本里可能不同，需要以 `--help` 输出为准，常见的可能是 `--chunked-prefill-size`、`--max-prefill-chunk-size` 等。
调整原则：chunk 越小，prefill 峰值显存越低，但计算调度次数变多，可能影响吞吐；chunk 越大，效果越不明显。建议先取默认值附近的一到两个档位测试，观察显存和延迟的变化。不要一开始就把 chunk 压到很小。
还要排查其它升级影响面
不要只盯着 `--chunked-prefill`。SGLang 升级时，KV cache 分配策略、显存比例配置（如 `--mem-fraction-static`）、radix cache 行为、甚至默认的最大 batch 都可能变化。如果显式设置 chunked-prefill 后显存没有回落，用下面的清单继续排查：
- 对比升级前后的启动脚本，列出所有未显式指定的参数；
- 检查请求的 context 长度和生成长度分布，是否有比升级前更长的请求；
- 确认并发数没有增加，压测脚本是否跟随重启而变化；
- 查看服务启动时打印的显存分配信息，例如 KV cache 总量、静态内存占比；
- 尝试把 `--mem-fraction-static` 等显存相关参数调低一小段，观察是否缓解。
每一步都要有监控前后对比，不能凭感觉。调参后如果显存恢复到可接受范围，还需要跑一轮回归请求确认服务稳定。
常见问题
chunked-prefill 为什么会影响内存？
chunked-prefill 一般会把较长的 prefill 阶段拆成多段，让显存消耗更平滑，降低峰值。默认值改变后，如果从开启变成关闭，大 prompt 第一次计算时可能一次性申请较多显存，从而出现可观察到的内存增长。
升级后什么都没改，为什么默认值会变？
主版本升级时，为了整体调度效率或兼容新功能，框架维护者会调整默认配置。这类变更通常不是 bug，调整启动参数即可恢复符合自身环境的设置。建议后续升级前先查看 changelog 或 `--help` 中的默认值变化。