英伟达AICR推理运行时
3 节点1 篇4 来源
英伟达推出AI集群运行时(AICR),旨在解决NVIDIA Dynamo在Kubernetes上部署时基础设施依赖复杂的问题。AICR将GPU驱动、动态资源分配、调度器及监控组件打包为版本锁定的“配方”,通过快照、生成、渲染、部署、验证五步流程,实现运行时就绪与应用部署的分离。
【背景】传统部署中,平台团队需手动协调vLLM/SGLang后端与底层硬件兼容性,耗时且易错。AICR通过固定组件版本和校验逻辑,提供可重复的基础设施层。
目前存在两条主要路由路径:适用于最小拓扑的Dynamo Frontend原生路由,以及集成Kubernetes Gateway API的GAIE/EPP路径。Dynamo 1.4.2采用TCP处理请求平面,ZMQ处理KV缓存事件以支持缓存感知路由。
尽管AICR简化了标准流程,但在多安全组隔离的EKS集群中,其ai-service-metrics验证器因Pod调度非确定性导致无法访问Prometheus而失败,暴露了网络策略与调度亲和性之间的潜在冲突。
事情怎么走到这一步
NVIDIA发布技术博客,详细介绍AICR如何通过版本锁定配方管理Dynamo推理运行时,并对比Frontend与GAIE/EPP两种路由方案。
developer.nvidia.com ↗第三方媒体We Are The Frontier报道AICR v1.1.2发布,强调其自动化四阶段工作流及对H100至GB300架构的支持。
wearethefrontier.org ↗GitHub Issue #933记录AICR在多安全组EKS集群中,因验证器Pod调度位置不确定导致Prometheus连接超时的Bug。
github.com ↗
还没定论的部分
- AICR是否计划引入更严格的Pod Affinity规则以解决多安全组环境下的验证器非确定性问题?
- 对于不使用Gateway API的传统Ingress场景,Dynamo Frontend路由与GAIE/EPP路径的性能差异是否有公开基准测试数据?
- AICR配方对非NVIDIA GPU Operator管理的集群(如使用其他驱动栈)的支持程度如何?