NVCF 平台开源情况NVIDIA 近日以 Apache 2.0 协议开源了完整的 NVCFNVIDIA Cloud Functions平台。这不是某个薄 SDK也不是轻量级客户端库而是真正的控制平面、调用平面、计算平面、CLI 工具、Helm charts 以及数据库迁移所有代码都在 GitHub 单体仓库 github.com/nvidia/nvcf 中。NVCF 是 build.nvidia.com 和 NVIDIA 托管推理工作流背后的基础设施现在任何人都可以自行运行完整平台并阅读每一行代码。NVCF 是什么NVCF 的托管服务允许用户注册一个 Docker 容器或 Helm chart指定 GPU 类型NVIDIA 自动处理路由、队列、自动扩缩容和多租户隔离。CoreWeave 等 GPU 云合作商在 Kubernetes 集群上运行 NVIDIA Cluster Agent让其 GPU 能够服务于函数同时 NVIDIA 保留控制平面。2026 年 4 月的 Apache 2.0 发布将这个控制平面彻底公开此前的两个仓库NVIDIA/nvidia-cloud-functions、NVIDIA/nvcf-go已被归档。目前控制平面镜像通过 NVIDIA NGC registry 的 nvcf - onprem 组织分发部署完整堆栈需要 NGC 访问权限。源码是 Apache 2.0 可审查的但可部署包仍然需要通过 NGC。issue #12完整 OSS 构建已经开放作者还专门开了 issue #14 呼吁社区贡献路径。三平面架构整个平台围绕三个独立可扩缩的平面构建通过 NATS JetStream 连接。控制平面运行在专用 Kubernetes 集群上负责函数的生命周期管理、自动扩缩决策和密钥管理。关键组件包括 function - autoscalerRust每 30 秒运行一次扩缩循环从 VictoriaMetrics 读取利用率向 Cassandra 写入决策调用 NVCF API 设置目标实例数、helm - revalGo在计算平面部署前验证 OCI 引用的 Helm charts、OpenBaoApache 2.0 的 Vault 分叉所有函数密钥静态加密运行时通过 ess - agent sidecar 注入以及 Cassandra为 autoscaler 提供持久状态和分布式锁。调用平面位于每个调用方和每个 GPU worker 之间所有请求都必须经过它http - invocationRust/Axum接收 HTTP/gRPC 请求并发布到 NATS JetStreamllm - gatewayGo提供 OpenAI 兼容 API通过嵌入式 Olric cache 实现基于 token 的速率限制grpc - proxyGo转发 gRPC 调用到函数实例ratelimiterGo使用 Olric 分布式缓存实现按函数的速率限制nats - auth - calloutGo支持 NKey、OIDC 和 webhook 三种 NATS 认证策略。计算平面每个 GPU 集群运行一个 NVCANVIDIA Cluster Agentoperator。NVCA 向控制平面注册集群消费 NATS 消息并管理 Pod 生命周期。一次请求的完整流程调用方向 POST /v2/nvcf/pexec/functions/{id} 发送请求http - invocation 通过 ratelimiter gRPC 检查速率请求发布到 NATS 流 Create.NVCA._.{clusterID}._.*NVCA 队列管理器消费消息并创建 Kubernetes CR通过 NATS sequence 去重MiniService controller 调和并创建 Pod 或应用 Helm chart函数 Pod 通过 WorkerService gRPC 回连最后通过 Terminate.NVCA.{clusterID} 触发 Pod 删除和垃圾回收。零扩缩容NATS 缓冲方案这是整个代码库中最重要的架构决策与 Knative 处理零扩缩的方式有根本性差异。Knative 在长时间冷启动期间请求可能面临超时或重试压力这对于需要将大模型加载到 VRAM可能需要数十秒甚至数分钟的 GPU 推理工作负载来说是致命的。NVCF 使用 NATS JetStream 作为持久请求缓冲autoscaler 将目标实例数降为 0没有 Pod 运行新请求到达后发布到 NATS JetStream 并持久化autoscaler 检测到队列深度大于 0将目标实例数设为 1NVCA 接收创建消息并启动 PodPod 通过 WorkerService gRPC 连接并拉取缓冲的消息响应通过仍开放的 http - invocation 连接返回。请求永远不会被丢弃调用方只是在冷启动时等待更长时间。这个设计对比 Knative 的优势是NVCF 在扩容期间请求被缓冲、零丢弃而 Knative 会失败或超时NVCF 通过每集群的持久消费者实现多集群路由而 Knative 仅支持单集群。本地搭建无需 NGC 访问也能玩可以引导集群并使用假 GPU 层无需 NGC 凭证。只有 NVCF 服务部署才需要 nvcf - onprem 组织访问。fake - gpu - operator 来自 run - ai/fake - gpu - operator它向真实 Kubernetes 节点添加 nvidia.com/gpu 扩展资源Pod 可以调度和运行CUDA 调用会失败因为没有真实 GPU但所有 NVCF 编排、NATS 分发和零扩缩逻辑都与生产环境完全一致。开源意味着什么最大的改变是透明性。企业现在可以直接从源码验证 NVIDIA 的架构决策而不是将平台视为黑盒。定制化方面可以修改 autoscaler Rust 循环、添加 NATS 认证策略、扩展 MiniService controller 或构建新的 CLI 命令。在此之前这些内部机制在 NVIDIA 管理环境之外基本上是无法访问的。