LLM成长笔记（十一）：模型部署与工程化

模型部署与工程化学习博客（通俗原理 + 详细注释 · AI应用强化版）

模型部署是将训练好的模型投入生产的关键环节。这篇博客从实际问题出发 ，用生活化类比 建立直觉，通过术语详解 深入概念本质，再用原理剖析 和可运行代码带你一步步理解。重点覆盖面试中的高频考点。

一、初级篇：快速上线你的模型

1. 🔥 Ollama 本地部署、Modelfile 配置、API 调用

问题

手上有开源模型（如 Llama 3、Qwen 2），如何在本地一键运行并提供 HTTP API？面试官可能问："你用什么工具在本地跑开源模型？"

生活化类比
Ollama 就像 Docker 简化版 + 模型商店 ：你用 ollama pull llama3 下载模型，用 ollama run llama3 启动对话，就像 docker pull 和 docker run 一样简单。无需手动编译、配置 CUDA，开箱即用。

术语详解

Ollama：专为本地运行大模型设计的工具，内置模型量化、GPU 加速、API 服务。支持 macOS/Linux/Windows。
Modelfile：类似 Dockerfile 的配置文件，用于自定义模型参数、系统提示、温度等。
API 调用 ：Ollama 启动后自动在 http://localhost:11434 提供 OpenAI 兼容的 API。

原理

Ollama 底层封装了 llama.cpp（CPU 推理）和 CUDA（GPU 推理），自动检测硬件并选择最优推理引擎。默认使用 Q4_K_M 量化格式 （4-bit），将模型压缩到约 1/4 体积，普通消费级显卡即可运行。它从模型注册表拉取预量化的 GGUF 格式模型，通过 Modelfile 可设置 FROM 基础模型、SYSTEM 提示词、PARAMETER 推理参数。

并发限制 ：Ollama 默认单请求串行处理。如需并发，设置环境变量 OLLAMA_NUM_PARALLEL=4（最多同时处理 4 个请求），但并发越高显存占用越大，需根据显卡性能调整。

演示用例：Ollama 部署 Llama 3 并调用 API

bash 复制代码

# 1. 安装 Ollama（官网：ollama.com 下载安装包）
# 2. 拉取并运行模型（默认使用 Q4_K_M 4-bit 量化，约 2GB）
ollama pull llama3.2:3b          # 下载 Llama 3.2 3B 模型
ollama run llama3.2:3b           # 进入交互式对话（Ctrl+D 退出）

# 3. 查看已安装的模型列表
ollama list                      # 输出模型名称、ID、大小、量化格式

# 4. 创建自定义 Modelfile（添加系统提示和推理参数）
# Modelfile 内容：
# FROM llama3.2:3b               ← 基础模型
# SYSTEM "你是一个专业的 Python 编程助手，回答简洁，给出可运行代码。"  ← 系统提示词
# PARAMETER temperature 0.3       ← 温度参数（0-2，越低越确定）
# PARAMETER top_p 0.9             ← 核采样阈值
ollama create my-coder -f Modelfile  # 创建名为 my-coder 的自定义模型
ollama run my-coder                  # 运行自定义模型

# 5. 启动 API 服务（默认端口 11434，服务随 ollama 命令自动启动）
# 如需并发处理，先设置环境变量：export OLLAMA_NUM_PARALLEL=4
curl http://localhost:11434/api/generate -d '{
  "model": "my-coder",
  "prompt": "用 Python 写一个快速排序",
  "stream": false
}'  # 返回 JSON：{"response":"def quick_sort(arr): ..."}

Python 客户端调用（OpenAI 兼容格式）

python 复制代码

# pip install openai
from openai import OpenAI

# Ollama 的 API 兼容 OpenAI 格式，只需修改 base_url 指向 Ollama 服务
client = OpenAI(
    base_url="http://localhost:11434/v1",    # Ollama 的服务地址（端口 11434）
    api_key="ollama"                         # Ollama 不校验 API Key，但必须传一个占位值
)

