转型AI运维工程师·Day 6：从 Demo 到服务化 —— 第一次遭遇“搬家”与“高并发”

心情： 焦虑中带着兴奋（要把"玩具"变成"产品"了） 任务： 模型量化与迁移、构建无状态推理容器、部署 Fargate 前端、配置 ALB 关键词： Quantization (Int8), g5.12xlarge, s5cmd, Stateless Architecture, Split Frontend/Backend

早上 9:00，CEO 直接下令："YY，昨天那个聊天机器人太棒了。明天全员大会，我要让公司 200 人都能用上这个模型进行内测。你把它部署好，搞个内网网址，别再让我连那什么 SSH 隧道了。"

任务很明确：规模化。但我还没来得及喝咖啡，脑子里的"架构师警报"已经响了：

成本红线： 现在跑在 P4d 上（$32/hr）。如果为了一个聊天服务长期占着它，一个月 2 万多美刀，财务会杀了我。
并发瓶颈： 昨天的 Gradio 和 vLLM 挤在一起，单线程，200 人同时点肯定崩。
存储陷阱： 我不能用 EFS。虽然 EFS 管理方便，但 70GB 的文件在默认吞吐模式下读取太慢，我不希望服务启动要等半小时。

上午 10:00：算账与选型 ------ 为了省钱，把模型"压扁"

首先解决机器太贵的问题。训练（Training）必须用 A100，但推理（Inference）可以用便宜点的 A10G。我看中了 AWS 的 g5.12xlarge 实例：

配置： 4 张 NVIDIA A10G 显卡。
价格： 约 $5.6/hr（比 P4d 便宜了 82%！）。
显存总和： 24GB x 4 = 96GB。

冲突出现了： 我们的 70B 模型，FP16 精度下需要 140GB 显存。 96GB 装不下 140GB。

难道要升到更贵的 g5.48xlarge（192GB 显存， $16/hr）？我不甘心。我找到李博士："能不能把模型变小点？" 李博士说："推理对精度要求没那么高。我们可以做 Int8 量化（Quantization），把权重从 16 位浮点数压成 8 位整数。"

效果立竿见影： 模型体积从 140GB 缩减到 70GB。 70GB < 96GB。完美！我们可以用便宜的机器了。

上午 11:30：告别"有状态" ------ 构建 Docker 镜像

接下来是打包环境。我决定采用 "无状态（Stateless）" 架构。

决策点：模型放哪？

方案 A（EFS 挂载）： 方便同步，但吞吐量受限，启动慢，还有 IO 争抢风险。
方案 B（打入 Docker）： 镜像会变成 70GB 的巨无霸，推送/拉取极其痛苦。
方案 C（S3 + 启动时拉取）： 我选了这个。

1. 编写 Dockerfile (Backend - vLLM):

复制代码

# 基于 NVIDIA 官方 PyTorch 镜像
FROM nvcr.io/nvidia/pytorch:23.10-py3

# 安装 vLLM 和 s5cmd (AWS 上的下载神器，比 aws s3 cp 快 10 倍)
RUN pip install vllm s3fs && \
    curl -L https://github.com/peak/s5cmd/releases/download/v2.2.2/s5cmd_2.2.2_Linux-64bit.tar.gz | tar -xz -C /usr/bin

WORKDIR /app
COPY start.sh /app/
RUN chmod +x /app/start.sh

ENTRYPOINT ["/app/start.sh"]

2. 编写启动脚本 start.sh: 这个脚本体现了云原生的精髓------启动即拉取。

复制代码

#!/bin/bash
# 1. 快速下载模型
# 利用 G5 实例 25Gbps 的带宽，s5cmd 能跑满下载速度
# 70GB 大概只需要 20-30 秒就能下完，比 EFS 快多了
echo "Downloading quantized model from S3..."
s5cmd cp s3://company-ai-models-archive/v1.0-int8/* /model-cache/

# 2. 启动 vLLM 推理服务
# --quantization awq: 开启量化模式
# --max-num-seqs 64: 限制并发数，防止 200 人把显存撑爆 (OOM)
python -m vllm.entrypoints.openai.api_server \
    --model /model-cache/ \
    --quantization awq \
    --tensor-parallel-size 4 \
    --max-num-seqs 64 \
    --host 0.0.0.0 --port 8000

下午 2:00：前后端分离部署 ------ Fargate 登场

为了高可用，我把前端（Gradio）和后端（vLLM）彻底拆开了。

1. 后端 (GPU Layer):

启动了一台 g5.12xlarge。
通过 UserData 运行上面的 Docker 容器。
这台机器现在只负责计算，不负责网页渲染。

2. 前端 (Web Layer):

Gradio 是纯 CPU 应用，跑在 GPU 机器上太浪费。
我把 Gradio 代码打包成另一个轻量级镜像。
部署在 AWS Fargate (Serverless 容器) 上。
配置环境变量：BACKEND_URL = http://<G5的内网IP>:8000。

下午 4:00：网络与负载均衡 ------ 告别 SSH 隧道

现在架构变成了： 用户浏览器 -> ALB -> Fargate (Gradio) -> G5 (vLLM)

操作记录：

创建 ALB (Application Load Balancer):
- 名字：alb-internal-ai。
- 类型：Internal（仅内网访问，为了安全）。
- 监听：HTTPS 443。
Target Group: 指向 Fargate 的 7860 端口。
Route 53: 创建域名 chat.internal.company.com 指向 ALB。

再也不需要告诉老板"先连 VPN，再输 SSH 命令，再打开 localhost"了。现在大家只要在公司内网，浏览器输入域名就能用。

