介绍
硬件配置档案可让平台管理员集中预配特定且标准化的硬件配置。这些配置将计算资源限制、节点选择器和节点容忍紧密封装为一个统一单元，平台用户在部署不同的模型推理服务时可轻松选择。
使用硬件配置档案可显著减少通过 YAML 原始配置带来的人工错误，避免工作负载被无意调度到错误的拓扑组，并全面确保集群工作负载的稳健资源管理。
硬件配置档案原生支持并与平台的 InferenceService 和 LLMInferenceService 资源进行紧密交互。
为什么需要硬件配置档案？
虽然标准 Kubernetes 通过 Pod 规范提供了资源请求和限制，但构建和部署 AI 推理工作负载（例如大语言模型或专用 KServe predictor）会带来独特的运维挑战。我们的硬件配置档案实现专门针对这些挑战进行了设计，并具备以下平台特性：
-
拓扑与专用加速器抽象
数据科学家更关注模型性能和逻辑，而不是底层集群拓扑。他们可能并不清楚将工作负载调度到特定 GPU 节点、vGPU 资源或互连网络所需的精确节点标签或污点。硬件配置档案会抽象掉这些技术复杂性。管理员可以将精确的Node Selectors和Tolerations直接嵌入配置档案中，确保用户从 UI 中选择“High-End NVIDIA A100”配置档案时，工作负载会自动指向正确的物理机器池。 -
动态边界化自定义（不只是固定配额）
与那些严格强制单一且不可变资源尺寸（t-shirt sizing）的平台不同，我们的系统为每种资源类型定义了动态、可扩展的边界。管理员配置 最小允许值、默认值 和 最大允许值。当用户选择某个配置档案时，会立即继承 默认 设置。不过，通过 Customize Data 选项，他们仍可灵活地手动微调各自的 Requests 和 Limits。只要这些值落在授权的配置档案边界内，就能通过——在不导致集群被过度占用的情况下，为不同模型提供弹性。 -
智能 Webhook 校验与非对称自动修正
我们的平台采用专用的 Mutating Webhook，与模型服务管道深度集成。Webhook 不再依赖用户精确编写 YAML manifest，而是优雅地拦截请求，并安全地将配置档案的约束注入到工作负载运行时。此外，它还会智能地保护集群——例如，如果用户指定了 limits 但遗漏了 requests（或反之），Webhook 会原生执行智能语义调整（将 requests 限制到 limits，或提升默认值），并在任何 Pod 创建之前，全面阻止违反配置档案定义的最小值或最大值的配置。 -
与自定义服务引擎的原生互操作性
无论部署标准的InferenceService还是高度定制的LLMInferenceService，硬件配置档案引擎都会在后台原生跟踪复杂的 Pod/Container 结构，并精准注入到当前活动的推理容器资源中。
硬件配置档案的关键方面
- 资源标识符（Limits 与 Requests）： 配置档案会安全地管控原生 Kubernetes 资源限制（例如最小 CPU 阈值、默认可用 Memory 分配以及严格的最大 GPU 加速限制），以防止系统过载并保持运行稳定。
- Taints 与 Tolerations： 硬件配置档案会内置地精确告知工作负载 Pod 能够容忍哪些节点污点（例如针对专用异构硬件的 taint）。
- 节点选择器： 它们严格将工作负载约束到特定的节点标签选择器，以匹配正确的机器架构，避免任何隐式推断。
- 后端 Webhook 注入： 通过安装在集群中的自动拦截机制，硬件约束会从管理命名空间透明地合并并附加到已提交的工作负载上。