# 调用 chat/completions 端点（与调用 OpenAI API 完全相同）
response = client.chat.completions.create(
    model="my-coder",                        # 使用刚才创建的模型名称
    messages=[
        {"role": "user", "content": "用 Python 写一个快速排序函数"}
    ],
    temperature=0.3,                         # 控制生成随机性（0-2，越低越确定）
    max_tokens=200                           # 最大生成 token 数，限制回复长度
)
# 提取回复内容
print(response.choices[0].message.content)

输出结果

python 复制代码

def quick_sort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[len(arr) // 2]        # 取中间元素作为基准
    left = [x for x in arr if x < pivot]    # 比基准小的放左边
    middle = [x for x in arr if x == pivot] # 等于基准的放中间
    right = [x for x in arr if x > pivot]   # 比基准大的放右边
    return quick_sort(left) + middle + quick_sort(right)

# 测试
arr = [3,6,8,10,1,2,1]
print(quick_sort(arr))  # [1, 1, 2, 3, 6, 8, 10]

面试必问 ："怎么本地运行开源模型？"------Ollama 是最快的方案。ollama pull llama3 && ollama run llama3 即可启动，API 兼容 OpenAI 格式。默认使用 4-bit 量化，7B 模型约 4GB 显存即可运行。

2. 🔥 Docker 容器化：Dockerfile 编写，挂载模型文件

问题

模型服务需要一致运行环境（CUDA 版本、Python 依赖），如何将它打包成可移植的镜像，在任何支持 Docker 的机器上运行？

生活化类比
Docker 就像行李箱：你把模型、代码、依赖全部打包进去，到任何地方（云服务器、同事电脑）打开箱子就能用，环境完全一致。

术语详解

Dockerfile：描述如何构建镜像的脚本。包括基础镜像、安装依赖、复制文件、设置启动命令。
镜像（Image） ：构建好的只读模板。docker build -t my-model-server .
容器（Container） ：镜像的运行实例。docker run -p 8000:8000 my-model-server
挂载（Volume Mount） ：将宿主机的文件夹映射到容器内，避免把几十 GB 的模型文件打入镜像。-v /host/models:/app/models
多阶段构建（Multi-stage Build）：在一个 Dockerfile 中定义多个 FROM，构建阶段安装编译工具，运行阶段只复制最终产物，显著减小镜像体积。

原理

Docker 使用分层文件系统，每一条 RUN 指令创建一个只读层，最终叠加成完整镜像。容器运行时在最上层添加一个可写层。模型文件通常通过 -v 挂载而非 COPY 到镜像，因为：① 镜像推送拉取慢（几十 GB）；② 模型更新不需要重建镜像。

前提条件 ：使用 --gpus all 前需在宿主机安装 NVIDIA Container Toolkit （nvidia-container-toolkit），否则 Docker 无法识别 GPU。

演示用例：Dockerfile 部署 vLLM 推理服务

dockerfile 复制代码

# Dockerfile
# 基础镜像：NVIDIA 官方 CUDA 12.1 开发镜像（包含 CUDA 运行时和编译工具）
FROM nvidia/cuda:12.1.0-devel-ubuntu22.04

# 设置工作目录（后续命令都在此目录下执行）
WORKDIR /app

# 安装 Python 3.10 和 pip（先更新源列表，避免下载失败）
RUN apt-get update && apt-get install -y python3.10 python3-pip && \
    rm -rf /var/lib/apt/lists/*   # 清理包缓存，减小镜像体积

# 复制依赖文件（先复制 requirements.txt 可利用 Docker 缓存层）
# 这样代码变更时，依赖安装层可以复用缓存，加速构建
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt  # --no-cache-dir 不缓存下载的包

# 复制应用代码（放在最后，代码变更时前面的层可复用缓存）
COPY . .

# 健康检查：定期检测服务是否就绪
# curl -f 会在 HTTP 状态码非 2xx 时返回非零退出码，触发不健康判定
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
    CMD curl -f http://localhost:8000/health || exit 1

# 声明运行时端口（文档作用，实际映射用 docker run -p）
EXPOSE 8000

# 启动命令：运行 vLLM API 服务
# --model 指向挂载的模型路径（通过 -v 提供，不打包进镜像）
# --host 0.0.0.0 监听所有网卡，允许外部访问
CMD ["python", "-m", "vllm.entrypoints.openai.api_server", \
     "--model", "/models/qwen2-7b", \
     "--host", "0.0.0.0", \
     "--port", "8000"]

# ===== 多阶段构建提示（生产环境推荐） =====
# 如需减小镜像体积，可使用多阶段构建：
# 第一阶段（构建阶段）：安装编译工具，编译 CUDA 扩展
# 第二阶段（运行阶段）：只复制编译好的产物 + 运行时依赖
# 最终镜像可减小 30-50% 体积

构建与运行命令

bash 复制代码

# 安装 NVIDIA Container Toolkit（首次使用 GPU 的 Docker 必须）
# 详见：https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/

# 构建镜像
docker build -t my-vllm-server .

# 运行容器
# --gpus all：将宿主机所有 GPU 暴露给容器（需 nvidia-container-toolkit）
# -v /data/models:/models：将宿主机模型目录挂载到容器内（避免 COPY 几十 GB 模型）
# -p 8000:8000：将宿主机的 8000 端口映射到容器的 8000 端口
docker run --gpus all \
    -v /data/models:/models \
    -p 8000:8000 \
    my-vllm-server

AI 应用场景：Docker 化模型服务确保开发/测试/生产环境一致。模型文件通过挂载而非打包，避免镜像过大。多阶段构建进一步减小镜像体积。

二、中级篇：高性能推理与生产优化

1. 🔥 vLLM 或 TGI 部署优化：连续批处理、PagedAttention、前缀缓存

问题

直接用 HuggingFace Transformers 做推理，一个请求就要占用 GPU，并发能力差。如何提升推理吞吐量，让同一块 GPU 同时服务更多用户？

生活化类比

连续批处理就像餐厅服务员不等上一桌结账就接下一桌，空闲时立刻给新客人点菜。传统批处理必须等整批处理完才能接新请求。
PagedAttention 就像操作系统的虚拟内存分页------把显存中零散的空间整合起来，按页分配，随用随取，不浪费一点空间。
前缀缓存 就像共享笔记------多轮对话中，每轮都重复的 system prompt 只算一次，后续直接复用结果。

术语详解

vLLM：加州大学伯克利分校开源的高性能推理引擎，核心创新是 PagedAttention 和连续批处理。
TGI（Text Generation Inference）：HuggingFace 推出的推理服务器，功能类似 vLLM，支持多种模型。
KV Cache ：Transformer 推理时，每个 token 的 Key 和 Value 向量会被缓存，避免重复计算。一个请求的 KV Cache 显存估算：2 × 层数 × hidden_dim × 已生成 token 数 × 数据类型字节。例如 7B 模型（32 层，4096 维，FP16），生成了 1000 token 时约占用 2 × 32 × 4096 × 1000 × 2 ≈ 0.5 GB。

原理深入：连续批处理 vs 静态批处理

传统推理引擎的静态批处理：收集一批请求（如 8 个）→ 一起推理 → 等所有请求全部生成完 → 返回结果 → 收集下一批。问题在于：如果批次中有一个请求需要生成长文本（如 500 token），其他 7 个请求（只需 50 token）全部被阻塞等待。

复制代码

静态批处理时间线：
|── 等待凑批(8个) ──|── 推理(被最慢请求拖累) ──|── 返回 ──|── 等待下一批 ──|
     GPU 空闲等待          全部串行阻塞               再次空闲等待

连续批处理时间线：
|── 请求1 ──|── 完成，退出 ──|
|── 请求2 ──────────|── 完成 ──|
|── 请求3(新) ──|── 完成 ──|          ← 新请求随时加入，无需等待
|── 请求4(新) ────────|── 完成 ──|
    GPU 持续工作，空闲时间为零

vLLM 的连续批处理在每次推理迭代时动态决定哪些请求参与计算：某个请求生成完（遇到 EOS 或达到 max_tokens）就退出，新请求立刻加入。GPU 利用率始终保持高位，吞吐量提升 10-20 倍。

PagedAttention 的分页管理原理

传统 KV Cache 管理是预分配：每个请求预留最大可能长度的连续显存空间（如 4096 token）。问题是大多数请求实际生成长度远小于最大值，大量预留空间被浪费，且碎片化严重。

PagedAttention 将 KV Cache 分成固定大小的"页"（如每页 16 个 token），按需动态分配：

请求开始时只分配少量页，生成长度增加时再追加新页。
页不必物理连续，通过页表映射逻辑位置。
请求结束立即回收所有页，无碎片残留。

对比：预分配方案显存利用率约 20-30%（大量预留浪费），PagedAttention 可达到 96% 以上。

演示用例：vLLM 部署 Qwen2-7B

bash 复制代码

# 安装 vLLM
pip install vllm

# 启动 OpenAI 兼容 API 服务
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2-7B-Instruct \        # 模型名称（自动从 HuggingFace 下载）
    --host 0.0.0.0 \                         # 绑定 IP，0.0.0.0 表示监听所有网卡
    --port 8000 \                             # 监听端口
    --max-model-len 4096 \                    # 最大上下文长度（限制显存占用）
    --gpu-memory-utilization 0.9 \            # GPU 显存使用率上限（90%，预留10%给系统）
    --enable-prefix-caching \                 # 启用前缀缓存（多轮对话中复用 system prompt）
    --max-num-seqs 256                        # 最大并发请求数（超过排队的会等待）

Python 客户端并发测试

python 复制代码

from openai import OpenAI
import asyncio, time

# 连接到 vLLM 服务
client = OpenAI(base_url="http://localhost:8000/v1", api_key="vllm")

async def send_request(i):
    """
    发送单个请求并返回处理耗时。
    参数 i: 请求编号，用于日志输出。
    返回: 请求耗时（秒）。
    """
    start = time.time()                    # 记录开始时间
    response = client.chat.completions.create(
        model="Qwen/Qwen2-7B-Instruct",
        messages=[{"role": "user", "content": "用一句话介绍 vLLM"}],
        max_tokens=50                      # 限制生成长度，使测试快速完成
    )
    elapsed = time.time() - start          # 计算耗时
    # 打印请求编号、耗时和回复前30字符
    print(f"请求{i}: {elapsed:.2f}s  {response.choices[0].message.content[:30]}...")
    return elapsed

async def benchmark(num_concurrent=10):
    """
    并发发送请求，测试吞吐量。
    参数 num_concurrent: 同时发送的请求数量。
    """
    # 创建多个并发任务
    tasks = [send_request(i) for i in range(num_concurrent)]
    # 等待所有任务完成
    times = await asyncio.gather(*tasks)
    # 输出统计信息
    print(f"\n总请求: {num_concurrent}, 平均耗时: {sum(times)/len(times):.2f}s")

# 运行并发测试
asyncio.run(benchmark(10))

输出结果（示例）

复制代码

请求0: 1.23s  vLLM是加州大学伯克利...
请求1: 1.35s  它是一种高性能的...
...
总请求: 10, 平均耗时: 1.45s

面试常考："如何提升推理吞吐？"------答：使用 vLLM/TGI 的连续批处理，允许新请求动态加入，避免等待整批完成。PagedAttention 按页动态分配 KV Cache，消除显存碎片。组合使用可提升 10-20 倍吞吐量，前缀缓存进一步降低延迟。

2. 🔥 模型量化：GGUF、AWQ、GPTQ 的区别与显存估算

问题

7B 模型 FP16 需要约 14GB 显存，普通消费级显卡（RTX 4060 8GB）跑不动。如何压缩模型体积到消费级显卡可运行的范围？

生活化类比

GGUF 就像把高保真音乐压成 MP3------体积大幅缩小，几乎听不出差别。
AWQ 就像只压缩不那么重要的部分------静音部分用更低码率，高潮部分保持高码率。
GPTQ 就像用算法逐句压缩------需要原来的乐谱（校准数据）才能压缩好。

术语详解

GGUF：llama.cpp 的模型格式，使用 k-quant 量化（Q4_K_M 等），CPU 推理友好，Ollama/LM Studio 默认格式。
AWQ（Activation-aware Weight Quantization）：根据激活值的重要性选择量化精度，重要通道保高精度，不重要的用低精度。GPU 推理专用。
GPTQ（Post-Training Quantization）：逐层量化，需要少量校准数据，精度高但量化过程慢。
显存估算（经验公式） ：
- FP16：参数量 × 2 字节
- 8-bit：参数量 × 1 字节
- 4-bit：参数量 × 0.5 字节
- 需额外加上 KV Cache、激活值等约 1-2GB 开销。

三大量化方案对比

维度	GGUF	AWQ	GPTQ
运行方式	CPU/GPU 混合	GPU	GPU
推理引擎	llama.cpp, Ollama	vLLM, TGI	vLLM, TGI
量化速度	快	较快	慢（需要校准）
精度保持	好	极好	很好
适用场景	本地 CPU/低配 GPU	生产 GPU 部署	精度要求高的 GPU 部署

演示：显存占用对比表（以 Qwen2-7B 为例）

量化方案	模型大小（近似）	适用显存
FP16	14 GB	RTX 3090/4090 (24GB)
8-bit	7 GB	RTX 4060 Ti (16GB)
4-bit (Q4_K_M)	4 GB	RTX 4060 (8GB)
4-bit (AWQ/GPTQ)	4 GB	RTX 4060 (8GB)

面试高频："一个 7B 模型要多少显存？量化后呢？"------FP16 需要 14GB，4-bit 量化约 4GB，加上开销约 5-6GB。

演示用例：用 Ollama 运行量化模型并查看显存

bash 复制代码

# Ollama 默认使用 Q4_K_M 量化（4-bit），自动压缩模型
ollama pull qwen2:7b          # 自动下载量化版（约 4GB）
ollama run qwen2:7b           # 运行，RTX 4060 8GB 即可流畅运行
# 另开终端查看显存占用
nvidia-smi                     # 显示约 5.2GB 显存占用（模型 4GB + KV Cache 约 1GB）

在 vLLM 中使用 AWQ 量化模型

bash 复制代码

# 安装 AWQ 内核加速库
pip install autoawq

# 下载 AWQ 量化版模型并启动服务
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2-7B-Instruct-AWQ \  # AWQ 量化版（由社区或官方提供）
    --quantization awq \                   # 指定量化方式为 AWQ
    --gpu-memory-utilization 0.95          # AWQ 更省显存，可设更高的利用率上限

实际使用：GGUF 适合本地、边缘设备；AWQ/GPTQ 适合服务器 GPU 批量推理。面试中能讲清三者的适用场景和显存差异即可。

3. 🔥 docker-compose 编排应用+模型服务+向量库

问题

完整 AI 应用包含前端、后端 API、模型推理服务、向量数据库等多个组件，如何一键启动和管理？

生活化类比
docker-compose 就像交响乐团的总谱 ：每个乐器（服务）有独立的声部，总谱定义了它们何时进场、怎么配合。docker-compose up 就是指挥棒落下，全体奏响。

术语详解

docker-compose：Docker 官方编排工具，用 YAML 文件定义多个容器的启动顺序、网络、数据卷、环境变量等。
服务（Service）：YAML 中定义的单个容器配置。
depends_on ：定义服务依赖关系，先启动数据库再启动应用。注意：depends_on 只保证启动顺序，不保证服务已就绪（vLLM 加载模型需要几十秒）。生产环境需配合 healthcheck 或 wait-for-it 脚本确保依赖服务真正可用。
网络：compose 自动创建虚拟网络，容器间通过服务名互相访问（如 http://vllm:8000）。

原理
docker-compose.yml 定义了所有服务的镜像、端口、挂载、环境变量。docker-compose up 命令解析 YAML，按依赖顺序启动容器，并创建一个共享网络。容器间通过服务名通信，无需硬编码 IP。

演示用例：docker-compose.yml 编排 RAG 应用

yaml 复制代码

# docker-compose.yml
version: '3.8'                     # Compose 文件版本

services:
  # 1. 向量数据库服务（ChromaDB）
  chroma:
    image: chromadb/chroma:latest  # 官方镜像
    ports:
      - "8001:8000"                # 将宿主 8001 映射到容器 8000
    volumes:
      - ./chroma_data:/chroma/chroma  # 持久化向量数据到本地目录（容器删除数据不丢）
    environment:
      - IS_PERSISTENT=TRUE         # 开启持久化存储

  # 2. 模型推理服务（vLLM）
  vllm:
    image: vllm/vllm-openai:latest # vLLM 官方镜像
    ports:
      - "8000:8000"
    volumes:
      - /data/models:/models       # 挂载模型文件（宿主机路径:容器内路径）
    command: >                     # > 表示多行合并为一行
      --model /models/qwen2-7b
      --host 0.0.0.0
      --port 8000
      --gpu-memory-utilization 0.9
    healthcheck:                   # 健康检查：确认模型是否已加载完成
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s                # 每 30 秒检查一次
      timeout: 10s                 # 超时时间
      retries: 5                   # 连续失败 5 次判定为不健康
    deploy:                        # GPU 资源分配
      resources:
        reservations:
          devices:
            - driver: nvidia       # 使用 NVIDIA GPU
              count: 1              # 分配 1 张 GPU
              capabilities: [gpu]

  # 3. 后端 API 服务
  api:
    build: ./backend               # 从 backend 目录下的 Dockerfile 构建镜像
    ports:
      - "3000:3000"
    environment:
      - VLLM_URL=http://vllm:8000/v1  # 通过服务名访问 vLLM（Compose 内部 DNS）
      - CHROMA_URL=http://chroma:8000 # 通过服务名访问 ChromaDB
    depends_on:                    # 等待这两个服务先启动（但不等它们就绪！）
      - vllm
      - chroma
    restart: unless-stopped        # 崩溃时自动重启（手动停止除外）
    # 生产建议：配合 wait-for-it 脚本或 healthcheck 依赖确保 vLLM 已就绪

启动命令

bash 复制代码

# 启动所有服务（-d 后台运行）
docker-compose up -d

# 查看各服务日志（-f 实时追踪）
docker-compose logs -f api

# 停止并删除所有容器（-v 同时删除数据卷）
docker-compose down

AI 应用场景 ：docker-compose 将模型服务、数据库、API 服务统一编排，适合中小型生产部署和本地开发。depends_on 需配合 healthcheck 确保依赖服务真正就绪。

4. 🔥 生产优化：冷启动、蓝绿部署、流式响应全链路、并发与背压处理

问题

模型服务上线后，可能遇到启动慢、更新导致宕机、高并发下崩溃等问题。如何让服务更稳定、更可靠？

4.1 冷启动优化

问题：vLLM 加载 7B 模型需要 30 秒到 1 分钟，期间请求全失败。如何减少启动时间？

解决方案：

模型预热：启动后立即发送一两个空请求，触发模型加载和 CUDA 编译。

bash 复制代码

# 预热脚本（在服务启动后执行）
curl -s http://localhost:8000/health        # 等待健康检查通过
curl -s -X POST http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model":"qwen2-7b","messages":[{"role":"user","content":"ping"}],"max_tokens":1}' > /dev/null
# 此时模型已加载，第一个真正请求的延迟降低 50% 以上

Docker Compose 健康检查（见 3 节 vllm 服务的 healthcheck 配置），确保模型就绪后才接受外部流量。
持久化缓存 ：使用 --download-dir 预下载模型到持久卷，避免每次启动下载。

4.2 蓝绿部署

问题：更新模型版本时，直接重启服务会导致所有用户短暂不可用。

解决方案：

蓝绿部署：同时运行两套完全相同的服务（蓝 = 旧版本，绿 = 新版本），通过负载均衡切换流量。新版本验证无误后，老版本下线。

Nginx 最小化 upstream 切换示例：

nginx 复制代码

# nginx.conf
upstream model_backend {
    # 蓝环境（当前生产，端口 8001）
    server 127.0.0.1:8001 weight=1;
    # 绿环境（新版本，端口 8002），上线时：
    # 1. 启动绿环境：docker run -p 8002:8000 new-model:v2
    # 2. 测试绿环境：curl http://localhost:8002/health
    # 3. 取消下面注释，重启 nginx，流量切换到绿环境
    # server 127.0.0.1:8002 weight=1;
    # 4. 注释掉蓝环境，再次重启 nginx，蓝环境下线
}

server {
    listen 80;
    location / {
        proxy_pass http://model_backend;  # 将请求转发到 upstream 定义的后端
        proxy_set_header Host $host;      # 保留原始 Host 头
    }
}

4.3 流式响应全链路

问题：用户感知延迟不仅包括模型推理，还包括网络传输、前端渲染。

端到端 SSE 流式链路：

python 复制代码

# 后端 FastAPI 流式端点
from fastapi import FastAPI
from starlette.responses import StreamingResponse

@app.get("/chat/stream")
async def chat_stream(prompt: str):
    async def generate():
        # 逐 token 从 vLLM 获取流式输出
        async for chunk in vllm_client.stream(prompt):  # stream=True
            yield f"data: {chunk}\n\n"                   # SSE 格式
        yield "data: [DONE]\n\n"                         # 结束标记
    return StreamingResponse(generate(), media_type="text/event-stream")

# 前端（JS 极简示例）
# const eventSource = new EventSource('/chat/stream?prompt=你好');
# eventSource.onmessage = (e) => {
#     if (e.data === '[DONE]') eventSource.close();
#     else outputDiv.innerText += e.data;  // 收到一个 token 就立刻显示
# };

4.4 并发与背压处理

问题：高并发时推理请求排队过长，导致超时甚至 OOM。

FastAPI 背压示例：

python 复制代码

from fastapi import FastAPI, HTTPException
import asyncio

app = FastAPI()
# 创建信号量，限制同时处理的请求数为 10
semaphore = asyncio.Semaphore(10)

@app.post("/generate")
async def generate(prompt: str):
    # 如果信号量已满（10个请求在处理中），直接返回 429 而非无限等待
    if semaphore.locked():
        raise HTTPException(
            status_code=429,
            detail="服务繁忙，请稍后重试",
            headers={"Retry-After": "5"}  # 建议客户端 5 秒后重试
        )
    async with semaphore:          # 获取信号量（保证最多 10 并发）
        result = await model.inference(prompt)
    return {"result": result}

# 客户端重试策略（指数退避）：
# 1. 收到 429 → 等 Retry-After 秒 → 重试
# 2. 再次 429 → 等 2×Retry-After 秒 → 重试
# 3. 连续 3 次 429 → 放弃，提示用户

5. ⭐ GPU 云服务与算力平台使用经验

问题

自己没有高端 GPU（如 A100、H100），如何租用云端 GPU 进行模型部署和微调？

生活化类比
GPU 云就像共享汽车：你不用买一辆豪车（A100），出行时按小时租一辆，用完还回去。费用远低于买车。

常用平台：

平台	特点	适合场景
AutoDL	国内性价比高，按小时计费	个人开发者微调/部署
Vast.ai	去中心化租赁，价格低	预算敏感的长时任务
RunPod	Serverless GPU，按秒计费	间歇性推理
AWS SageMaker	全托管，生态完善	企业级生产部署

成本参考（以 7B 模型部署为例）：

GPU	租赁价格（约）	24h/天月成本	能否部署 7B（FP16）
RTX 3090 24GB	1.5 元/小时	~1080 元/月	✅
RTX 4090 24GB	2.5 元/小时	~1800 元/月	✅
A100 40GB	8 元/小时	~5760 元/月	✅（可部署更大模型）

AutoDL 五分钟上手流程：

注册充值：autodl.com，充值 10 元即可开始。
选择 GPU：计费方式选"按量计费"，GPU 选 RTX 3090（1.5 元/时）。
选择镜像 ：社区镜像搜 vllm，选带有 vLLM 预装的镜像。
创建实例：点击"立即创建"，等待 2 分钟分配机器。
上传模型 ：通过 JupyterLab 或 scp 上传模型到 /root/autodl-tmp/（数据盘）。
启动服务：打开终端，运行 vLLM 启动命令（见 2.1 节）。
获取公网 API：AutoDL 提供 SSH 隧道或公网端口映射。

AI 应用场景：GPU 云是个人开发者运行大模型的最经济选择。面试中可能问"你用过哪些 GPU 云平台？"------AutoDL 性价比高，RunPod 适合 Serverless 推理。

AI 应用场景速查表

知识点	核心用途	典型场景
Ollama	本地一键部署模型	开发测试、个人使用
Docker 容器化	环境一致性	模型服务打包分发
vLLM/TGI	高性能推理	生产环境 API 部署
连续批处理	动态请求调度	高并发下提升吞吐
PagedAttention	显存高效管理	减少 KV Cache 碎片
GGUF/AWQ/GPTQ	模型压缩	降低显存需求
docker-compose	多服务编排	完整 AI 应用部署
冷启动优化	缩短服务就绪时间	减少用户等待
蓝绿部署	无中断更新	模型版本平滑升级
流式全链路	降低感知延迟	ChatGPT 式对话体验
并发与背压	防止过载崩溃	高并发服务保护
GPU 云平台	租用算力	无 GPU 或需更大显存

面试模拟题

1. 实操型：怎么在本地运行一个 7B 的开源模型？从下载到提供 API 的步骤是什么？

答案要点 ：Ollama 是最快方案------ollama pull model_name 下载，ollama run model_name 交互，ollama serve 启动 API（端口 11434）。客户端用 OpenAI SDK，将 base_url 设为 Ollama 地址即可。默认使用 Q4_K_M 量化，7B 模型约 4GB 显存可运行。

2. 原理型：vLLM 的连续批处理和 PagedAttention 是什么？为什么能大幅提升吞吐量？

答案要点：连续批处理允许新请求动态加入当前批次，无需等待整批完成，GPU 利用率始终保持高位。PagedAttention 将 KV Cache 分成固定大小的页，按需动态分配，消除显存碎片，利用率从 20-30% 提升到 96% 以上。组合使用可提升 10-20 倍吞吐量。

3. 计算型：一个 13B 模型需要多少显存？4-bit 量化后呢？

答案要点：FP16：13B × 2 字节 = 26GB，需 32GB 以上显卡（如 A100）。4-bit 量化：约 13B × 0.5 = 6.5GB，加上 KV Cache 和系统开销约 8-10GB，24GB 显卡即可运行。

4. 架构型：你有一个 AI 应用（前端+后端+模型服务+向量库），如何用 Docker 部署？更新模型版本时如何保证不中断？

答案要点：用 docker-compose 编排四个服务，通过服务名互相通信。模型更新时采用蓝绿部署------先启动新版模型容器，测试通过后在 Nginx upstream 中切换流量到新版，旧版保持运行一段时间观察后下线。容器间通过健康检查确保依赖服务就绪。

总结

从 Ollama 本地一键部署，到 Docker 容器化和 docker-compose 编排，再到 vLLM 高性能推理的连续批处理和 PagedAttention 原理，模型量化的显存优化，以及生产环境的冷启动、蓝绿部署、并发控制，你已掌握模型工程化的完整技能栈。面试中的高频考点------Ollama 部署、vLLM 优化原理、显存计算、docker-compose 编排------都已覆盖。现在你可以把训练好的模型稳定、高效地部署到任何环境了。