基于 EKS 的混合云大模型推理：NVIDIA NIM + KEDA + Karpenter 的 0→N 弹性架构

背景

大模型推理落地面临的核心矛盾：本地 GPU 有限但延迟/数据要求高，云上 GPU 弹性好但 7×24 成本高。

混合架构是务实的解法——本地 GPU 扛基础负载，云上 GPU 弹性兜底。本文记录基于 Amazon EKS、NVIDIA NIM、KEDA 和 Karpenter 的完整实现方案。

架构

双集群：本地 K8s（IDC GPU）+ Amazon EKS（弹性 GPU）。

关键组件：

• Nginx Router：统一入口，智能路由（本地优先）
• NVIDIA NIM：推理引擎，标准 OpenAI API
• KEDA：Pod 级弹性（0→N）
• Karpenter：节点级 GPU 实例供给
• Prometheus：双侧指标采集

请求流转：ALB → Nginx Router → 本地推理（默认）→ 本地饱和时切到 EKS 推理。

推理引擎选型

NIM vs RayServe + vLLM 实测对比（Llama3-8B-instruct）：

指标	NIM (g5.2xlarge)	RayServe+vLLM (g5.8xlarge+m5.xlarge)
冷启动	5-6 分钟	12-15 分钟
热启动	2-3 分钟	8-11 分钟
资源	单实例	双实例

NIM 用更少资源达到更好性能。冷启动快 2-3 倍。

原因：NIM 针对不同 GPU 架构预编译 TensorRT-LLM 引擎。RayServe 需要额外的 Head 节点，启动时模型加载和编译开销更大。

弹性伸缩

核心创新：综合指标

KEDA 默认用同一指标驱动扩缩容。但更好的策略是：扩容看本地排队、缩容看云上负载。

通过 Custom Metric APP 将两侧指标合并为 custom_metric（0/0.5/1），用不同计算逻辑控制上升沿（扩容）和下降沿（缩容）。

# KEDA ScaledObject
spec:
  minReplicaCount: 0   # 核心：不用时零成本
  maxReplicaCount: 3
  pollingInterval: 15
  cooldownPeriod: 300
  triggers:
    - type: prometheus
      metadata:
        threshold: "0.25"
        query: custom_metric

扩容链路（实测）：触发 → KEDA 创建 Pod（15s）→ Karpenter 启动 Spot（30-90s）→ NIM 加载模型（150-300s）→ 就绪（300-360s）。总计 5-6 分钟。

缩容链路：流量下降 → KEDA 缩 Pod → Karpenter emptiness 检测 → 销毁实例。

性能数据

g5.2xlarge（A10G 24GB），Llama3-8B，NIM 1.1.2：

指标	并发 32	并发 120
TTFT	215ms	3.53s
ITL	37.6ms	37.9ms
吞吐	530 tok/s	193-202 tok/s

ITL 高并发下基本不变——Continuous Batching 效果好。

成本模型

Spot（-67%）× 弹性按需（-67%，按 8h/24h）= On-Demand 全天候的 ~11%。

g5.2xlarge Spot：$0.403/h（vs On-Demand $1.212/h）。

Spot 中断处理：Karpenter + SQS + EventBridge 实现优雅迁移。

网络

四套 CIDR 互不重叠。铁律：先验证双向连通再创建 EKS 集群。

IDC ↔ AWS：Direct Connect 或 Site-to-Site VPN。

适用场景

适合：已有本地 GPU + 峰谷流量 + 延迟/数据敏感。
不适合：7×24 稳定高负载（Reserved + Spot 更经济）。

参考：从IDC到云上GPU：基于 Amazon EKS 的大模型推理混合云弹性部署实践
服务：Amazon EKS | Karpenter