企业官网建设流程全解析

一个轻量、可组合的开源 LLM Serving 控制面，让低频模型不再长期占用宝贵的 GPU 和 NPU

Noctaya 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、冷启动、请求控制、流式响应、优雅退出和回到零副本的完整过程。

GitHub：github.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)