1. 项目概述当Kubernetes遇上GPU我们为何需要AICR在AI基础设施领域混迹了十几年我见过太多团队在构建GPU加速的Kubernetes集群时从踌躇满志到焦头烂额的转变。问题往往不是出在模型本身而是底层那套看似标准、实则暗藏玄机的“环境配置”。你精心调优的PyTorch训练任务在开发环境的单卡DGX上跑得飞快一旦部署到生产环境的A100/H100集群就可能因为一个内核版本不匹配、一个GPU驱动的小版本差异或者容器运行时的一个微妙配置导致性能骤降甚至直接崩溃。更头疼的是这种问题极难复现和排查因为“环境”本身就是一个由云厂商、操作系统、Kubernetes发行版、各类Operator和驱动程序交织成的复杂矩阵。这就是NVIDIA推出AI Cluster RuntimeAICR的核心动因。它不是一个全新的Kubernetes发行版也不是一个集群管理工具。你可以把它理解为一个“经验固化器”和“配置保险箱”。AICR的核心工作是将NVIDIA及其生态伙伴在无数内部验证和客户实践中积累下来的、针对特定硬件、云环境、操作系统和工作负载类型的“已知最佳配置组合”打包成一个个版本锁定的、可复现的“配方”。这个配方在AICR的术语里叫做Recipe。它本质上是一份声明式的配置清单详细规定了在你的目标环境比如Azure AKS Ubuntu H100 训练意图下每一个组件GPU Operator, Network Operator, 监控栈等应该使用哪个确切的版本以及应该如何配置。对于平台工程师和SRE来说AICR的价值在于将集群配置从一门“艺术”和“玄学”变成了可管理、可验证、可复现的“工程”。你再也不需要去记忆“H100在Ubuntu 22.04上到底该用CUDA 12.4还是12.5对应的驱动版本又是什么GPU Operator的哪个Helm Chart版本能兼容这个组合”。AICR的Recipe库已经帮你完成了所有这些兼容性测试和验证。你只需要告诉AICR你的目标是什么它就会给你一个经过验证的、可以直接部署的答案。2. AICR核心架构与工作原理拆解要真正用好AICR不能只停留在命令行操作层面必须理解其背后的设计哲学和数据流。这能帮助你在遇到问题时快速定位甚至根据需要扩展它的能力。2.1 核心概念Recipe、Overlay与BundleAICR的整个体系建立在几个核心抽象之上理解它们就理解了AICR的工作流。Recipe配方这是AICR输出的核心产物。一个Recipe不是一个简单的YAML文件而是一个结构化的、版本锁定的配置描述。它定义了在满足一组特定约束条件如serviceaks,acceleratorh100,osubuntu,intenttraining下整个软件栈应该如何构成。这包括了每个组件的名称、仓库、版本、以及针对该特定环境的定制化配置值。Recipe本身是不可直接部署的它是“部署什么”和“如何配置”的蓝图。Overlay覆盖层这是构建Recipe的“乐高积木”。AICR采用了一种分层配置模型。想象一下最底层是一个所有GPU环境通用的“基础默认”配置。然后针对不同的云服务商如AWS、Azure、GCP会叠加一层“云特定”的配置覆盖可能调整存储类、网络插件设置。接着再叠加“加速器特定”如H100 vs A100的覆盖层优化驱动参数和拓扑感知。之后是“操作系统特定”Ubuntu vs RHEL的覆盖最后是“工作负载意图”训练 vs 推理的覆盖后者可能会调整GPU Operator的配置以启用MIG多实例GPU或调整RDMA设置。AICR的引擎会根据你提供的目标维度自动将这些Overlay按正确顺序组合、合并最终生成一个完整的、针对性的Recipe。这种设计保证了配置的模块化和可复用性。Bundle捆绑包这是Recipe的“可部署物”形态。当你运行aicr bundle命令时AICR的“打包器”会将抽象的Recipe具体化为Recipe中定义的每一个组件生成一个独立的、可直接用于部署的文件夹。通常每个组件对应一个Helm Chart。这个文件夹里会包含一个精确指向特定版本Chart的Chart.yaml一个包含了所有针对该环境优化后的配置值的values.yaml以及该Chart的校验和用于供应链安全。最终bundles/目录下的内容才是你可以直接用helm install命令部署或者提交到GitOps仓库如Argo CD的Application源的最终物料。2.2 工作流全景从环境捕获到部署验证AICR倡导一个完整、闭环的配置管理生命周期。下图展示了其端到端的工作流环境捕获Snapshot这是起点。通过aicr snapshot命令或部署Snapshot Agent收集你现有集群的实时状态。这包括Kubernetes版本、节点操作系统、GPU型号、已安装的驱动和Operator版本等。生成的snapshot.yaml是你环境的“体检报告”。配方生成Recipe Generation基于你的目标需求例如我要在Azure AKS上为H100 GPU搭建一个Kubeflow训练平台使用aicr recipe命令查询AICR的中央Recipe库。AICR引擎会根据你提供的维度service, accelerator, os, intent, platform匹配并组合相应的Overlay生成一个针对性的recipe.yaml。配置查询与验证Query Validate在生成或获得Recipe后你可以使用aicr query来提取其中某个具体的配置值例如GPU Operator里驱动的确切版本号。更重要的是在部署前使用aicr validate命令将目标Recipe与你当前集群的Snapshot进行对比。这个“预检”可以提前发现环境不匹配的问题比如当前集群的内核版本过低无法支持Recipe中指定的新驱动。物料打包Bundle验证通过后使用aicr bundle将Recipe渲染成可部署的Helm Chart bundles。这是将抽象配置转化为具体部署文件的关键一步。部署与后验证Deploy Post-Validation使用你熟悉的工具Helm, Kustomize, Argo CD部署这些bundles。部署完成后可以再次运行aicr validate --phase all进行更全面的验证包括部署完整性检查、基本的性能基准测试和Kubernetes一致性检查并生成一份详细的报告report.json。这个闭环流程确保了从配置定义到部署上线的整个过程都是可预测、可验证的。2.3 组件生态与支持矩阵AICR不是一个封闭系统它的价值随着其支持的组件和环境的丰富度而提升。从官方文档看其支持矩阵正在快速扩张Kubernetes服务目前主要支持主流云托管服务Amazon EKS Azure AKS 1.34 Google GKE以及用于开发的本地环境如Kind。对于OpenShift、Rancher RKE2或纯裸金属部署社区贡献正在路上。GPU硬件重点支持最新的数据中心级GPU如H100和GB200。对于更广泛的A100、V100等卡的支持通常可以通过选择相近的“加速器类型”或由更通用的Recipe覆盖。操作系统Ubuntu是当前的一等公民这是AI工作负载最流行的宿主OS。其他如Red Hat Enterprise Linux (RHEL) 等企业级OS的支持是明确的路线图项目。工作负载与平台明确区分了“训练”和“推理”两种意图这会导致底层配置的显著不同例如训练更关注All-Reduce通信优化推理更关注多实例和批处理。同时也集成了像Kubeflow这样的MLOps平台和NVIDIA自家的推理服务框架的配置。注意AICR的组件目录是一个动态增长的列表。如果你需要的某个特定CNCF项目或监控栈比如希望集成VictoriaMetrics而非Prometheus尚未被支持最有效的方式不是等待而是去GitHub仓库提交Issue。NVIDIA团队明确表示社区的反馈会直接决定下一个被验证和集成的组件是什么。3. 实战从零开始使用AICR配置一个生产级GPU集群理论说得再多不如亲手操作一遍。下面我将以“在Azure AKS上部署一个用于Kubeflow训练任务的H100集群”为例带你走完AICR的全流程。我会假设你已有基本的Kubernetes和Helm操作经验。3.1 环境准备与AICR CLI安装首先你需要一个目标Kubernetes集群。这里我们在Azure上快速创建一个AKS集群作为实验环境。同时我们需要在本地或跳板机上安装AICR命令行工具。# 1. 创建AKS集群示例请根据你的Azure配置调整资源组、区域和规模 az group create --name myAICRResourceGroup --location eastus az aks create \ --resource-group myAICRResourceGroup \ --name myAICRCluster \ --node-count 3 \ --node-vm-size Standard_NC24ads_A100_v4 \ # 此处仅为示例实际请选择H100 SKU如Standard_ND96amsr_A100_v4 --enable-addons monitoring \ --generate-ssh-keys # 获取集群凭证 az aks get-credentials --resource-group myAICRResourceGroup --name myAICRCluster # 2. 安装AICR CLI # 方法一使用安装脚本最简单 curl -sfL https://raw.githubusercontent.com/NVIDIA/aicr/main/install | bash -s -- # 脚本会将 aicr 安装到 /usr/local/bin 或 ~/.aicr/bin并提示你添加路径。 # 方法二使用HomebrewmacOS/Linux brew tap NVIDIA/aicr brew install aicr # 验证安装 aicr version安装完成后aicr命令应该就可以使用了。如果遇到命令未找到请根据安装脚本的输出提示将AICR的二进制目录添加到你的PATH环境变量中。3.2 生成环境快照与目标配方在改造或新建集群前我们先捕获当前集群的状态并生成我们期望的目标配方。# 3. 捕获当前集群快照 # 这会收集节点信息、已安装的CRD、Operator等输出到 snapshot.yaml aicr snapshot --output snapshot-current.yaml # 查看快照内容了解当前环境 cat snapshot-current.yaml | head -50 # 4. 生成目标配方 # 我们的目标Azure AKS, H100 GPU, Ubuntu系统用于训练集成Kubeflow平台 aicr recipe \ --service aks \ --accelerator h100 \ --os ubuntu \ --intent training \ --platform kubeflow \ -o recipe-target.yaml # 查看生成的配方里面锁定了所有组件的版本和配置 cat recipe-target.yaml | yq eval .components[] | .name : .version - # 需要 yq 工具 # 或者简单查看结构 head -100 recipe-target.yaml关键解读生成的recipe-target.yaml文件是核心。它里面不会有具体的镜像URL或Chart仓库密码但它会精确指定例如gpu-operator的Chart版本是v23.9.0并且其values中driver.version会被设置为535.154.05。这一切都是AICR后台经过验证的组合。3.3 配方验证与配置查询在部署前进行验证是避免后续踩坑的关键步骤。同时我们可能需要提取配方中的某些具体值用于其他自动化脚本或文档。# 5. 验证目标配方与当前集群的兼容性 # 这一步会检查内核版本、K8s版本等基础条件是否满足配方要求 aicr validate --recipe recipe-target.yaml --snapshot snapshot-current.yaml --output validation-report.json # 查看验证报告如果存在错误ERROR或警告WARNING需要先解决 cat validation-report.json | jq .summary # 需要 jq 工具 # 6. 查询配方中的具体配置值 # 例如我们想知道这个配方为GPU Operator指定的驱动版本号是多少 aicr query \ --service aks \ --accelerator h100 \ --os ubuntu \ --intent training \ --selector components.gpu-operator.values.driver.version # 输出可能类似于535.154.05 # 再比如查询为这个环境推荐的Kubernetes版本范围 aicr query ... --selector requirements.kubernetes.version实操心得aicr validate的预检功能非常实用。我曾经遇到一个情况Recipe要求Linux内核5.15以支持某新特性但生产集群的节点镜像还停留在5.4。这个命令在部署前就发出了警告让我们有时间先规划节点镜像升级避免了部署中途失败导致的混乱。3.4 渲染部署包与实际部署验证通过后我们就可以将配方“编译”成可部署的实际物料了。# 7. 渲染配方为可部署的Helm Chart包 aicr bundle --recipe recipe-target.yaml --output ./aicr-bundles # 查看生成的目录结构 tree ./aicr-bundles -L 2 # 你会看到类似这样的结构 # ./aicr-bundles/ # ├── gpu-operator # │ ├── Chart.yaml # │ ├── values.yaml # │ └── README.md # ├── nvidia-network-operator # │ ├── Chart.yaml # │ ├── values.yaml # │ └── README.md # └── bundle.yaml # 总体描述文件 # 8. 使用Helm进行部署以GPU Operator为例 # 首先添加NVIDIA Helm仓库如果尚未添加 helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update # 切换到组件目录使用AICR生成的values.yaml进行安装 cd ./aicr-bundles/gpu-operator helm install --wait --create-namespace -n gpu-operator gpu-operator nvidia/gpu-operator -f values.yaml # 或者你也可以使用Helm的--dry-run先模拟一下检查渲染后的资源 helm install --dry-run --debug ... -f values.yaml # 9. 部署其他组件 # 同理进入其他组件的目录如nvidia-network-operator, cert-manager等进行安装。 # 对于复杂的多组件部署建议使用Argo CD等GitOps工具来管理。注意事项aicr bundle生成的values.yaml是已经根据你的特定环境AKSH100训练优化过的。切勿直接使用该组件的默认values.yaml否则会丢失AICR提供的针对性调优。例如针对H100训练优化的GPU Operator配置可能已经设置了正确的MIG策略、GPU时钟频率和RDMA相关参数。3.5 部署后验证与监控部署完成后我们还需要确认一切是否按配方正确运行。# 10. 运行全面的部署后验证 # 这会检查Pod状态、运行一些基础的功能和性能测试 aicr validate --recipe recipe-target.yaml --phase all --output post-deployment-report.json # 检查关键组件状态 kubectl get pods -n gpu-operator kubectl get nodes -o custom-columnsNAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu # 应该能看到GPU资源被成功上报 # 11. 运行一个简单的GPU测试任务 cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: gpu-test-pod spec: restartPolicy: OnFailure containers: - name: cuda-vector-add image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.4.0 resources: limits: nvidia.com/gpu: 1 EOF kubectl logs gpu-test-pod # 如果看到 Test PASSED 字样说明GPU驱动和容器运行时配置成功。至此你已经使用AICR完成了一个从配置定义到部署验证的完整闭环。整个过程中你无需纠结于各个组件之间繁琐的版本兼容性问题AICR已经为你提供了经过验证的“黄金配置”。4. 高级应用与集成模式掌握了基础操作后我们可以看看如何将AICR集成到企业级的CI/CD和GitOps流水线中实现真正的“基础设施即代码”和“配置即数据”。4.1 集成Argo CD实现GitOps这是最经典的集成模式。AICR生成的bundles/目录天生适合作为Argo CD的Application源。准备Git仓库创建一个专门的Git仓库如gitops-infra-config用于存放AICR生成的bundle。自动化生成与推送在你的CI流水线如Jenkins、GitLab CI、GitHub Actions中在需要更新集群配置时例如升级GPU驱动版本调用AICR CLI生成新的bundle。# GitHub Actions 示例片段 - name: Generate AICR Bundle run: | aicr recipe ... -o recipe.yaml aicr bundle --recipe recipe.yaml --output ./bundles - name: Commit and Push run: | git config user.email cicompany.com git config user.name CI Bot git add ./bundles/ git commit -m chore: update AICR bundle for H100 training git push配置Argo CD Application在Argo CD中为每个逻辑组件或整个bundle目录创建一个Application指向上述Git仓库中的对应路径。# argocd-app-of-apps.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: gpu-operator namespace: argocd spec: project: default source: repoURL: https://github.com/your-org/gitops-infra-config.git targetRevision: HEAD path: bundles/gpu-operator # 指向AICR生成的特定组件目录 helm: valueFiles: - values.yaml # 直接使用AICR生成的values文件 destination: server: https://kubernetes.default.svc namespace: gpu-operator syncPolicy: automated: prune: true selfHeal: true同步与回滚当Git仓库中的bundle更新后Argo CD会自动同步变更到集群。如果出现问题你可以轻松地回滚到Git历史中的任何一个已知良好的bundle版本实现了配置变更的可追溯和可回滚。4.2 使用API Server (aicrd) 进行集中式管理对于拥有多个团队、多个集群的大型组织在每个CI Runner或开发者机器上安装和管理CLI并不方便。AICR提供了API Server模式。部署aicrd你可以将aicrd作为容器部署在你的内部Kubernetes集群中。# 从官方Release页面获取部署清单或使用Helm kubectl apply -f https://github.com/NVIDIA/aicr/releases/latest/download/aicrd-kubernetes.yaml内部服务暴露通过Ingress或LoadBalancer将aicrd服务暴露给内部网络。团队自助服务开发者和平台团队可以通过调用REST API来生成和验证配方而无需本地安装CLI。这可以与内部门户网站或ChatOps工具如Slack机器人集成。# 示例通过curl调用API生成配方 curl -X POST https://aicrd.internal.company.com/v1/recipe \ -H Content-Type: application/json \ -d { service: aks, accelerator: h100, os: ubuntu, intent: training } recipe.json4.3 供应链安全与合规性检查AICR在设计之初就融入了软件供应链安全的最佳实践这对于满足企业安全合规要求至关重要。SBOM软件物料清单每个AICR的Release都附带有签名的SBOM文件如SPDX格式。你可以使用工具解析这些SBOM快速识别所有包含的软件组件及其许可证用于安全审计和许可证合规检查。镜像签名与验证CosignAICR Recipe中引用的容器镜像很多都支持使用Cosign进行签名。你可以在部署流水线中集成验证步骤确保只拉取和运行经过签名的、可信的镜像。# 示例在CI中验证镜像签名 cosign verify --key cosign.pub nvcr.io/nvidia/gpu-operator:v23.9.0校验和验证aicr bundle生成的每个Helm Chart都带有校验和。在部署时Helm可以验证这些校验和确保Chart内容在传输和存储过程中没有被篡改。SLSA ProvenanceAICR项目自身遵循SLSA Level 3标准为构建产物提供来源证明。这意味着你可以确信你下载的aicr二进制文件确实是由NVIDIA的官方构建流程产生的而非被恶意篡改的版本。将这些安全特性集成到你的部署流水线中能显著提升整个AI基础设施供应链的安全性。5. 故障排查与经验实录即使有了AICR这样的“最佳实践集”在实际部署和运维中仍然会遇到问题。下面分享几个我遇到过的典型场景和排查思路。5.1 常见问题速查表问题现象可能原因排查步骤与解决方案aicr validate失败提示内核版本不兼容目标Recipe要求的Linux内核版本高于集群节点当前内核。1. 运行uname -r在节点上检查内核版本。2. 查看Recipe中的requirements.kernel.version字段。3. 升级节点操作系统镜像或选择更低内核要求的Recipe变体如果存在。GPU Operator Pod 一直处于ContainerCreating或Init:Error通常与驱动、容器运行时或内核模块相关。1.kubectl describe pod gpu-operator-pod -n gpu-operator查看具体事件。2. 检查节点dmesg日志看是否有NVRM或nvidia相关错误。3.重点检查确认AICR Recipe生成的values.yaml中driver.repository和driver.imageTag是否与你的容器运行时如containerd的配置匹配特别是镜像仓库地址和拉取凭证。节点kubectl describe node看不到nvidia.com/gpu资源GPU设备插件未成功注册。1. 确认nvidia-device-pluginDaemonSet的Pod是否在所有GPU节点上运行正常。2. 检查节点上/var/log/nvidia-driver-installer.log日志。3. 运行nvidia-smi在节点上手动测试驱动是否正常。如果正常则问题可能出在设备插件与Kubelet的通信上。使用AICR Bundle部署后Pod无法调度到GPU节点节点Selector、Taint/Toleration或资源请求不匹配。1. 检查Pod的resources.limits是否包含nvidia.com/gpu: 数量。2. 检查GPU节点是否有污点Taint如nvidia.com/gputrue:NoSchedule你的Pod需要对应的容忍Toleration。AICR的Recipe通常会为GPU Operator设置这些但你的工作负载Pod需要声明容忍。aicr recipe命令找不到指定维度的配方你请求的维度组合如servicebaremetal,osrhel尚未被AICR官方库支持。1. 运行aicr recipe --list-dimensions查看当前支持的所有维度选项。2. 考虑使用最接近的已知维度如将baremetal替换为self-managed。3. 前往GitHub Issues提交功能请求这是推动支持新环境的最有效方式。5.2 深度排查GPU节点“就绪”但Pod无法使用GPU这是一个非常典型的问题。从集群层面看节点状态是Readykubectl describe node也显示了nvidia.com/gpu: 8的容量。但一旦部署训练任务Pod要么调度失败要么Pod启动后报CUDA初始化错误。我的排查心路历程第一层检查最明显的。确认Pod的YAML里正确设置了resources.limits.nvidia.com/gpu。确认节点没有满负荷。这些都没问题。第二层深入节点内部。SSH到GPU节点运行nvidia-smi。正常。运行docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果使用Docker。也正常。这说明驱动和容器运行时的基础层是好的。第三层聚焦Kubernetes集成。问题很可能出在nvidia-container-toolkit与containerd的集成上。检查/etc/containerd/config.tomlsudo cat /etc/containerd/config.toml | grep -A5 -B5 nvidia我发现配置中引用了nvidia-container-runtime但路径不对。这是因为AICR Recipe或GPU Operator在部署时会尝试自动配置containerd。但在某些自定义的AKS或自建集群上containerd的配置文件可能被云提供商或初始化脚本修改过导致自动配置未能完全生效或产生冲突。解决方案方案A推荐让AICR/GPU Operator强制接管。在GPU Operator的values.yaml中即AICR bundle生成的那个确保operator.defaultRuntime设置为containerd并且toolkit相关的配置正确。然后彻底重启containerd服务和GPU Operator的所有Pod。有时需要重启整个节点才能使配置完全生效。方案B手动修正如果自动配置始终失败可以手动修正containerd配置然后创建一个DaemonSet来确保所有节点配置一致。但这违背了使用AICR实现自动化的初衷应作为临时补救措施。经验总结GPU在Kubernetes中的集成问题十有八九出在容器运行时这一层。AICR虽然提供了正确的配置蓝图但在复杂的生产环境中原有的系统状态可能会干扰部署。养成一个习惯在部署AICR Bundle后不仅用kubectl检查Pod状态还要到一两个样本节点上用crictl对应containerd或docker命令以非Kubernetes的方式验证GPU容器是否能运行。这是隔离问题域的关键。5.3 性能调优从“能用”到“好用”AICR确保了组件的兼容性和基本功能但对于追求极致性能的训练场景可能还需要一些“锦上添花”的手动调优。这些通常不会写在Recipe里因为它们高度依赖于具体的工作负载和硬件。GPU Direct RDMA如果你的集群配备了InfiniBand或RoCE网卡并计划进行多节点训练启用GPUDirect RDMA能大幅降低跨节点GPU通信的延迟和CPU开销。这需要在AICR Recipe的基础上额外确保nvidia-network-operator被正确部署和配置。节点安装了正确的OFED驱动。Pod的securityContext中需要添加capabilities: add: [“IPC_LOCK”]并设置privileged: true或更细粒度的权限。注意这有安全风险需评估。在训练框架如PyTorch中设置正确的通信后端如NCCL_IB_DISABLE0。持久化GPU时钟与内存频率为了获得稳定的高性能尤其是在推理服务中可能需要将GPU锁定在最高的P-State性能状态。这可以通过在GPU Operator的values.yaml中配置devicePlugin部分的configuration来实现或者使用nvidia-smi在节点启动脚本中设置。但要注意功耗和散热。MIG多实例GPU配置对于A100/H100等支持MIG的GPUAICR Recipe可以根据intent为你设置一个合理的默认MIG策略例如训练用全卡推理用MIG分区。但如果你需要更精细的划分如将一块H100切成7个1g.10gb实例你需要深入研究GPU Operator中关于MIG的配置并可能需要在Recipe生成后手动调整values.yaml。重要提示任何对AICR生成的标准配置的修改都会使你偏离“已验证”的状态。在进行任何性能调优前务必做好基准测试和记录并意识到这可能会引入新的不稳定性。理想的做法是将你的调优参数反馈给AICR社区也许它能成为下一个“已验证”配方的一部分。AICR的出现标志着AI基础设施管理正在从“手工匠人”时代走向“标准化工程”时代。它并不能解决所有问题但它将最棘手、最耗时的底层环境兼容性问题封装成了一个可靠的、可编程的接口。对于运维和平台团队而言这意味着可以将精力从无穷尽的兼容性矩阵中解放出来更多地投入到提升资源利用率、优化工作流和保障服务稳定性这些更高价值的事情上。从我个人的使用体验来看初期学习和集成需要一些投入但一旦跑通它在提升部署成功率、加速环境交付和保障多环境一致性方面带来的回报是巨大的。尤其是在面对频繁的驱动升级、Kubernetes版本迭代和混合云场景时AICR这种“配方化”的管理思想显得尤为珍贵。