在 AWS 上部署 Kimi K3：HyperPod 与 EKS 两条路径怎么选

预计阅读时间：11 分钟

在 AWS 上部署 Kimi K3，可以沿两条路径展开：使用 Amazon SageMaker HyperPod 构建面向大模型训练与推理的集群，或者把服务部署到 Amazon Elastic Kubernetes Service（Amazon EKS）。两种方案都能承载模型工作负载，但它们解决的问题不同：HyperPod 更强调托管式集群与机器学习基础设施，EKS 则提供更通用、更容易纳入现有 Kubernetes 平台的控制面。

来源摘要没有给出模型镜像、权重格式、GPU 规格和推理框架，因此下面的配置属于可改造的工程模板。部署前需要根据 Kimi K3 的实际发布物，确认模型许可证、下载方式、运行时参数以及硬件要求。

两条路径的核心差异

选择 HyperPod 时，团队通常希望减少大规模机器学习集群的基础设施维护工作。模型节点、共享存储、任务调度和故障恢复可以围绕 SageMaker 工作流组织，适合已经使用 AWS 机器学习服务，或者准备运行训练、微调和批量推理任务的团队。

选择 EKS 时，Kimi K3 会被视为一个标准的容器化服务。平台团队可以继续使用 Deployment、Service、Ingress、PersistentVolumeClaim、Prometheus 和 GitOps 等 Kubernetes 组件。这种路径更适合已经维护 EKS 集群，并希望统一管理模型服务与普通后端服务的组织。

可以从几个具体问题判断：

问题	更偏向 HyperPod	更偏向 EKS
团队主要使用 SageMaker 工作流吗	是	否
是否已有成熟的 Kubernetes 平台	不一定	是
工作负载以训练、微调和批处理为主吗	是	不一定
是否需要沿用现有 Ingress、服务网格和 GitOps	不一定	是
谁负责 GPU 驱动、节点升级和容量治理	ML 平台团队	Kubernetes 平台团队

这并不意味着二者只能选一个。实践中可以让 HyperPod 承担训练或微调，让 EKS 承担在线推理，但模型版本、制品存储和发布流程必须保持一致。

部署前先固定四个接口

基础设施创建之前，应先确定以下契约：

模型制品：权重存放在 S3、共享文件系统还是容器镜像中，以及节点如何取得访问权限。
推理运行时：容器启动命令、监听端口、健康检查路径和模型加载完成的判定方式。
硬件边界：单副本需要多少 GPU、显存、CPU、内存和本地磁盘，是否支持跨节点并行。
服务协议：请求与响应格式、最大上下文、超时、流式输出以及并发限制。

IAM 权限也应该按角色拆分。集群或节点角色只获得读取指定模型路径、写入指定日志位置等必要权限，不应为了快速验证而长期保留宽泛的 S3 或管理权限。若模型存放在私有 S3 路径，还需要同时检查网络出口、VPC Endpoint、KMS 解密权限和对象权限。

在 EKS 上落一个可改造的服务模板

下面示例假设已经存在 EKS 集群、GPU 节点和可用的 GPU 设备插件。它还假设 Kimi K3 被封装为一个监听 8000 端口的 HTTP 推理镜像，并可通过环境变量读取模型目录。这些是假设，不是来源摘要给出的 Kimi K3 固定接口。

运行前必须修改：

YOUR_ACCOUNT_ID 和 YOUR_REGION；
容器镜像地址与启动参数；
GPU 数量及节点标签；
PVC 的 StorageClass 和容量；
健康检查路径，或改为运行时实际支持的探针。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: kimi-k3-model
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kimi-k3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kimi-k3
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: kimi-k3
    spec:
      nodeSelector:
        workload: gpu-inference
      containers:
        - name: server
          image: YOUR_ACCOUNT_ID.dkr.ecr.YOUR_REGION.amazonaws.com/kimi-k3:latest
          imagePullPolicy: IfNotPresent
          args:
            - --model-path=/models/kimi-k3
            - --host=0.0.0.0
            - --port=8000
          ports:
            - name: http
              containerPort: 8000
          env:
            - name: MODEL_PATH
              value: /models/kimi-k3
          resources:
            requests:
              cpu: "8"
              memory: 64Gi
              nvidia.com/gpu: "1"
            limits:
              cpu: "16"
              memory: 96Gi
              nvidia.com/gpu: "1"
          readinessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 30
          volumeMounts:
            - name: model
              mountPath: /models
              readOnly: true
      volumes:
        - name: model
          persistentVolumeClaim:
            claimName: kimi-k3-model
