KubeCon India 2026：构建在云原生技术栈之上的主权 AI

在孟买举行的 KubeCon + CloudNativeCon India 2026 贯穿着一条主线：主权 AI 是一种架构需求而非口号，Sarvam 和 NPCI 这样的人口级平台与商业平台依靠同一套云原生工具承载负载，而由 Prometheus、Thanos、Argo CD 和 vLLM 组成的 CNCF 原生技术栈反复出现。本文梳理主题演讲真正展示的内容，以及哪些模式值得带回去借鉴。

几周前，我们介绍了 AWS Summit Seoul 2026：韩国企业与 Agentic AI，以及韩国企业如何将 Agentic AI 推向生产环境。在 KubeCon + CloudNativeCon India 2026 上，一个相似的主题浮现出来，但伴随着独特的挑战。印度庞大的人口和 22 种官方语言，意味着服务公民可能要用马拉地语回答一位农民的问题，或者用印地语处理一笔贷款咨询，而且往往是通过电话而非应用完成。这种多样性带来了一种不同的工程挑战，它塑造了孟买主题演讲的关注重点。

主题演讲共同贯穿的主线

「主权」一词在 KubeCon India 的主题演讲中频繁出现，有两场讲座直接强调了这一点。Sarvam 探讨了如何为整个印度构建主权 AI，而印度国家支付公司（NPCI）则强调，云原生技术如今已成为大规模主权 AI 的关键基础设施。这一趋势并不局限于印度。在 2025 年 11 月首尔举办的 Naver Cloud DAN25 大会上，CEO Kim Yuwon 等人同样聚焦于主权 AI，将其描述为由那些深谙本国语言、数据和行业的企业所构建的垂直模型。看到这一理念在首尔和孟买两地独立出现，说明主权 AI 如今已是一种架构上的需求，而不仅仅是一句口号。

在这场活动上，规模是意料之中的，但它并不是主旋律。每一场主题演讲都谈到了大规模运营，只是方式各不相同。Sarvam 和 NPCI 聚焦于服务全体国民，而 Flipkart、Rapido 和 JioHotstar 则代表了大型商业平台。

Sarvam 对主权 AI 的探索根植于政策。它是在 IndiaAI Mission 的 Innovation Center 支柱下入选的十二家组织之一，获得了 ₹246.72 crore 的资金以及算力资源。Sarvam 正在构建核心的语言和语音模型，例如 Bulbul（面向 11 种印度语言、提供 39 种声音的文本转语音）和 Saaras（面向全部 22 种官方语言的语音转文本）。

企业主题演讲真正展示的内容

Sarvam 的 Avi Kothari 和 Vinayak Gavariya 描述了一个印度所需要的对话式 AI 平台，它要能用 22 种语言交流：从用马拉地语向一位确认作物的农民对话，到用泰米尔语帮助一位公民申领政府方案，再到用印地语处理一笔贷款咨询。他们提到的规模是每天数百万次 API 调用和语音对话，延迟低至亚秒级，同时还要保持可审计。他们用一个具体的部署案例为此提供了支撑：一项全国性的作物核验计划，在一次为期 24 天的活动中触达了 1700 万农民，并制定了在下一季度覆盖 8000 万农民的路线图。整套技术栈完全基于 CNCF：用 Linkerd 实现零信任服务网格，用 Strimzi 托管的 Kafka 进行事件流处理，用 Argo CD 和 Helm 在大约 20 个组件之间进行 GitOps 交付，用 Prometheus 和 Thanos 实现统一的多集群可观测性，并用 CloudNativePG 作为权威数据库。

来自 NPCI 的 Tittu Varghese 阐明了「人口级规模」对支付意味着什么。NPCI 每月处理超过 240 亿笔交易，每天处理 7 亿笔支付。他们还借助 Kubernetes、Kubeflow、Prometheus、vLLM、OpenStack 和 NVIDIA AI 平台，以亚秒级速度运行实时欺诈检测。这是 AI 推理成为关键国家基础设施一部分的最清晰例证。

