一个轻量、可组合的开源 LLM Serving 控制面让低频模型不再长期占用宝贵的 GPU 和 NPUNoctaya v0.3.0 (Release v0.3.0 · noctaya/noctaya · GitHub) 现已正式发布。谈大模型推理服务行业通常首先关注高并发、多模型路由、分布式推理和集群吞吐量。但在大量企业私有化环境中真实情况往往有所不同1. 集群中的 GPU 或 NPU 数量有限少数热门模型需要长期在线同时还存在一批调用频率不高、但又必须随时可用的长尾模型。2. 如果所有模型都保持常驻就会持续占用昂贵的加速卡资源如果简单地把副本数设置为零下一个请求到来时又会遇到 Pod 调度、镜像拉取、权重加载、健康检查和客户端超时等一系列问题。3. 把副本数降到零并不困难。真正困难的是当第一个请求到达时如何确保它不会在模型启动过程中丢失当模型再次缩容时又如何保护仍在生成中的流式请求。Noctaya 正是为这个问题而设计的。Noctaya 是什么Noctaya (GitHub - noctaya/noctaya: Kubernetes-native control plane for vendor-neutral, scale-to-zero LLM serving · GitHub) 是一个面向私有 Kubernetes 集群的轻量级、可组合 LLM Serving 控制面。它不是推理引擎不实现算子和芯片内核它不安装厂商设备插件也不取代 Kubernetes 调度器它同样不试图成为一个覆盖所有场景的“大而全”AI Serving 平台。Noctaya 专注于模型声明与可运行推理端点之间的 Kubernetes 生命周期管理。应用开发者通过命名空间级别的 LLMService 描述使用哪个模型选择哪个推理运行时需要多少加速卡、CPU 和内存如何缓存和预热模型如何进行弹性伸缩冷启动期间如何处理请求。集群管理员则通过集群级别的 InferenceRuntime 定义推理镜像和启动参数设备插件暴露的资源名称节点选择器和容忍配置可选调度器与队列健康检查优雅终止策略。这种设计把“应用希望如何运行模型”与“集群具体使用什么硬件和运行时”分离开来。Noctaya 根据这两个资源自动创建后端工作负载、稳定网关、Kubernetes Service、模型缓存、可选预热任务以及 KEDA 弹性伸缩对象。不只是把副本数设置为零、Noctaya 会为每个模型保留一个轻量网关而真正占用加速卡的模型后端可以在 0 到指定最大副本数之间伸缩。完整流程如下1. 没有请求时KEDA 将模型后端保持在零副本。2. 请求首先到达始终可用的 Noctaya 网关。3. 网关记录当前需求并根据策略等待模型启动或者立即返回带有 Retry-After 的 503。4. KEDA 通过默认 Metrics API 或可选的 External Push 模式激活模型后端。5. 后端从缓存加载模型只有通过运行时健康检查后才会进入 Ready 状态。6. 网关把请求转发给后端并将生成结果流式返回给客户端。7. 持续增加的队列需求可以触发 1→N 扩容。8. 流量消失后Noctaya 会先保护仍在处理的请求再让后端回到零副本。网关还提供有界请求队列。队列满时新增请求会明确收到 429而不是继续消耗内存和连接。冷启动存在最大等待时间流式请求还可以在模型加载期间持续收到 SSE 心跳从而降低客户端或中间代理提前断开连接的风险。v0.3.0 新增了 External Push 模式。它可以在冷请求出现时立即向 KEDA 推送激活事件不必等待下一次轮询。与此同时Activation Lease 会把模型激活需求与当前客户端连接解耦。即使 Reject 模式已经返回 503或者 KEDA 重新建立External Scaler 连接激活信号仍然可以得到保留。为了兼容更多环境原有 Metrics API 模式仍然是默认选项。缓存和预热是弹性到零的一部分、释放加速卡并不是最终目的。如果模型每次启动都需要重新下载全部权重那么弹性到零的实际价值会大幅下降。Noctaya 当前支持HostPath 模型缓存NodeLocalPVC 模型缓存Hugging Face 和 ModelScope 模型预热通过 pvc:// 挂载已经提前准备好的模型权重。预热任务会继承运行时的节点选择、容忍和调度配置但不会申请 GPU 或 NPU。这样可以先完成权重下载再把加速卡留给真正的推理 Pod。在可观测性方面Noctaya 暴露稳定的网关与后端指标但不会把监控系统绑定到核心控制器中。用户可以按需安装 kube-prometheus-stack 或其他兼容方案也可以完全不部署监控组件。Noctaya 与 Kthena热门模型和长尾模型可以共存、Noctaya 并不要求用户放弃现有的 AI Serving 平台。项目已经在真实硬件上录制了一段演示Kthena 负责让高频模型保持在线Noctaya 则负责管理同一 Kubernetes 集群中的长尾模型。实际的分工方式高频、延迟敏感模型由面向集群级 Serving 的平台管理低频和长尾模型交给 Noctaya在没有请求时释放加速卡。Volcano 可以为两类工作负载提供调度能力但它仍然是独立的外部集成而不是被绑定在 Noctaya 核心代码中。Noctaya 当前适合哪些场景Noctaya v0.3.0 仍然是 Alpha 软件API 版本为 serving.noctaya.dev/v1alpha1。它目前更适合以下环境企业内部、开发、实验和预发布集群GPU 或 NPU 数量有限、成本敏感的私有化部署包含低频或突发访问模型的工作负载能够接受一定模型冷启动时间的场景位于可信网络边界内的单租户环境希望使用小型 Kubernetes 控制面而不是引入完整 Serving 平台的团队。Noctaya 暂时不适合共享多租户集群或直接面向公网客户的推理服务。网关当前没有内置身份认证External Push 模式在需求聚合完成前要求使用一个网关副本。当前物理验证采用整卡分配模式尚未证明 HAMi 共享、MIG、通用多节点拓扑或分数加速卡能力。即使没有 GPU 或 NPU也可以体验 Noctaya。项目提供了 CPU-only 开发指南(noctaya/docs/no-gpu.md at main · noctaya/noctaya · GitHub)可以在 Kind上验证网关、KEDA、冷启动、请求控制、流式响应、优雅退出和回到零副本的完整过程。GitHubgithub.com/noctaya/noctaya (GitHub - noctaya/noctaya: Kubernetes-native control plane for vendor-neutral, scale-to-zero LLM serving · GitHub)路线图ROADMAP.md(noctaya/ROADMAP.md at main · noctaya/noctaya · GitHub)