AIBrix v0.8.0：引入实验性 ModelClaim，闲置模型共享 GPU 内存

休眠引擎的预留空间

控制器负责模型放置，并设定 KV 缓存上限。用于复用先前 Token 信息的 KV 缓存由 kvcached 管理，它会灵活调节引擎之间的可用空间。

休眠模型默认保留全部预留空间，以确保有足够空间重新唤醒。开启 noWakeReserveWhileAsleep 后，其他模型也可以使用这部分预留空间。

让出预留空间后，恢复流程会有所不同。系统可能需要先让同一资源池中的其他闲置模型休眠，在另一个 Pod 中加载新引擎，或等待空间释放。

39 个模型驻留与并发处理的区别

项目报告称，在配备 8 块 NVIDIA H20 GPU 的节点上驻留了 39 个模型，参数规模为 15 亿至 320 亿。其中，处于休眠状态的 80 亿参数模型仍占用 1.7–3.2 GiB GPU 内存。

对比基准是仅加载该模型权重所需的约 15 GiB。因此，这组数据展示的是休眠模型的驻留成本，而不是在维持相同吞吐量的情况下同时运行更多模型的结果。

同一份报告称，每块 GPU 约有 5 个模型驻留，其中约 3 个同时处于唤醒状态。报告还介绍了收到请求后约 4 秒恢复服务的案例，但前提是 GPU 上有空闲空间。

测试范围

项目的驻留测试报告没有提供完整的请求构成、测试时长、服务目标或失败率对比。仅凭驻留模型数量，很难判断实际运行负载下的处理性能。

当前指南明确列出的测试范围是 vLLM、H20，以及在单个 Pod 内将模型分布到 1 块或 2 块 GPU 上的张量并行配置。节点配备 8 块 GPU，并不意味着已经验证了单个模型的 8 GPU 并行运行。

张量并行度大于 2、每个 Pod 超过 2 块 GPU，以及其他 GPU 型号均未经测试。按模型层划分的流水线并行也未经测试，而通过副本分担请求的数据并行则不受支持。一个 ModelClaim 运行一个引擎。

内存管理责任

根据当前指南，GPU 放置决策依赖运维人员声明的 perGPU.maximumFootprint 和 perGPU.kvFloor。控制器不会测量模型的实际占用量，kvcached 限制的也仅是 KV 缓存。如果申报的占用量偏低，可能导致 GPU 内存不足。

主机 RAM 是另一个问题。1 级休眠会将权重从 GPU 移至主机 RAM，但控制器在做放置或休眠决策时不会计入这部分用量。因此，无论是否将 GPU 预留空间让给其他模型，休眠模型增多都可能导致节点 RAM 不足。

运行时与访问控制

当前指南公开的运行时基于 vLLM，仅提供 linux/amd64 版本。这些构建产物从 main 分发，不包含在 AIBrix 发布版本中。SGLang 需要用户自行提供镜像，且未经测试。

指南说明，运行时代理的 8080 端口没有身份验证，引擎的 20000–20999 端口用于接受休眠与恢复控制。指南建议限制对这些控制通道的网络访问。

分别记录首个请求与就绪时间

在自己的环境中，可以先检查 noWakeReserveWhileAsleep 设置，确认是否保留休眠模型的预留空间，再一并记录首个请求的时间、HTTP 状态和 Retry-After 值。

随后观察 ModelClaim 的就绪状态，记录确认其就绪的时间，并单独记录客户端的重试时间和结果。分开记录后，就能区分请求收到的状态、服务器的重试提示、实际就绪时间与客户端等待时间。