现在还早 —— 一起来构建它

Hearth 正在快速迭代，非常欢迎贡献 —— 尤其在真实 NPU 上验证昇腾后端，以及路线图上的 P0/P1 项。现有许多适合初学者的 good first issues。

⭐ 点星 + 保持关注：github.com/hearth-project/hearth

如果你在 Kubernetes 上自托管开源 LLM，一定会遇到和我一样的困境： 

• 一个 GPU 绑定到一个模型，每天只有 3 小时有流量，但你却要付 24 小时的钱。

• 每个推理服务框架都默认 NVIDIA first、英文 first —— 如果你要跑 Qwen、DeepSeek 或 GLM，或者部署在昇腾 / 国产芯片上，就会很别扭。

• “用 KServe 就行了”意味着为了在一个 GPU 上跑一个模型，你要拖上 Knative + Istio。

🔥 Hearth —— 一个厂商中立的 Kubernetes Operator，把“在我的私有集群上跑 Qwen”这件事变成一个 LLMService 清单，内置 scale-to-zero

一个清单。缩零。任选芯片。

apiVersion: serving.hearth.dev/v1alpha1
kind: LLMService
metadata:
  name: qwen3-8b
  namespace: ai
spec:
  model:
    source:
      uri: modelscope://Qwen/Qwen3-8B-Instruct
    runtime:
      selector: { vendor: [nvidia, ascend] }   # 自动选择后端
    resources:
      accelerators: 1
    scaling:
      min: 0        # 👈 缩到零
      max: 3
      metric: queueDepth
      target: 10

$ kubectl apply -f qwen3-8b.yaml
$ kubectl get llmservice -n ai
NAME       PHASE          RUNTIME       REPLICAS   AGE
qwen3-8b   ScaledToZero   vllm-nvidia   0          30s

当请求到达时，Hearth 的网关会缓冲请求，将模型从 0 扩容到 1，通过 SSE 心跳保持客户端连接存活直至冷启动完成，然后将 token 流式返回。再次空闲？回到 0 个 GPU。

同样的清单只需让 vllm-ascend 成为可用运行时，就能跑在昇腾集群上 —— 无需修改 spec。这种可移植性正是核心目标。

它的不同之处

Hearth 刻意不重新实现那些已经成熟的部分：

后端通过集群范围的 InferenceRuntime 进行声明式描述（镜像、参数、加速器资源、探针、指标）。增加一个新芯片只需要一个薄适配层 —— 而不是重写。

目前真正可用的功能

我诚实说明一下成熟度 —— 这是预发布版本 v0.1.0（alpha）：

• ✅ NVIDIA 后端 + 完整的缩到零路径已在真实 A100 上端到端验证 —— 冷启动保持存活、优雅排干（正在进行的流在缩容后仍能存活）、模型缓存/预热、1→N 自动扩缩、Grafana 仪表板。

• 🧪 昇腾后端已完成脚手架和黄金测试（能渲染出正确的清单）—— 真实 NPU 验证是 v1 里程碑。

• ⚠️ 尚未可用于生产：没有认证、没有多租户。目前非常适合内部/开发、对延迟有一定容忍度、对成本敏感的推理场景 —— 缩到零能让很多空闲模型挤在少数 GPU 上。

60 秒内尝试 —— 无需 GPU

你可以在 kind 上运行整个控制平面：

make install      # 将 CRD 安装到你的 kube-context
make run          # 运行 operator
kubectl apply -f config/samples/serving_v1alpha1_inferenceruntime.yaml
kubectl apply -f config/samples/serving_v1alpha1_llmservice.yaml -n ai