文章目录
- Cloud Native Computing Foundation 已经把 OpenShell 与 KubeRay 接纳为 Sandbox 项目。两个项目分别覆盖 Agent 行为边界和 Ray 工作负载编排，但是 Sandbox 身份只说明项目进入开放治理起点，Sandbox 身份不等于安全认证或生产成熟度证明。
- NVIDIA Kubernetes Engine 与 NVIDIA Kubernetes Recipes 已经进入 public preview，NVIDIA Snapshot 的启动时间数字来自 NVIDIA 与设计伙伴测试。企业需要把开放源代码、预览状态和特定测试结果分别核验。
- 第六代 AMD EPYC SP7 服务器处理器已经正式可用，而且相关服务器平台已经开始出货。AMD 公布的核心、带宽和 Agent 容量数字仍然依赖具体处理器、内存、软件、编排和整机配置。
OpenShell 把 Agent 行为边界交给开放治理
Cloud Native Computing Foundation 在 11 月 10 日接纳 OpenShell 成为 Sandbox 项目。NVIDIA 把这个用于保护和治理自主 Agent 的开放源代码运行时贡献给基金会，而且 OpenShell 会从 NVIDIA 的 GitHub 组织迁移到中立的 ai-openshell 组织。项目已经采用公开的意见征求流程和明确的供应商中立承诺，而且项目使用 Cedar 作为策略语言。
OpenShell 把策略执行放在 Agent 周围的基础设施中。项目提供计算、推理供应商、凭据存储、隔离、批准流程和可观察性的扩展点，但是基金会材料仍然把一致性测试、真实批准流程、跨平台隔离、安全审查、软件物料清单、签名、持续集成、多租户和身份集成列为需要继续建设的内容。
对企业落地而言，开放治理可以让平台团队检查策略执行代码、参与接口演进并降低单一供应商控制核心运行边界的风险。企业仍然需要在自身环境中验证文件、网络、凭据和模型端点的拒绝规则，而且企业仍然需要验证审计记录、人工批准、故障关闭和升级回退。Sandbox 身份不能替代安全评估、兼容性测试或正式支持合同。
KubeRay 把训练、任务和在线推理放进同一套生命周期
Cloud Native Computing Foundation 在 11 月 10 日宣布 KubeRay 加入基金会。KubeRay 使用 RayCluster 管理 Ray 集群的节点、健康检查、控制服务容错和动态扩缩容；KubeRay 使用 RayJob 为批处理、分布式训练和强化学习临时创建集群并在任务结束后释放集群；KubeRay 使用 RayService 管理长期在线推理、滚动升级、自动故障转移和流量路由。
KubeRay 的官方材料还列出了与 OpenTelemetry、Prometheus、Fluent Bit、Kueue、Volcano 和 KAI 的集成。相关集成覆盖指标、日志、批量调度、多租户配额、优先级抢占和拓扑调度，而且 KubeRay 可以结合自动双向传输层安全协议和 Kubernetes 网络策略保护 Ray 集群。KubeRay 当前进入的是基金会 Sandbox 阶段，而不是更高成熟度阶段。
对企业落地而言，一套公开的生命周期对象可以减少训练、批处理和在线推理各自建设编排接口的重复工作，而且统一对象可以帮助平台团队连接资源配额、日志和发布记录。基金会治理不会自动承担集群升级、模型正确性、数据驻留、故障恢复和服务等级责任。企业需要使用自身工作负载验证 Ray、Kubernetes、调度器、存储和推理服务之间的版本组合。
NVIDIA 把集群管理和恢复组件放进预览与开放源代码阶段
NVIDIA 在 11 月 10 日宣布 NVIDIA Kubernetes Engine、NVIDIA Kubernetes Recipes 和 NVIDIA Snapshot。NVIDIA Kubernetes Engine 与 NVIDIA Kubernetes Recipes 目前处于 public preview，而且两个项目使用开放源代码构件帮助团队管理集群生命周期并使用带签名和固定版本的镜像。NVIDIA Snapshot 则通过恢复已经保存的副本，减少模型重新加载和预热过程。
NVIDIA 与设计伙伴公布了两组 Snapshot 测试。Crusoe 在 NVIDIA HGX B300 系统上测试 GLM-5.3，并且 Crusoe 把工作负载就绪时间从约 8 分钟降到 31 秒；Saturn Cloud 把 vLLM 从零扩展的启动时间从 2 至 8.5 分钟降到 6 至 34 秒。这些数字来自 NVIDIA 与设计伙伴，而且这些数字只覆盖公开材料列出的硬件、模型和启动条件。
对企业落地而言，固定版本镜像和可以复查的恢复组件能够把集群变更与模型副本状态纳入同一条发布记录。public preview 组件可能继续改变接口、支持范围和升级方式，设计伙伴测试也不能替代目标企业对模型字节、缓存状态、存储故障、网络拥塞、恢复一致性和完整费用的验收。企业需要把预览功能与正式生产依赖分开管理。
已经出货的服务器处理器为开放控制面提供计算基础
AMD 在 11 月 10 日宣布第六代 AMD EPYC SP7 服务器处理器正式可用，而且采用这些处理器的平台已经开始由服务器厂商出货。AMD 表示，Microsoft Azure 与 Oracle Cloud Infrastructure 的相关云实例仍将后续提供。AMD 产品页把处理器定位于 Agent 沙箱、图形处理器主机节点和通用服务，而且 AMD 产品页列出了最高 256 个核心、512 个线程、最高 5.3 GHz、每插槽最高 1.6 TB/s 内存带宽和 PCIe Gen 6。
AMD 的性能与 Agent 容量数字来自厂商测试或估算。AMD 产品页明确说明，线程数量只是估算 Agent 容量的代理指标，而且实际容量与工作负载、模型、内存、软件、编排和系统配置有关。公开材料没有提供适用于所有服务器的模型、量化、上下文、批量、首 token 延迟、完整整机功耗、整机价格或统一售后条件。
对企业落地而言，处理器和服务器已经出货是一项可采购状态，但是该状态不能证明具体 Agent 工作负载已经达到所需的并发、延迟或成本目标。企业需要按照服务器型号核对处理器功耗、内存容量、网络、存储、图形处理器、虚拟化、供应地区、价格和支持合同，并且企业需要使用真实 Agent、工具调用、检索和业务应用重放容量测试。计划中的云实例也不能提前算作当前可用容量。
后续观察
- OpenShell 与 KubeRay 能否从 Sandbox 阶段形成公开的一致性测试、安全审查、长期支持和多供应商生产案例。
- NVIDIA 能否为三个新组件公布稳定接口、升级承诺、完整兼容矩阵和独立恢复测试。
- AMD 与服务器合作伙伴能否按具体整机公布 Agent 工作负载的功耗、内存、并发、首 token 延迟、完整价格和供应地区。
来源与核验
本文由英科铸数基于所列公开资料编辑撰写。事实与数据以原始来源为准；“对企业落地意味着什么”为英科铸数结合企业客户场景所作的编辑分析，不构成对第三方产品的背书。
← 返回每日观察