Flipkart 的讲座聚焦于可靠性而非 AI 推理，其可靠性工程团队利用 LitmusChaos 项目构建了一个集中式、多租户的混沌工程平台，以增强数百个微服务的健壮性。他们从四个方面对 Litmus 进行了定制：一套混合多租户方案、一种基于 DaemonSet 的混沌注入高可用模型、一个用于动态选择目标的 Script Runner，以及一个面向 Kubernetes 之外 VM 工作负载的混合扩展。他们的成果在台上获得了认可，赢得了 CNCF End User Case Study Contest。他们将约 90% 的混沌实验迁移到了预发布集群，并向上游贡献了 5 处修复，其中包括对数据库索引和重名校验的改进。

Rapido 和 JioHotstar 提供了更多消费级规模的例子。Rapido 的 CTO Srivatsa Katta 和 Adarsh K Kumar 介绍了印度最大的出行平台，它每天通过实时撮合乘客和司机处理超过 400 万次出行。他们的系统运行在 150 多个微服务之上，借助 Kubernetes、Istio、Prometheus、Thanos、Cert Manager 和 External DNS，每秒处理 200,000 个请求。来自 JioHotstar 的 Pradeep Bishnoi 讲解了他们如何在重大赛事期间向 5000~6000 万名用户同时直播板球比赛，跨全球众多集群使用 Kubernetes、Amazon EKS、OpenTelemetry、Karpenter 和 Envoy Gateway。他还预告了一些由 AI 驱动的新功能，例如对话式的 Kubernetes 故障排查和更智能的 SRE 自动化。

反复出现的 GPU 问题

另一个关键主题是：AI 工作负载的主要挑战不在于获得足够的 GPU，而在于如何高效地使用它们。来自 vCluster 的 Saiyam Pathak 解释说，尽管容器、自动扩缩容、多租户和 RBAC 都已经解决，但即便一个工作负载只需要一块 GPU 的 10%，Kubernetes 仍然要求分配整块 GPU。他给出的方案是 HAMi，它能将一块物理 GPU 切分成基于显存的切片，以及 DRA，它让 Kubernetes 能够把 GPU 视为不仅仅是简单的数量。他做了现场演示：用一台 MacBook 控制一台 NVIDIA DGX Spark，让单块 Blackwell GPU 同时为两个团队运行两个开源 LLM。在另一场讲座中，来自 Red Hat 的 Ravindra Patil 借助 llm-d 在路由层解决了同一问题。他将其与一个基础的轮询（round-robin）均衡器进行了对比：后者会把重复的提示词分散到各个 pod 上，导致不必要的缓存重新加载。相比之下，llm-d 会把每个请求发送到一个已经持有所需缓存的 pod（缓存感知），或者在需要从头开始时发送到负载最轻的 pod（负载感知），并使用一条由 scraper、filter 和 scorer 组成的流水线来挑选最佳目标。这种方法减少了冗余的缓存加载，并改善了 P95/P99 延迟。

反复出现的 CNCF 原生技术栈

有几个项目在不同的主题演讲中都出现了。Prometheus 几乎在每一场讲座中都被提及，往往与 Thanos 搭配用于多集群可观测性。Argo CD 是 GitOps 交付的主要工具。vLLM 负责推理，而关于切分 GPU（HAMi、DRA、KAI-Scheduler）的讨论，则呼应了 AWS Summit Seoul 上的 Dynamic Resource Allocation 主题。服务网格被广泛使用，各家企业在 Linkerd 和 Istio 之间各有选择。

值得带回去借鉴的主题

有几个关键模式浮现出来。第一，主权已经成为一种核心的架构需求，而不只是一个流行语，而且这一理念正在跨地区涌现：从孟买的 Sarvam 和 NPCI，到首尔的 Naver DAN25。第二，当面临真正人口级规模的挑战时，比如 Sarvam 的数百万农民或 NPCI 每天 7 亿笔支付，承载这些负载的，正是 Flipkart、Rapido 和 JioHotstar 用于商业流量的同一套云原生工具。第三，GPU 的挑战已经从获得足够的硬件，转向更好地利用硬件，而 HAMi、DRA 和 KAI 这样的方案帮助 Kubernetes 管理按比例切分、能力感知的 GPU。最主要的启示是：这一切都不依赖专门为 AI 而新建的基础设施，关键在于把现有的 CNCF 技术栈用好。