部署 Kimi K3 这类大型模型，真正困难的部分通常不是启动一个容器，而是把 GPU 拓扑、模型权重、分布式推理、故障恢复和服务入口组合成一套可重复运维的系统。AWS 提供了两条主要路径：使用 Amazon SageMaker HyperPod 建设面向大规模 AI 工作负载的集群，或者把推理服务部署到 Amazon EKS，由 Kubernetes 负责调度和服务治理。
两种方案并不是简单的“托管与自建”之分。选择时需要看团队已有平台、模型服务框架、扩缩容方式，以及是否需要跨节点并行。
两条路径解决的是不同层面的问题
SageMaker HyperPod 更适合围绕大规模模型训练和推理建设专用算力环境。团队可以把注意力放在 GPU 节点、分布式任务和集群韧性上，而不必从零拼装完整的基础设施管理流程。如果 Kimi K3 需要跨节点加载权重，或者同一套集群还要承担微调、评测与批量推理，HyperPod 通常更贴近这类工作负载的运行方式。
Amazon EKS 则把 Kimi K3 纳入标准 Kubernetes 体系。已有 EKS 平台的团队可以继续使用 Namespace、Service、Ingress、GitOps、监控和策略控制等机制。它适合服务接口标准化、发布频繁，并且需要与其他微服务共享网络和治理能力的场景。
可以用下面几项做初步判断：
| 决策项 | 更偏向 HyperPod | 更偏向 EKS |
|---|---|---|
| 主要任务 | 分布式训练、微调、大规模推理 | 在线 API、平台化服务治理 |
| 团队经验 | AI/HPC 调度和分布式运行 | Kubernetes、GitOps 和微服务 |
| GPU 拓扑 | 强调跨节点协同 | 强调 Pod 调度与服务伸缩 |
| 运维入口 | 作业、集群和节点 | Deployment、Service、Ingress |
| 周边系统 | 模型实验与计算流水线 | 现有云原生应用体系 |
这不是硬性边界。HyperPod 集群也可以承载服务化工作负载，EKS 也能运行分布式推理。区别主要在于团队希望把哪一种控制面作为日常运维入口。
部署前先固定三个契约
无论选择哪条路径，都应先固定镜像、权重和 API 三个契约。
镜像契约需要明确 CUDA、通信库和模型服务框架的版本，并把启动脚本封装进镜像。不要在节点启动后临时安装大量 Python 依赖，否则节点替换和扩容会产生不可预测的版本差异。
权重契约需要记录模型版本、存储位置、校验值和缓存策略。权重可以来自对象存储或预制快照，但容器看到的最终目录应保持稳定，例如 /models/kimi-k3。
API 契约应尽量与调用方解耦。实践中可以让推理引擎暴露 OpenAI 兼容接口，或者在前面增加一层轻量网关。这样替换底层引擎时，业务应用不需要同步修改请求格式。
还要在部署前确认 Kimi K3 所需的精度、单副本 GPU 数量、张量并行或流水线并行参数。这些值取决于模型版本、推理框架、量化方式和实例显存，不能直接照搬其他模型的配置。
可以这样实践：在 EKS 上搭建可替换的服务骨架
下面的示例假设你已经拥有一个能够加载 Kimi K3、监听 8000 端口并提供 /v1/chat/completions 接口的镜像。示例中的镜像地址、模型 URI、GPU 数量和启动参数不是官方固定值，运行前必须根据实际推理引擎修改。
先配置集群访问并确认 GPU 节点资源：
export AWS_REGION=us-west-2
export EKS_CLUSTER=my-kimi-cluster
aws sts get-caller-identity
aws eks update-kubeconfig \
--region "$AWS_REGION" \
--name "$EKS_CLUSTER"
kubectl get nodes
kubectl get nodes -o custom-columns='NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu'
然后设置部署变量。MODEL_SERVER_IMAGE 应替换成团队构建并推送到镜像仓库的地址；MODEL_URI 则替换成经过授权的权重位置。
export MODEL_SERVER_IMAGE='123456789012.dkr.ecr.us-west-2.amazonaws.com/kimi-k3-server:2025-01'
export MODEL_URI='s3://my-model-bucket/kimi-k3/'
export GPU_COUNT='8'
创建 kimi-k3.yaml：
apiVersion: v1
kind: Namespace
metadata:
name: kimi-serving
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: kimi-k3
namespace: kimi-serving
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: kimi-k3
template:
metadata:
labels:
app: kimi-k3
spec:
terminationGracePeriodSeconds: 120
containers:
- name: model-server
image: ${MODEL_SERVER_IMAGE}
imagePullPolicy: IfNotPresent
args:
- --model
- ${MODEL_URI}
- --host
- 0.0.0.0
- --port
- "8000"
ports:
- name: http
containerPort: 8000
resources:
requests:
cpu: "16"
memory: 128Gi
nvidia.com/gpu: "${GPU_COUNT}"
limits:
cpu: "16"
memory: 128Gi
nvidia.com/gpu: "${GPU_COUNT}"
startupProbe:
httpGet:
path: /health
port: http
failureThreshold: 120
periodSeconds: 10
readinessProbe:
httpGet:
path: /health
port: http
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: kimi-k3
namespace: kimi-serving
spec:
selector:
app: kimi-k3
ports:
- name: http
port: 80
targetPort: http
type: ClusterIP
使用 envsubst 注入变量并部署：
envsubst < kimi-k3.yaml | kubectl apply -f -
kubectl -n kimi-serving rollout status deployment/kimi-k3 --timeout=30m
kubectl -n kimi-serving get pods -o wide
如果镜像的健康检查路径不是 /health，需要同步修改两个 Probe。若推理引擎要求从 init container 下载权重，或者需要挂载 FSx、EBS 等存储，也应在 Pod 模板中增加对应 Volume。对于跨节点推理，单个 Deployment 骨架并不充分，需要采用推理框架支持的分布式启动器、稳定的节点发现机制和匹配的网络配置。
服务就绪后，可以先通过端口转发做一次不经过负载均衡器的验证：
kubectl -n kimi-serving port-forward service/kimi-k3 8000:80
在另一个终端发送请求。模型名称和请求字段应按实际服务实现调整：
curl -sS http://127.0.0.1:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "kimi-k3",
"messages": [
{"role": "user", "content": "Explain tensor parallelism in three sentences."}
],
"temperature": 0.2,
"max_tokens": 256
}'
HyperPod 中应复用同一套运行契约
在 HyperPod 路径中，具体提交方式会取决于集群采用的编排方式以及模型服务框架。可以这样实践：保留与 EKS 相同的容器镜像、模型目录和健康检查接口，只替换任务提交与资源编排层。
一个可维护的启动脚本可以接收节点数、每节点 GPU 数和模型路径，而不是把环境信息写死：
#!/usr/bin/env bash
set -euo pipefail
: "${MODEL_PATH:?MODEL_PATH is required}"
: "${GPUS_PER_NODE:?GPUS_PER_NODE is required}"
: "${MASTER_ADDR:?MASTER_ADDR is required}"
: "${MASTER_PORT:=29500}"
exec /opt/model-server/bin/serve \
--model "$MODEL_PATH" \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size "$GPUS_PER_NODE" \
--master-address "$MASTER_ADDR" \
--master-port "$MASTER_PORT"
这里的 /opt/model-server/bin/serve 和参数名称是一个适配模板，不代表 Kimi K3 的固定官方命令。接入实际引擎时，应替换可执行文件，并核对它对多节点、张量并行、流水线并行和权重格式的支持。
HyperPod 上的重点不是把 Kubernetes YAML 原样搬过去，而是保证以下信息仍然可审计：使用了哪个镜像和权重版本、任务获得了哪些 GPU、主节点如何发现、失败后如何恢复，以及服务是否通过固定探针返回健康状态。
上线前的检查清单
先用单副本完成正确性和显存验证，再扩展吞吐量。大型模型加载时间可能很长，启动探针需要给足窗口，但就绪探针不能在权重尚未加载完成时放行流量。
上线前至少检查以下项目：
- 固定镜像摘要、模型版本和配置文件，避免使用浮动标签。
- 验证实例 GPU 型号、显存容量和节点间网络是否匹配并行方案。
- 对模型下载、首个 token 延迟、输出 token 吞吐量和队列长度分别监控。
- 为权重存储、镜像仓库和日志系统配置最小权限。
- 不把长期密钥写入镜像、YAML 或启动脚本。
- 使用真实长度分布做压测，短提示词测试不能代表生产负载。
- 预估空闲副本、权重缓存和跨节点通信带来的成本。
- 明确节点中断、进程退出和健康检查失败时的恢复流程。
如果团队已经围绕 Kubernetes 建立成熟的平台能力，EKS 通常能更快接入现有发布和监控体系。如果主要挑战是大规模 GPU 集群、分布式任务和计算环境管理，HyperPod 更值得优先评估。无论选择哪条路径，都应先把镜像、权重和 API 做成稳定契约，再决定调度层；这会显著降低后续更换实例、推理引擎或部署平台的成本。