模型完成量化，只解决了显存占用和推理成本的一部分问题。真正进入生产环境时，还要决定由谁管理实例、如何扩缩容、怎样接入现有容器平台，以及如何监控冷启动、显存和请求延迟。对于已经通过 Unsloth 量化的模型，可以根据团队现有基础设施，在 Amazon EC2、Amazon SageMaker AI 推理端点、Amazon EKS 和 Amazon ECS 之间选择。
四种部署模式解决的是不同问题
这四条路径并不是简单的产品替换关系，而是四种不同的运维责任划分。
| 模式 | 适合场景 | 团队需要负责的内容 | 主要取舍 |
|---|---|---|---|
| EC2 | 调试、自定义运行时、直接访问 GPU | 系统、驱动、进程、扩缩容和故障恢复 | 控制力最强，运维工作最多 |
| SageMaker AI 端点 | 需要托管推理、标准化发布和扩缩容 | 模型镜像、制品和端点配置 | 平台能力完整，但要遵循托管服务接口 |
| EKS | 已有 Kubernetes 平台、需要统一调度和治理 | 集群、控制器、工作负载与 GPU 节点 | 灵活，平台复杂度较高 |
| ECS | 已使用 AWS 容器体系，不需要 Kubernetes | 任务定义、服务和容量配置 | 容器化清晰，编排模型比 EKS 简单 |
EC2 通常是打通部署链路的第一站。工程师可以登录实例，检查 CUDA、驱动、模型文件和推理进程，适合定位量化模型加载失败、算子不兼容或显存不足等问题。不过，SSH 调试方便并不等于生产可维护；当副本增加后，人工管理进程很快会成为负担。
SageMaker AI 端点把实例生命周期、端点更新和托管服务能力交给平台，更适合希望建立标准发布流程的团队。EKS 与 ECS 则适合模型推理必须进入现有容器框架的情况，例如复用内部网关、服务发现、日志采集和发布审批流程。
先固定模型制品和推理接口
无论选择哪一种运行平台，都建议先把“模型如何加载”和“服务如何响应”固定下来。量化方法、模型文件格式和运行时必须匹配；不能仅因为制品体积变小，就假设任意推理引擎都能直接加载。
一个可移植的交付单元通常包含：
- 已量化的模型文件、分词器和必要配置；
- 明确版本的 CUDA、Python 和推理依赖；
- 健康检查接口；
- 推理接口及请求上限；
- 模型加载完成后才返回成功的就绪状态。
可以这样实践：假设团队已经制作了一个能加载 Unsloth 量化制品的自定义镜像，并暴露 8080 端口、/ping 健康检查和 /invocations 推理接口。先在 GPU 主机上验证镜像，再推送到 Amazon ECR。请替换区域、账户 ID、镜像名称和本地模型目录。
set -euo pipefail
AWS_REGION="us-east-1"
AWS_ACCOUNT_ID="123456789012"
IMAGE_NAME="unsloth-inference"
IMAGE_TAG="v1"
IMAGE_URI="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${IMAGE_NAME}:${IMAGE_TAG}"
MODEL_DIR="$PWD/model"
aws ecr describe-repositories \
--region "$AWS_REGION" \
--repository-names "$IMAGE_NAME" >/dev/null 2>&1 || \
aws ecr create-repository \
--region "$AWS_REGION" \
--repository-name "$IMAGE_NAME"
aws ecr get-login-password --region "$AWS_REGION" | \
docker login \
--username AWS \
--password-stdin "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"
docker build -t "${IMAGE_NAME}:${IMAGE_TAG}" .
docker run --rm --gpus all -p 8080:8080 \
-v "${MODEL_DIR}:/opt/model:ro" \
"${IMAGE_NAME}:${IMAGE_TAG}"
服务启动后，可以在另一个终端进行最小验证：
curl --fail http://localhost:8080/ping
curl --fail http://localhost:8080/invocations \
-H 'Content-Type: application/json' \
-d '{"prompt":"Explain quantized inference in two sentences.","max_new_tokens":80}'
这里的接口只是可改造的实践约定，并不代表所有 Unsloth 制品都使用相同的加载方式。实际镜像必须根据模型格式和推理引擎调整。
从 EC2 验证，到 SageMaker 托管端点
在 EC2 上，建议使用启动脚本或系统服务拉起容器，并将模型放在持久化存储或启动时从对象存储下载。不要把模型下载、镜像构建和服务启动混成一个无法观测的长脚本。至少要分别记录下载耗时、模型加载耗时和首次推理耗时。
当镜像接口稳定后，可以迁移到 SageMaker AI。下面是一个可改造的 AWS CLI 流程，假设模型制品已打包上传到 Amazon S3，自定义镜像已推送到 ECR，并且执行角色允许 SageMaker 读取对应资源。实例类型只是占位值，部署前要按模型显存需求替换。
set -euo pipefail
AWS_REGION="us-east-1"
MODEL_NAME="unsloth-quantized-v1"
ENDPOINT_CONFIG="unsloth-quantized-v1-config"
ENDPOINT_NAME="unsloth-quantized-prod"
ROLE_ARN="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
IMAGE_URI="123456789012.dkr.ecr.us-east-1.amazonaws.com/unsloth-inference:v1"
MODEL_DATA_URL="s3://my-model-bucket/unsloth/model.tar.gz"
aws sagemaker create-model \
--region "$AWS_REGION" \
--model-name "$MODEL_NAME" \
--execution-role-arn "$ROLE_ARN" \
--primary-container "Image=${IMAGE_URI},ModelDataUrl=${MODEL_DATA_URL}"
aws sagemaker create-endpoint-config \
--region "$AWS_REGION" \
--endpoint-config-name "$ENDPOINT_CONFIG" \
--production-variants "VariantName=AllTraffic,ModelName=${MODEL_NAME},InitialInstanceCount=1,InstanceType=ml.g5.xlarge,InitialVariantWeight=1.0"
aws sagemaker create-endpoint \
--region "$AWS_REGION" \
--endpoint-name "$ENDPOINT_NAME" \
--endpoint-config-name "$ENDPOINT_CONFIG"
aws sagemaker wait endpoint-in-service \
--region "$AWS_REGION" \
--endpoint-name "$ENDPOINT_NAME"
生产更新时，不要直接覆盖无法追踪的 latest 镜像。为镜像、模型制品和端点配置使用不可变版本，创建新配置后再更新端点。这样出现输出质量下降、运行时崩溃或显存回归时，才能定位并回滚到上一组制品。
在 EKS 或 ECS 中复用容器平台
如果组织已经使用 Kubernetes，EKS 可以把模型服务纳入现有的命名空间、网关、监控和发布策略。下面的清单假设集群已经安装 NVIDIA GPU 设备插件，节点能够拉取 ECR 镜像，并且容器使用一个 GPU。请按实际镜像、节点标签和资源需求修改。
apiVersion: apps/v1
kind: Deployment
metadata:
name: unsloth-inference
namespace: model-serving
spec:
replicas: 1
selector:
matchLabels:
app: unsloth-inference
template:
metadata:
labels:
app: unsloth-inference
spec:
containers:
- name: server
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/unsloth-inference:v1
ports:
- name: http
containerPort: 8080
resources:
requests:
cpu: "2"
memory: 8Gi
nvidia.com/gpu: "1"
limits:
cpu: "4"
memory: 16Gi
nvidia.com/gpu: "1"
readinessProbe:
httpGet:
path: /ping
port: http
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 30
livenessProbe:
httpGet:
path: /ping
port: http
initialDelaySeconds: 180
periodSeconds: 30
nodeSelector:
workload: gpu-inference
---
apiVersion: v1
kind: Service
metadata:
name: unsloth-inference
namespace: model-serving
spec:
selector:
app: unsloth-inference
ports:
- name: http
port: 80
targetPort: http
应用并观察模型加载过程：
kubectl create namespace model-serving --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -f unsloth-inference.yaml
kubectl rollout status deployment/unsloth-inference -n model-serving --timeout=20m
kubectl logs -n model-serving deployment/unsloth-inference --follow
模型加载可能持续数分钟，因此就绪探针和存活探针不能使用同一套激进阈值。否则，容器还在加载权重时就会被反复重启。ECS 中也应采用同样的设计原则：在任务定义中声明 GPU 和内存需求，让服务调度任务，并通过负载均衡器健康检查控制流量进入。选择 ECS 的关键理由通常不是模型性能更高，而是团队已经围绕 ECS 建立了镜像、网络、权限和日志体系。
上线前检查延迟、容量和回滚能力
量化降低了资源需求，但不会自动解决所有生产问题。上下文长度、并发请求数、批处理策略和生成 token 数仍会显著影响显存与尾延迟。部署前至少完成以下检查：
- 在目标 GPU 上验证模型能够完整加载，并记录峰值显存；
- 分别测试短输入、长输入和最大输出长度；
- 记录冷启动、首 token 延迟、总延迟和吞吐量；
- 为输入长度、输出 token 和并发数设置明确上限；
- 监控 GPU 利用率、显存、容器重启、错误率和排队时间；
- 使用不可变镜像标签与模型版本，保留上一版本的配置；
- 在生产流量进入前验证健康检查不会过早放行；
- 检查 IAM、网络边界、日志脱敏和模型制品访问权限。
如果团队还没有成熟的容器平台，可以先用 EC2 验证镜像和模型兼容性，再迁移到 SageMaker AI 端点减少实例运维。已有 Kubernetes 治理体系时，EKS 更容易复用平台能力；已经标准化 ECS 的团队则无需为了一个推理服务额外引入 Kubernetes。最终选择应由运维边界、发布流程和流量特征决定，而不是只比较单次推理速度。