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