使用 Hearth 在 Kubernetes 上实现大模型自动缩容至零

在生成式 AI 爆发的当下，企业面临的最大挑战之一就是昂贵的算力成本。对于在 Kubernetes 上私有化部署大语言模型（LLM）的开发者来说，一个普遍的痛点是：即便模型在凌晨无人使用，它依然占据着昂贵的 GPU 显存。这种“闲置即浪费”的现象在 NVIDIA A100 或 H100 集群上尤为突出。虽然像 n1n.ai 这样的 API 聚合平台提供了极高性价比的 DeepSeek-V3 和 Claude 3.5 Sonnet 接入方案，但对于有极致数据隐私需求的企业，本地化部署依然是必选项。

为了解决这一痛点，Hearth 项目应运而生。作为一个云原生、厂商中立的 Kubernetes Operator，Hearth 的核心使命是将“运行模型”简化为一个简单的 LLMService 资源，并原生支持 Scale-to-Zero（缩容至零） 功能。

为什么现有的 K8s 方案不够好？

在 Hearth 出现之前，如果你想在 K8s 上实现自动扩缩容，通常会面临以下障碍：

1. 架构过于沉重：像 KServe 或 Seldon 这样的方案，往往需要捆绑安装 Knative 和 Istio。对于只想快速部署一个 Qwen-7B 或 GLM 模型的团队来说，运维这套“全家桶”的成本甚至超过了模型本身。
2. 国产化适配困难：大多数开源推理框架优先适配 NVIDIA 生态。在需要使用华为昇腾（Ascend）或其他国产算力芯片时，开发者不得不手动编写复杂的适配层。
3. 冷启动响应超时：LLM 的冷启动（从 0 到 1 加载显存）通常需要几十秒甚至数分钟。标准的 K8s HPA 在模型加载期间无法处理请求，导致客户端直接报错超时。

Hearth 的核心机制：网关缓冲与心跳维持

Hearth 通过一种创新的“网关-控制器”架构解决了上述问题。当一个 LLMService 被配置为 minReplicas: 0 时，如果没有流量，它将不占用任何 GPU 资源。

当第一个请求到达时：

1. Hearth Gateway 拦截请求并将其放入缓冲区。
2. Hearth Controller 立即感知到流量压力，触发 Pod 扩容。
3. 在模型加载的“冷启动”阶段，网关会向客户端发送 SSE（Server-Sent Events）心跳包。这在协议层面维持了连接，防止负载均衡器或浏览器因超时而断开。
4. 模型加载完成后，网关将请求转发给推理后端（如 vLLM），并将生成的 Token 流式返回给用户。
5. 当流量消失并超过预设的静默期后，系统自动回收 GPU 资源，回到零副本状态。

实战指南：部署 DeepSeek-V3 蒸馏版模型

使用 Hearth 部署模型非常简单。以下是一个典型的 YAML 配置示例：

apiVersion: serving.hearth.dev/v1alpha1
kind: LLMService
metadata:
  name: qwen-7b-chat
  namespace: ai-team
spec:
  model:
    source:
      uri: modelscope://qwen/Qwen2.5-7B-Instruct # 支持 ModelScope 镜像源
  runtime:
    selector: { vendor: [nvidia, ascend] } # 自动匹配可用算力
  resources:
    accelerators: 1
  scaling:
    min: 0 # 核心配置：允许缩容至零
    max: 3
    metric: queueDepth # 基于队列深度扩容
    target: 10

只需执行 kubectl apply -f qwen-7b-chat.yaml，你的模型就进入了自动托管状态。通过 n1n.ai 提供的 API 监控思路，你也可以在 Grafana 中实时查看当前集群的 GPU 利用率和节省的成本。

深度对比：自建 Hearth vs. 使用 n1n.ai

技术优势：多后端适配与国产化支持

Hearth 的设计哲学是“声明式推理运行时（InferenceRuntime）”。这意味着它不绑定任何特定的推理引擎。目前，Hearth 已经验证了 NVIDIA 环境下的 vLLM 路径，并且正在积极适配昇腾 NPU 环境。

对于中国开发者而言，这意味着你可以在同一个 K8s 集群中，通过同一套 manifest 文件，无缝地在 A100 和 昇腾 910B 之间切换模型负载。Hearth 会根据 selector 自动选择最合适的容器镜像和驱动挂载方式。

专家建议：如何优化你的 AI 基础设施？

1. 混合云策略：对于高频、低延迟的业务场景，建议直接使用 n1n.ai 的托管 API；对于长尾、低频但数据敏感的内部工具，使用 Hearth 部署在私有云并开启 Scale-to-Zero。
2. 精细化扩容指标：不要使用 CPU 使用率来扩容 LLM。Hearth 提供的 queueDepth（队列深度）是更好的指标，因为它直接反映了推理引擎的繁忙程度。
3. 模型预热：对于有规律的业务流量（如早 9 点上班高峰），可以通过 CronJob 提前将 minReplicas 改为 1，避开第一次请求的冷启动等待。

总结

Hearth 项目虽然还处于 Alpha 阶段，但它为解决 GPU 资源浪费提供了一个优雅的云原生方案。它让中小企业也能像大厂一样，精细化地管理每一块显卡的生命周期。如果你正在寻找一种既能保证数据隐私，又能最大化降低算力支出的方案，Hearth 绝对值得一试。

当然，如果你希望跳过复杂的底层运维，直接调用全球最领先的 AI 能力，欢迎访问 n1n.ai 获取稳定、高速的 API 服务。

Get a free API key at n1n.ai