下午 5:30：全员压力测试

我让运维组的几个人先上去狂点，模拟并发。

监控面板 (CloudWatch) 像心电图一样跳动：

网络 I/O: 启动瞬间飙升到 3GB/s（s5cmd 在拉模型），25 秒后回落。启动速度符合预期。
显存: 稳定在 75GB / 96GB。量化后的模型很老实，KV Cache 也在预设范围内。
排队: 当我们模拟超过 64 个并发请求时，vLLM 自动让后续请求排队，而不是直接崩溃。

唯一的插曲： 有一个瞬间 Fargate 报错了。原因是前端 Gradio 处理 WebSocket 连接数过多。我反手在 ECS 控制台把 Fargate 的任务数从 1 个改成 5 个 。 这就是前后端分离的好处： 前端瓶颈？一键扩容 Fargate，几秒钟搞定，完全不影响昂贵的后端 GPU。

下午 6:00：下班总结

今天的改造成就感满满。从一个仅仅能跑通的 Demo，变成了一个高可用、低成本、易扩展的微服务架构。

今日核心决策复盘：

量化 (Quantization): 它是 AI 降本增效的核武器。没有它，我们就得用贵 3 倍的机器。
S3 + s5cmd > EFS: 在大模型场景下，利用 EC2 的高带宽直接拉取 S3，比 EFS 更快、更便宜、更无状态。
分离架构: 把便宜的 CPU 任务（Gradio）移出 GPU 实例，让好钢用在刀刃上。

1. 显存算账：为什么 96GB 的卡能跑 140GB 的模型？

原始困境：
- 模型： 70B 参数，FP16 精度 $\\approx$ 140GB。
- 硬件： g5.12xlarge (4 x A10G) 总显存 = 96GB。
- 直接跑： OOM (Out Of Memory)，装不下。
解决方案：量化 (Quantization)
- 原理： 把权重参数从 16-bit 浮点数 (FP16) 压缩成 8-bit 整数 (Int8) 甚至 4-bit (AWQ)。
- 效果：
  - 体积减半：140GB $\\rightarrow$ 70GB。
  - 速度翻倍：整数运算比浮点运算快。
- 代价： 精度微损（智商稍微下降一点点），但在聊天、摘要等通用任务上几乎无感。
- 结论： 量化是 AI 推理降本的第一神技。 它让我们能用便宜 60% 的显卡跑大模型。

2. 存储对决：为什么放弃 EFS，选择 S3 + s5cmd？

这是传统运维最容易"想当然"的地方。

EFS (Elastic File System) 的坑：
- 吞吐量限制： EFS 的基准吞吐量与容量挂钩。存 70GB 数据，默认吞吐量可能只有个位数 MB/s。
- IO 争抢： 当 10 台机器同时扩容启动时，会挤爆 EFS 带宽，导致启动时间从几分钟变几小时。
- 费用： $0.30/GB/月，还得买预置吞吐量（贵）。
S3 + s5cmd 的优势：
- 带宽利用率： EC2 G5 实例网卡带宽高达 25Gbps。S3 是对象存储，支持高并发读取。
- 工具选型： AWS CLI (aws s3 cp) 是单线程/少线程的，跑不满带宽。s5cmd 是用 Go 写的，支持成百上千个并发连接，能把 25Gbps 网卡跑满。
- 效果： 下载 70GB 只需要 20-30 秒。
- 架构意义： 实现了无状态 (Stateless)。服务不依赖任何共享磁盘，随起随用，这才是云原生的正确姿势。

3. 实例选型：G5 vs P4d vs Inf2

P4d (A100):
- 定位： 训练专用（Training）。
- 特点： 显存大、带宽极高（EFA）、贵（$32/hr）。
- 结论： 拿来跑推理简直是暴殄天物。
G5 (A10G):
- 定位： 推理与图形渲染（Inference）。
- 特点： 性价比高（$5.6/hr）、显存适中（24GB/卡）。
- 结论： 配合量化技术，是目前 70B 模型推理的主力军。
Inf2 (Inferentia2):
- 定位： AWS 自研 AI 芯片。
- 特点： 极其便宜。
- 现状： 生态还在发展中，适配 vLLM 可能有坑，暂不作为首选，但在未来是降本终极方案。

4. 架构解耦：为什么要拆分 Gradio？

Day 5 (All-in-One):
- Gradio (Web) + vLLM (AI) 跑在同一台 GPU 机器上。
- 风险： 网页访问量大时，CPU 飙升，会抢占 GPU 驱动的 CPU 资源，导致推理卡顿。且 Gradio 挂了，整个服务就挂了。
Day 6 (Split):
- 前端 (Fargate): 纯 CPU 任务，便宜，弹性极强（1 秒扩容）。
- 后端 (G5): 纯 GPU 任务，昂贵，专注于计算。
- 中间层 (ALB): 负责流量分发和健康检查。
- 结论： 让 GPU 机器只做 GPU 该做的事。

5. 关键参数解析：`--max-num-seqs`

背景： vLLM 为了加速，会预先在显存里分配一块巨大的 KV Cache（键值缓存）。
问题： 如果并发请求太多（比如 200 人同时发长文本），KV Cache 会耗尽显存，导致 OOM 崩溃。
配置： --max-num-seqs 64。
作用： 设置一道"显存闸门"。
- 哪怕外面有 1000 个请求进来，显卡内部同时也只处理 64 个。
- 多余的请求在 vLLM 内部队列排队（Waiting），而不是让程序崩溃。
- 运维启示： 稳定性 > 响应速度。宁可让用户等 5 秒，也不能让服务挂掉。