配置表越短，越容易显得可靠：某开关设 True，显存利用率调到 0.95，并发拉到 1024。问题是这些字段属于哪个引擎版本、哪个后端、哪个模型？若参数根本不存在，或者只在特定 Attention 路径生效，后面的收益数字没有意义。
SGLang 10 月 19 日的 v0.5.22 发布记录列出了具体改动与提交；Google 10 月 20 日的 TPU 后端发布也说明了不同硬件与模型的支持范围。SGLang 发布记录、Google 官方发布
固定四份身份
至少保存模型修订、引擎版本或提交、后端与精度。还应保留启动命令、运行日志、分词器和适配器。版本号后面加一个“+”不足以形成可复现环境；它可能横跨多个行为变化。
下面只检查一份自定义实验清单是否完整，并比较两个清单的变化。它不会认证任何真实模型可在某个引擎运行。
import re REQUIRED = ("model_revision", "engine_version", "backend", "dtype") def validate(record): missing = [k for k in REQUIRED if not record.get(k)] if missing: raise ValueError("missing: " + ",".join(missing)) if not re.fullmatch(r"\d+\.\d+\.\d+", record["engine_version"]): raise ValueError("pin an exact version in this example") return {k: record[k] for k in REQUIRED} a = validate({"model_revision":"demo@abc", "engine_version":"1.2.3", "backend":"cpu-demo", "dtype":"fp16"}) b = validate(dict(a, dtype="bf16")) changed = [k for k in REQUIRED if a[k] != b[k]] assert changed == ["dtype"] try: validate(dict(a, engine_version="1.2.x+")) except ValueError: pass else: raise AssertionError("unpinned version accepted") print("changed:", changed)示例版本 1.2.3 与 cpu-demo 都是人工标签，不是 vLLM 或 SGLang 的推荐版本。真实项目可能用 Git SHA、预发布标签或带构建信息的版本，届时应改为对应的解析规则，不能把这个简单正则当作通用软件版本标准。
兼容、容量、速度分三步
先确认功能是否支持，再确认模型与缓存能否放下，最后测目标负载下的延迟与吞吐。提高显存预分配比例会减少余量；增加并行度又会增加通信。一个配置在小上下文上启动成功，不代表超长输入或量化路径没有问题。
vLLM 的调优文档说明抢占与 Token/序列预算有关，并讨论并行度的资源权衡。官方文档 调参应当一次改变一个主要因素，保留基线和失败日志，而不是同时打开十个开关后只看最终图表。
| 阶段 | 所需证据 |
|---|---|
| 兼容性 | 官方支持范围、参数解析与启动日志 |
| 正确性 | 固定输入与参考输出比较 |
| 容量 | 真实分配量、余量与抢占计数 |
| 性能 | 相同工作负载和完整成功率 |
本例只验证清单规则，未加载 MLA 模型、未运行后端或启动命令。没有确切版本与模型身份的“生产推荐值”，应当被当作待验证假设，而不是直接进入配置仓库。
