Adapter代码、运行进程、权重配方分层；与worker统一调度，避免每个排队任务预占PPU。

处理结果：管理接口r167已上；Public60k原生加载缩容r174已测，其他配方保留未验收。

下一步：暂无

现在我们评测的一系列调度主要都还是在评测卡做，但其实 ppu 侧无论是加载模型还是释放也都应该放在一个维护的流程中。我们想一想这里的设计吧。 我理解如果是那些 adapter 支持的权重，其实机制应该就是我们在开启任务的时候提供权重路径（对于那些我们自己要部署的权重而言，提供已部署端口的就不需要考虑），然后评测系统自己完成权重的加载。当评测完成也自动释放。这里的意义在于我们未来可能会有非常多排队任务，不可能为每个排队任务都分 ppu 提前加载好。那这肯定就依赖我们系统完成评测侧 & 推理侧资源的统一管理调度。

但我想要让模型这边也和评测卡一样是渐进释放的，比如说上一个评测分配了 8 张评测卡，到了最后几个任务只有 4 张评测卡在消费，那这时候对应推理卡也应该释放 4 张，这样就可以并行完成下一个任务的加载和执行了。

另外一个比较关键的就是我们得知道如何启动一个权重，这些东西应该是排队时就能准备好的（也应该规范化的？）。现在我们能做到吗

或者说，adapter & worker 某种意义上是两个对称的概念，adapter 用于让模型权重变成接口，worker 让评测环境变成接口。但这里的主要差异就是 adapter 是经常变化的（换模型权重），worker 相对稳定。但按理说它们都是被一个统一的评测服务管理的子服务？

对，这里，Worker 本身也是对环境的一个加载嘛，就是它其实都涉及了两个概念，一种概念 Adapter 是这个代码，然后另一种 Adapter 的概念其实是这个代码对应的一个真实运行进程。 然后我们按这种架构要不实现一轮看看。