---
apiVersion: v1
kind: Service
metadata:
  name: kimi-k3
spec:
  selector:
    app: kimi-k3
  ports:
    - name: http
      port: 80
      targetPort: http
  type: ClusterIP

将内容保存为 kimi-k3.yaml 后，可以这样部署和检查：

aws eks update-kubeconfig --region YOUR_REGION --name YOUR_CLUSTER
kubectl apply -f kimi-k3.yaml
kubectl rollout status deployment/kimi-k3 --timeout=20m
kubectl get pods -l app=kimi-k3 -o wide
kubectl logs deployment/kimi-k3 --tail=100

在没有配置公网入口时，可以先通过端口转发验证服务：

kubectl port-forward service/kimi-k3 8000:80

另开终端，根据实际 API 调整请求体：

curl --fail-with-body http://127.0.0.1:8000/health

大模型加载时间可能远超普通 Web 服务。不要仅靠增大 initialDelaySeconds 掩盖问题；更稳妥的做法是让运行时分别暴露存活与就绪状态，并考虑 Kubernetes startupProbe。只有权重加载完成、GPU 初始化成功后，就绪探针才应通过。

HyperPod 路径要重点设计什么

HyperPod 方案不应只停留在“创建一组 GPU 实例”。部署设计至少要覆盖节点分组、模型制品挂载、作业调度、日志采集、检查点保存和故障后的恢复方式。

可以这样实践：把基础设施定义、模型启动脚本和运行参数分开管理。基础设施层负责实例类型、节点数量、网络和 IAM；作业层只接收模型 URI、镜像版本、并行度与输出路径。一个最小的作业参数文件可以写成：

# 这是通用参数示例，需要接入团队实际使用的 HyperPod 作业提交工具。
job_name: kimi-k3-inference
container_image: YOUR_ACCOUNT_ID.dkr.ecr.YOUR_REGION.amazonaws.com/kimi-k3:VERSION
model_uri: s3://YOUR_BUCKET/models/kimi-k3/VERSION/
replicas: 1
gpus_per_replica: 8
output_uri: s3://YOUR_BUCKET/jobs/kimi-k3-inference/
environment:
  MODEL_PATH: /opt/ml/model
  SERVER_PORT: "8000"

这里刻意不提供未经来源确认的 HyperPod API 字段。AWS CLI、SageMaker SDK 和集群编排方式可能随所选的 HyperPod 配置及调度器而变化，应以当前 AWS 文档和团队创建集群时使用的接口为准。真正需要稳定下来的是参数契约，而不是把账户、区域和模型版本写死在脚本里。

上线时不要忽略成本与恢复能力

GPU 推理服务的成本不仅取决于实例单价。模型加载时间、副本空闲率、请求批处理效率、上下文长度和输出 token 数量都会改变单位请求成本。自动扩缩容也不能直接照搬 CPU 服务：新副本可能需要较长时间下载权重并初始化 GPU，突发流量到来后再扩容往往已经太晚。

上线前建议完成这份检查清单：

用固定测试集验证输出质量、延迟、吞吐和显存峰值。
固定镜像摘要与模型版本，不在生产环境使用不可追踪的 latest。
验证节点重启、Pod 重调度或作业失败后的恢复流程。
对模型下载、首 token 延迟、请求队列、GPU 利用率和错误率建立监控。
为公网入口增加认证、限流、请求大小限制和审计日志。
明确输入数据、提示词和生成结果的保留策略。
在扩大节点规模前，用真实请求分布测量每个副本的安全并发。

如果团队已经围绕 SageMaker 建立机器学习平台，HyperPod 通常更容易融入训练和批处理流程；如果 EKS 已经承载生产服务，并具备 GPU 节点、可观测性和发布能力，EKS 会减少额外的平台分裂。最终选择应由现有运维能力、工作负载形态和恢复目标决定，而不是只比较创建集群时需要多少条命令。