（七）大模型工程落地与部署 10 题！vLLM/QPS 优化 / 高可用，面试实战必备（工程篇）

上篇算法优化笔记发完，很多朋友反馈 "4bit 量化和结构化剪枝的话术直接背，终面真的被问到了"------ 其实算法再好，工程落地才是大模型从 "实验室" 走进 "业务" 的关键！现在大厂招大模型工程师，最看重 "能不能把模型稳定上线、扛住高并发"，我带的 100 + 求职者里，能说清 vLLM 部署细节 + 高可用架构 + 故障排查全流程的，offer 转化率直接提升 85%，甚至有学员靠这部分内容薪资谈高了 30%。

这篇笔记全是工程硬货：从单机单卡到分布式部署的选型、vLLM 的深度优化、高可用架构设计，到突发故障的排查步骤，每个题都带我学员的真实部署案例（含具体命令、配置参数、踩坑记录），没有空洞理论，只有 "能直接落地、能说给面试官听" 的实操细节，想拿大模型工程岗 offer，这篇一定要逐字吃透！

一、终面必问高频题

1. 大模型部署的常见形态（单机单卡、单机多卡、分布式部署）有什么核心差异？适用场景分别是什么？

这题是工程面的 "开门题"，我带的一个求职者只说 "卡越多性能越好"，被面试官追问 "34B 模型用单机多卡还是分布式"，直接卡壳 ------ 这是 70% 求职者的通病，核心是没搞懂 "模型参数量 + 业务流量" 的匹配逻辑。

原理拆解（用 "硬件需求 + 模型支持 + 性能 + 场景" 四维对比，带真实部署数据）

部署形态	硬件需求	支持模型参数量	核心性能指标	适用场景
单机单卡	单张消费级 / 数据中心 GPU（24G/80G）	≤7B（4bit 量化）、≤13B（8bit）	QPS＜10，延迟 200-500ms	原型验证、企业内部小团队（日活＜100）、低流量 API
单机多卡	1 台服务器 + 2-8 张 GPU（如 4 卡 A100 80G）	≤34B（4bit）、≤70B（8bit）	QPS 20-50，延迟 150-300ms	创业公司 API 服务（日活 1k-1w）、中等流量业务
分布式部署	多台服务器 + GPU 集群（如 10 台 4 卡 A100）	＞34B（如 175B、70B）	QPS＞100，延迟 100-250ms	高流量 To C 场景（日活＞10 万）、超大模型部署

关键补充（真实部署踩坑）

• 单机单卡：7B 模型 4bit 量化（GPTQ）用 RTX 3090 24G 刚好能跑，若用 FP16 量化，24G 卡会 OOM，必须搭配 --gpu-memory-utilization=0.85 限制显存占用；
• 单机多卡：34B 模型用 4 卡 A100 80G，通过模型并行（tensor-parallel-size=4）拆分，卡间用 NVLink 通信，避免 PCIe 带宽瓶颈，通信耗时控制在总耗时的 5% 以内；
• 分布式部署：175B 模型用 8 台 8 卡 A100，采用 "模型并行 + 数据并行" 混合策略，跨服务器用 InfiniBand 网络，降低通信延迟。

真实面试易错点（必避！）

❌ 只说 "卡越多越好"，没说通信开销（如无 NVLink 的 4 卡单机，通信耗时占比达 15%）；❌ 混淆模型参数量与 GPU 需求（如说 34B 模型能用单卡 24G，实际 4bit 量化也需 32G 以上）；❌ 不知道分布式部署的核心是 "跨服务器通信优化"，而非单纯加卡。

面试话术（直接背，含追问应对）

"大模型部署的三种形态，核心是按'模型参数量 + 业务流量'选型，没有绝对好坏：

① 单机单卡：用 1 张 24G/80G GPU，支持≤7B（4bit 量化）、≤13B（8bit）模型，QPS＜10，延迟 200-500ms------ 适合原型验证、企业内部小团队用，比如我们之前给某传统企业做内部知识库，用 RTX 3090 部署 7B 量化模型，日活 50 人，完全够用；

② 单机多卡：1 台服务器配 2-8 张 GPU，支持≤34B（4bit）、≤70B（8bit）模型，QPS 20-50，延迟 150-300ms------ 适合中等流量业务，比如创业公司的公开 API，日活 1k-1w，我们用 4 卡 A100 部署 34B 模型，QPS 稳定在 45，延迟 220ms；

③ 分布式部署：多台服务器组成 GPU 集群，支持＞34B 模型（如 175B），QPS＞100，延迟 100-250ms------ 适合高流量 To C 场景，比如某短视频平台的 AI 客服，日活 10 万 +，用 10 台 4 卡 A100 分布式部署，跨服务器用 InfiniBand 通信，通信耗时仅占 3%。

追问应对（面试官常问 "34B 模型选单机多卡还是分布式"）：优先选单机多卡 ------34B 模型 4bit 量化后权重约 17GB，4 卡 A100（80G）足够承载，模型并行的通信开销比分布式小（单机内 NVLink 带宽 3.2TB/s，跨服务器 InfiniBand 仅 200GB/s），延迟更低；若后续流量增长到 QPS＞50，再扩展为分布式集群，这样更节省成本。"

2. 用 vLLM 部署 7B 模型，如何优化 QPS 与响应延迟？（目标：QPS 从 5→20，延迟从 500ms→200ms）

这题是工程面的 "实操题"，我带的一个学员一开始按默认配置部署，QPS 仅 4.8，延迟 520ms，按以下方案优化后，QPS 冲到 23，延迟稳定在 180ms，直接满足了业务的高并发需求。

原理拆解（4 个核心优化方向，含具体配置 + 原理细节）

1. 模型层面：4bit 量化 + 权重优化（减少显存占用，提升推理速度）；
2. vLLM 配置层面：动态批处理 + PagedAttention（核心优化，提升 GPU 利用率）；
3. 部署架构层面：多卡并行 + 模型预热（分摊显存压力，避免首屏延迟）；
4. 请求调度层面：批量转发 + 优先级队列（减少 batch 切换，保障低延迟请求）。

实操步骤（含具体命令 + 参数解释）

步骤 1：模型量化（4bit GPTQ）

• 工具：GPTQ-for-LLaMa 框架，将 Llama 2-7B FP16 量化为 4bit，显存占用从 14GB→6GB；

• 核心命令：

  python quantize.py
  --model ./llama-2-7b
  --wbits 4
  --groupsize 128
  --save ./llama-2-7b-Q4_K_M.gguf

• 关键参数：--groupsize=128（平衡精度与速度，比 groupsize=64 快 20%，精度仅降 1%）。

步骤 2：vLLM 核心配置（动态批处理 + PagedAttention）

• 启动命令（2 卡 RTX 3090 部署）：

  vllm serve ./llama-2-7b-Q4_K_M.gguf
  --tensor-parallel-size=2 \ # 多卡并行，分摊显存
  --max-num-batched-tokens=2048 \ # 单batch最大token数，越大QPS越高
  --max-batch-size=32 \ # 单batch最大请求数，匹配GPU承载能力
  --gpu-memory-utilization=0.85 \ # 显存利用率，留15%缓冲
  --port=8000
  --enable-paged-attention=True # 启用PagedAttention，减少显存碎片化

• 参数解释：

  • --max-num-batched-tokens=2048：根据 GPU 显存设置，24G 卡单 batch 最大支持 2048token，避免显存溢出；
  • PagedAttention 原理：将注意力层的 key/value 按 "页" 管理，像操作系统内存分页，避免整段分配显存，碎片化减少 60%，GPU 利用率从 40%→90%。

步骤 3：部署架构优化（多卡并行 + 模型预热）

• 多卡并行：2 卡部署后，单卡显存占用从 6GB→4.2GB，支持更大 batch；

• 模型预热：启动服务后，发送 10 条测试请求（如 "介绍大模型部署"），让模型权重加载到 GPU 显存，首屏延迟从 1.1s→190ms；

• 测试命令（curl）：

  curl http://localhost:8000/v1/completions
  -H "Content-Type: application/json"
  -d '{"prompt": "介绍大模型部署", "max_tokens": 200, "temperature": 0.7}'

步骤 4：请求调度优化（Nginx 批量转发 + 优先级）

• Nginx 配置（批量转发）：

nginx

http {
    upstream vllm_nodes {
        server 127.0.0.1:8000;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://vllm_nodes;
            proxy_buffering on;  # 启用缓冲，100ms内的请求批量转发
            proxy_buffer_size 16k;
            proxy_buffers 4 64k;
        }
    }
}

• 优先级队列：用 vLLM 的 --priority-levels=2 配置，实时对话请求设高优先级（priority=0），长文本生成设低优先级（priority=1），避免长请求阻塞短请求。

真实面试易错点

❌ 只开启动态批处理，没做模型量化，显存不足导致 batch 上不去；❌ 忽视 --gpu-memory-utilization 设置，显存占满导致动态批处理失效；❌ 不做模型预热，首屏延迟过高，影响用户体验。

面试话术（直接背，含效果数据）

"用 vLLM 部署 7B 模型，4 个步骤就能实现 QPS 从 5→23、延迟从 500ms→180ms：

① 模型量化：用 GPTQ 将模型转为 4bit，显存从 14GB 降至 6GB，推理速度提升 3 倍；

② vLLM 核心配置：开启动态批处理（--max-num-batched-tokens=2048、--max-batch-size=32），启用 PagedAttention 减少显存碎片化，GPU 利用率从 40% 冲到 90%；

③ 多卡并行 + 预热：2 卡部署分摊显存，模型预热后首屏延迟从 1.1s 降至 190ms；

④ 请求调度：Nginx 批量转发 100ms 内的请求，优先级队列保障实时对话延迟。

我之前带学员优化后，QPS 从 4.8 涨到 23，延迟稳定在 180ms，支撑了日活 8000 的 API 服务，完全满足业务需求 ------ 核心是抓住 vLLM 的 PagedAttention 和动态批处理，这两个是提升性能的关键。"

3. 大模型服务的 "高可用" 如何保障？核心措施有哪些？（真实案例：从 99.5%→99.99% 可用性）

这题考察工程架构能力，我带的一个学员给某金融客户做大模型服务，一开始可用性仅 99.5%（全年 downtime 43.8 小时），按以下方案优化后，可用性冲到 99.99%（全年 downtime 仅 4.38 小时），客户直接续签了三年合同。

原理拆解（3 层高可用架构，从 "容错→冗余→监控" 闭环）

1. 服务容错层：避免单点故障，确保请求不丢失；
2. 资源冗余层：硬件 + 存储 + 网络冗余，确保故障快速恢复；
3. 监控告警层：实时感知异常，确保问题及时响应。

具体落地措施（含架构细节 + 实操配置）

层 1：服务容错层（请求不丢失 + 故障无缝切换）

• 多实例部署：同一模型部署 3 个 vLLM 实例（2 个工作 + 1 个备用），通过 Nginx 负载均衡分发请求；
  • 为什么是 3 个？2 个实例故障概率＞3 个，3 个实例能满足 "故障时仍有 2 个可用"，可用性达 99.9% 以上；
• Nginx 配置（负载均衡 + 健康检查）：

nginx

upstream vllm_nodes {
    server 192.168.1.100:8000 weight=1;
    server 192.168.1.101:8000 weight=1;
    server 192.168.1.102:8000 weight=1 backup;  # 备用实例
    health_check interval=10000 fails=3 passes=2 uri=/health;  # 10秒检查，3次失败下线
}

• 请求重试 + 超时控制：
  • 超时时间设 5s（比平均延迟高 2 倍），超时后自动重试（最多 3 次）；
  • 非幂等请求（如生成唯一订单号）：用 Redis 记录请求 ID，避免重复生成。

层 2：资源冗余层（故障快速恢复）

• 硬件冗余：GPU 服务器配置 20% 备用节点（如 10 个工作节点 + 2 个备用），工作节点故障时，Kubernetes 5 分钟内启动备用节点；
• 存储冗余：模型权重、配置文件存在 MinIO 分布式存储（3 副本），避免单点存储故障；
• 弹性扩展：用 Kubernetes HPA（Horizontal Pod Autoscaler），触发阈值：QPS＞50 时增加实例数，QPS＜10 时减少，平衡性能与成本。

层 3：监控告警层（异常早发现）

• 核心指标监控（Prometheus+Grafana）：
  • 延迟：P95 延迟＞300ms 告警（警告），＞500ms 严重告警；
  • 错误率：＞1% 警告，＞5% 严重告警；
  • GPU 指标：显存使用率＞85% 警告，＞95% 严重告警；
• 多级告警：
  • 警告：企业微信通知研发群；
  • 严重：短信 + 电话通知运维；
  • 紧急（所有实例故障）：升级至技术负责人；
• 日志分析：用 ELK 存储日志，记录字段：请求 ID、输入输出、耗时、错误信息、GPU 使用率，便于排查问题（如某类输入导致模型崩溃）。

真实面试易错点

❌ 只部署 2 个实例，故障时无备用，可用性不足；❌ 监控指标不全，只监控 QPS，不监控延迟和 GPU 状态；❌ 无日志分析，故障后无法定位原因。

面试话术（直接背，含效果数据）

"大模型服务高可用的核心是'避免单点故障、快速恢复、早发现异常'，3 层架构能让可用性从 99.5% 提升至 99.99%：① 服务容错：部署 3 个 vLLM 实例（2 工作 + 1 备用），Nginx 负载均衡 + 健康检查，单个实例故障时无缝切换，请求不丢失；设置 5s 超时 + 3 次重试，非幂等请求用 Redis 去重；② 资源冗余：20% 备用 GPU 节点，MinIO 分布式存储（3 副本），K8s 弹性扩展（QPS＞50 扩容），故障 5 分钟内恢复；③ 监控告警：Prometheus 监控延迟（P95＞300ms 告警）、错误率、GPU 状态，ELK 分析日志，多级告警确保 5 分钟内响应。

我之前给金融客户做的项目，优化后可用性从 99.5% 涨到 99.99%，全年 downtime 仅 4.38 小时，完全满足金融级需求 ------ 核心是'冗余 + 监控'，不能只靠多实例，还要有快速恢复和问题定位能力。"

4. 大模型部署后，推理延迟突然升高（从 200ms→1.2s），如何排查原因？（真实案例：30 分钟定位 + 解决）

这题考察故障排查能力，我带的一个学员遇到过类似问题：服务运行 1 个月后，延迟突然从 190ms 涨到 1.2s，按以下流程排查，30 分钟内定位到 "长文本请求占比飙升"，解决后延迟恢复到 195ms。

排查流程（4 步闭环，按优先级排序，含具体命令 + 工具）

步骤 1：硬件资源排查（先排除硬件瓶颈）

• 查 GPU 状态：

  nvidia-smi  # 看显存使用率（是否＞90%）、GPU利用率（是否＜50%/＞95%）、温度（是否＞85℃）

  • 若显存＞90%：可能是动态批处理积累了过多请求，需调整 --max-batch-size；
  • 若 GPU 利用率＜50%：可能是请求量下降，或存在计算瓶颈（如长文本请求过多）；

• 查 CPU / 内存：

  top  # 看CPU利用率（是否＞80%）、内存使用率（是否＞90%）

  • CPU 高：可能是数据预处理耗时（如文本分词），需优化预处理逻辑；

• 查网络：

  iftop  # 看网络带宽（是否＞90%）

  • 带宽高：可能是多实例间通信频繁（如分布式部署），需优化通信策略。

步骤 2：服务配置与请求特征排查（核心排查方向）

• 看 vLLM 日志（找警告 / 错误）：

  tail -f ~/.vllm/logs/server.log  # 查看是否有"batch等待超时""显存碎片化"警告

• 分析请求特征（用 ELK 查询）：

  • 统计请求长度分布：最近 1 小时内，token 数＞1024 的请求占比（学员案例中从 10% 升至 40%）；
  • 统计请求类型：是否有新的请求类型（如长文档摘要）涌入；

• 查实例状态：

  kubectl get pods  # 看vLLM实例是否有重启、 CrashLoopBackOff

步骤 3：模型与依赖排查（排除版本问题）

• 查模型版本：是否误部署了未优化的模型（如 FP16 替代 4bit 量化模型）；

• 查依赖库版本：

  pip list | grep vllm  # 看vLLM版本是否最近更新（如从0.2.0→0.3.0，可能有性能bug）

  • 若更新过版本：回滚到稳定版本（如 vllm==0.2.0），测试延迟是否恢复；

步骤 4：基线性能测试（验证是否为普遍问题）

• 用固定测试请求验证：

  # 发送短文本请求（128token）
  curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{"prompt": "介绍大模型部署", "max_tokens": 200}'

  • 若短文本延迟正常（200ms），说明是长文本请求导致；
  • 若短文本延迟也高，说明是硬件 / 模型 / 依赖问题。

真实案例排查结果

• 学员案例：步骤 2 中发现，长文本请求（＞1024token）占比从 10% 升至 40%，vLLM 动态批处理中，长文本占用更多 GPU 资源，导致整体延迟升高；
• 解决方案：
  • 限制单请求最大 token 数（--max-model-len=2048）；
  • 给长文本请求单独部署实例，避免影响短文本请求；
• 效果：延迟从 1.2s 降至 195ms。

真实面试易错点

❌ 排查顺序混乱，先查模型再查硬件，浪费时间；❌ 不分析请求特征，盲目调整 vLLM 配置；❌ 无基线测试，无法判断是普遍问题还是特定请求问题。

面试话术（直接背，含排查命令）

"推理延迟突然升高，按'硬件→服务→模型→基线'4 步排查，30 分钟内就能解决：① 硬件排查：用 nvidia-smi 查 GPU 显存（是否＞90%）、利用率，top 查 CPU，iftop 查网络，排除硬件瓶颈；② 服务排查：看 vLLM 日志找警告，用 ELK 分析请求特征（如长文本占比是否飙升），查实例是否重启；③ 模型排查：确认模型版本（是否误部署非量化模型）、依赖库版本（如 vllm 是否回滚）；④ 基线测试：用固定短文本请求验证，判断是普遍问题还是特定请求问题。

我之前带学员排查过类似问题，30 分钟内定位到'长文本请求占比从 10% 升至 40%'，限制单请求最大 token 数 + 单独部署长文本实例后，延迟从 1.2s 恢复到 195ms------ 核心是'先定位范围，再细化排查'，不要盲目调整配置。"

5. 大模型 "模型更新" 的常见策略有哪些？如何避免更新过程中服务中断？

这题考察工程细节，小白容易只说 "直接替换模型"，没说更新策略的选择逻辑，导致服务中断（如用户请求中模型切换，返回错误）。

原理拆解（3 种更新策略，含适用场景 + 实操步骤）

更新策略	核心逻辑	适用场景	避免中断的关键操作
蓝绿部署	部署 "蓝环境"（旧模型）+"绿环境"（新模型），测试通过后切换流量	重大更新（如模型架构变更、大版本升级）	绿环境测试通过后，Nginx 平滑切换流量（无停机）
滚动更新	逐步替换旧模型实例（如 3 个实例，每次替换 1 个）	小更新（如微调后的模型、小版本优化）	每次替换后测试健康状态，通过再替换下一个
金丝雀发布	先将 1%-5% 流量导入新模型，监控无异常后全量切换	风险高的更新（如未知效果的微调模型）	流量逐步提升（1%→10%→30%→100%），异常回滚

实操步骤（以蓝绿部署为例）

1. 部署绿环境（新模型）：

   启动新模型实例（端口8001）

   vllm serve ./new-model-Q4_K_M.gguf
   --tensor-parallel-size=2
   --port=8001

2. 测试绿环境：发送 100 条测试请求，验证延迟、准确率正常；

3. Nginx 平滑切换流量：

nginx

upstream vllm_green {
    server 127.0.0.1:8001;
}
# 切换时修改proxy_pass为vllm_green，无需重启Nginx

1. 监控绿环境：观察 10 分钟，无异常则保留，有异常则切回蓝环境。

真实面试易错点

❌ 直接停止旧模型再启动新模型，导致服务中断；❌ 不测试新模型直接全量切换，出现问题无法快速回滚；❌ 金丝雀发布无流量限制，异常时影响范围大。

面试话术（直接背）

"大模型模型更新有 3 种策略，核心是'先测试、再切换、可回滚'，避免服务中断：① 蓝绿部署：部署旧模型（蓝）+ 新模型（绿），测试通过后 Nginx 平滑切换流量 ------ 适合重大更新（如模型架构变更），无停机时间；② 滚动更新：逐步替换旧实例（如 3 个实例每次换 1 个），测试通过再换下一个 ------ 适合小更新（如微调模型），不影响整体服务；③ 金丝雀发布：先导 1%-5% 流量到新模型，无异常再逐步扩至 100%------ 适合高风险更新，异常时可快速回滚。

避免中断的关键：新模型必须先测试（延迟、准确率、稳定性），切换时保持旧模型运行，直到新模型验证无误再下线，确保有回滚通道 ------ 我之前做的项目，用蓝绿部署更新模型，服务零中断，用户无感知。"

6. 如何用 Docker+Kubernetes 部署大模型服务？核心配置是什么？

这题考察容器化部署能力，现在大厂几乎都用 K8s 部署，小白若说 "直接用命令启动"，会显得缺乏工程经验。

核心步骤（含 Dockerfile+K8s 配置）

步骤 1：编写 Dockerfile（封装 vLLM 服务）

FROM nvidia/cuda:12.2.0-runtime-ubuntu22.04

# 安装依赖
RUN apt-get update && apt-get install -y python3-pip
RUN pip install vllm==0.3.0 torch==2.2.0

# 复制模型（或挂载NFS）
COPY ./llama-2-7b-Q4_K_M.gguf /model/

# 暴露端口
EXPOSE 8000

# 启动命令
CMD ["vllm", "serve", "/model/llama-2-7b-Q4_K_M.gguf", "--tensor-parallel-size=2", "--max-batch-size=32", "--port=8000"]

步骤 2：构建 Docker 镜像

docker build -t llm-vllm:v1 .
# 推送到镜像仓库（如Harbor）
docker tag llm-vllm:v1 harbor.example.com/llm/llm-vllm:v1
docker push harbor.example.com/llm/llm-vllm:v1

步骤 3：编写 K8s 配置文件（llm-deployment.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-vllm
spec:
  replicas: 3  # 3个实例，高可用
  selector:
    matchLabels:
      app: llm-vllm
  template:
    metadata:
      labels:
        app: llm-vllm
    spec:
      containers:
      - name: llm-vllm
        image: harbor.example.com/llm/llm-vllm:v1
        resources:
          limits:
            nvidia.com/gpu: 2  # 每个实例2张GPU
        ports:
        - containerPort: 8000
        livenessProbe:  # 健康检查
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10
        volumeMounts:
        - name: model-storage
          mountPath: /model  # 挂载NFS存储，避免镜像过大
      volumes:
      - name: model-storage
        nfs:
          server: 192.168.1.200
          path: /nfs/models
---
# 服务暴露（NodePort/LoadBalancer）
apiVersion: v1
kind: Service
metadata:
  name: llm-vllm-service
spec:
  type: LoadBalancer
  selector:
    app: llm-vllm
  ports:
  - port: 80
    targetPort: 8000

步骤 4：部署到 K8s

kubectl apply -f llm-deployment.yaml
# 查看部署状态
kubectl get pods
kubectl get svc llm-vllm-service  # 获取外部访问IP

核心配置解释

• 资源限制：nvidia.com/gpu:2（指定 GPU 数量），避免资源争抢；
• 健康检查：livenessProbe，30 秒初始化后，每 10 秒检查 /health 接口，不健康则重启；
• 存储挂载：用 NFS 挂载模型，避免 Docker 镜像过大（模型文件通常数 GB）；
• 服务类型：LoadBalancer，对外暴露服务，适合云环境。

真实面试易错点

❌ Docker 镜像中包含模型文件，导致镜像过大（数 GB），推送 / 部署慢；❌ 未配置健康检查，实例不健康时无法自动重启；❌ K8s 资源限制不足，导致 GPU 显存溢出。

面试话术（直接背，含核心配置）

"用 Docker+K8s 部署大模型服务，核心是'封装标准化 + 部署高可用 + 存储优化'，4 步就能落地：① 编写 Dockerfile：基于 CUDA 镜像，安装 vLLM 依赖，复制模型（或挂载 NFS），暴露端口；② 构建镜像：推送到私有仓库（如 Harbor），方便 K8s 拉取；③ K8s 配置：部署 3 个实例（高可用），指定 GPU 资源（nvidia.com/gpu:2），配置健康检查和 NFS 存储挂载；④ 部署启动：kubectl apply 部署，通过 LoadBalancer 暴露服务。

核心配置要点：① 存储挂载：用 NFS 挂载模型，避免镜像过大；② 健康检查：livenessProbe 检查 /health 接口，确保实例健康；③ 资源限制：指定 GPU 数量和显存使用，避免资源争抢 ------ 我之前部署的服务，用这套配置稳定运行了 6 个月，无一次因部署问题中断。"

7. 跨地域部署大模型服务，如何优化延迟？（真实案例：从 350ms→120ms）

这题考察跨地域部署能力，小白容易只说 "就近转发"，没说具体的优化方案（如模型副本、缓存），我带的一个学员做跨地域服务时，按以下方案优化后，北京用户延迟从 350ms 降至 120ms。

原理拆解（3 个核心优化方向，含架构逻辑）

1. 地域就近转发（Nginx / 云负载均衡）；
2. 本地模型副本（避免跨地域加载模型）；
3. 缓存优化（高频请求结果缓存）。

实操方案

步骤 1：地域就近转发（Nginx 配置）

• 部署架构：武汉（主地域）+ 北京（副地域），各部署 3 个 vLLM 实例；
• Nginx 配置（按 IP 段转发）：

nginx

http {
    upstream wuhan_nodes {
        server 192.168.2.100:8000;
        server 192.168.2.101:8000;
    }
    upstream beijing_nodes {
        server 192.168.1.100:8000;
        server 192.168.1.101:8000;
    }
    server {
        listen 80;
        server_name llm-api.example.com;
        location / {
            # 武汉IP段转发到武汉节点
            if ($remote_addr ~* "^10.20.*|^202.103.*") {
                proxy_pass http://wuhan_nodes;
                # 武汉节点故障时切北京
                if ($upstream_status ~* "502|503|504") {
                    proxy_pass http://beijing_nodes;
                }
            }
            # 北京IP段转发到北京节点
            if ($remote_addr ~* "^10.10.*|^202.106.*") {
                proxy_pass http://beijing_nodes;
                if ($upstream_status ~* "502|503|504") {
                    proxy_pass http://wuhan_nodes;
                }
            }
            # 其他IP转发到负载低的节点
            proxy_pass http://wuhan_nodes;
        }
    }
}

步骤 2：本地模型副本（避免跨地域加载）

• 武汉和北京节点本地都存储模型副本，避免从武汉 NFS 加载模型（跨地域加载延迟＞100ms）；
• 模型更新：用 NFS 跨地域同步模型，在凌晨低峰期更新，避免影响业务。

步骤 3：缓存优化（Redis 缓存高频请求）

• 缓存高频请求结果（如前 1000 个高频查询），缓存有效期 1 小时；
• Redis 配置（跨地域主从同步）：武汉 Redis 主节点，北京从节点，确保缓存一致性；
• 缓存命中逻辑：用户请求先查 Redis，命中则直接返回，未命中再调用 vLLM。

优化效果

• 北京用户延迟：跨地域加载模型（350ms）→本地副本 + 就近转发 + 缓存（120ms）；
• 可用性：单个地域故障时，自动切换到另一地域，无服务中断。

真实面试易错点

❌ 仅做就近转发，未部署本地模型副本，跨地域加载模型延迟高；❌ 无缓存优化，高频请求重复调用 vLLM，浪费资源；❌ 未配置故障切换，单个地域故障时服务中断。

面试话术（直接背，含效果数据）

"跨地域部署大模型服务，核心是'就近转发 + 本地副本 + 缓存'，3 个方案能让延迟从 350ms 降至 120ms：① 地域就近转发：用 Nginx 按 IP 段转发，武汉用户访问武汉节点，北京用户访问北京节点，避免跨地域传输；② 本地模型副本：每个地域本地存储模型，避免跨地域加载（延迟＞100ms），模型更新在低峰期用 NFS 同步；③ 缓存优化：Redis 缓存前 1000 个高频请求，有效期 1 小时，命中则直接返回，未命中再调用 vLLM。

我之前做的跨地域项目，优化后北京用户延迟从 350ms 降到 120ms，单个地域故障时自动切换，可用性达 99.99%------ 核心是'减少跨地域数据传输'，模型和高频结果都在本地，延迟自然降下来。"

8. 大模型部署时，如何进行 "压力测试"？核心指标是什么？（含测试工具 + 命令）

这题考察工程测试能力，小白容易只说 "用 Locust 测试"，没说具体的测试场景和指标，我带的学员用 Locust 做压力测试，精准评估了服务的最大承载能力。

核心压力测试工具：Locust（Python 编写，支持自定义场景）

步骤 1：编写测试脚本（locustfile.py）

from locust import HttpUser, task, between

class LLMUser(HttpUser):
    wait_time = between(0.002, 0.01)  # 控制QPS：200QPS→wait=0.005
    api_key = "llm-api-key"
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {api_key}"
    }

    # 任务1：短文本请求（128token，占比70%）
    @task(7)
    def short_text_request(self):
        prompt = "介绍大模型部署的核心步骤"
        self.send_request(prompt, max_tokens=200)

    # 任务2：长文本请求（1024token，占比30%）
    @task(3)
    def long_text_request(self):
        prompt = "详细介绍大模型工程落地的全流程，包括模型量化、vLLM部署、高可用架构设计、故障排查、压力测试，每个环节说明核心步骤、工具和注意事项..."
        self.send_request(prompt, max_tokens=500)

    def send_request(self, prompt, max_tokens):
        data = {
            "prompt": prompt,
            "max_tokens": max_tokens,
            "temperature": 0.7
        }
        with self.client.post("/v1/completions", json=data, headers=self.headers, catch_response=True) as response:
            if response.status_code == 200 and "choices" in response.json():
                response.success()
            else:
                response.failure(f"失败：{response.status_code}，响应：{response.text}")

步骤 2：启动 Locust 测试

# 启动Locust Web UI（默认端口8089）
locust -f locustfile.py --host=http://llm-api.example.com

• 访问http://localhost:8089，设置并发用户数（如 1000）、每秒新增用户数（如 100），开始测试。

核心测试指标（需重点关注）

1. QPS：每秒处理的请求数（目标：≥50，根据业务需求调整）；
2. 响应延迟：P50/P95/P99 延迟（如 P95≤300ms，避免少数用户体验差）；
3. 错误率：请求失败比例（目标：＜1%，失败原因：超时、模型崩溃）；
4. GPU 指标：GPU 利用率（目标：≤90%）、显存占用（目标：≤85%）；
5. 稳定性：持续测试 1 小时，指标无明显波动（如 QPS 不下降、延迟不飙升）。

测试场景设计（模拟真实业务）

• 混合请求：短文本（70%）+ 长文本（30%），模拟真实用户分布；
• 峰值测试：逐步提升并发用户数，找到最大 QPS（如并发 1000 时，QPS=65，延迟 P95=280ms，错误率 0.8%）；
• 耐久测试：持续 12 小时测试，验证服务稳定性（如内存泄漏、显存持续上涨）。

真实面试易错点

❌ 仅测试短文本请求，未模拟长文本，测试结果不真实；❌ 只关注 QPS，不关注 P95/P99 延迟，忽略少数用户体验；❌ 测试时间短（＜30 分钟），未发现稳定性问题（如内存泄漏）。

面试话术（直接背，含测试命令）

"大模型部署后的压力测试，核心是'模拟真实场景 + 监控核心指标'，用 Locust 就能落地：① 编写测试脚本：设计混合请求（短文本 70%+ 长文本 30%），模拟真实用户行为；② 启动测试：Locust Web UI 设置并发用户数（如 1000），持续测试 1 小时；③ 关注指标：QPS（目标≥50）、P95 延迟（≤300ms）、错误率（＜1%）、GPU 利用率（≤90%）、稳定性（1 小时无波动）。

我之前做的测试，并发 1000 用户时，QPS=65，P95 延迟 = 280ms，错误率 0.8%，满足业务的高并发需求 ------ 核心是'场景真实 + 指标全面'，不能只看 QPS，还要关注延迟和稳定性，否则上线后会出现用户体验差的问题。"

二、补充高频题（直接背）

1. **Q：大模型部署时，如何选择容器化还是物理机部署？**A：① 容器化（Docker+K8s）：适合多模型部署、跨地域部署、弹性扩展，运维效率高，缺点是有轻微容器开销；② 物理机部署：适合单模型高并发场景（如 QPS＞100），无容器开销，延迟更低，缺点是运维复杂；③ 选型：大厂 / 多模型 / 弹性需求选容器化，单模型高并发选物理机。

2. **Q：模型量化后，如何验证精度损失是否在可接受范围内？**A：① 定量指标：计算 Perplexity（与 FP16 相比，上升＜5% 可接受）、下游任务准确率（如文本生成的 BLEU 分数，下降＜3%）；② 定性分析：人工抽样 100 条生成结果，评估流畅度、事实准确性，优秀率＞90%；③ 业务指标：如客服模型的意图匹配率、知识库问答的准确率，下降＜2%。

3. **Q：大模型服务如何做 "日志脱敏"？**A：① 输入脱敏：用正则表达式替换手机号（138****5678）、身份证号、邮箱等敏感信息；② 输出脱敏：若生成内容含敏感信息（如密码、隐私数据），用 LLM 过滤或替换；③ 日志存储：敏感字段加密存储（如 AES 加密），仅授权人员可解密，符合数据合规要求。

4. **Q：vLLM 相比 TensorRT-LLM，优势是什么？如何选择？**A：① vLLM 优势：开箱即用（无需转格式），动态批处理（PagedAttention），支持更多模型（如 Llama、Qwen），部署简单；② TensorRT-LLM 优势：推理速度快 10%-20%，支持 INT8/FP8 量化优化，适合 NVIDIA GPU；③ 选型：快速部署 / 多模型支持选 vLLM，极致性能 / NVIDIA GPU 选 TensorRT-LLM。

5. **Q：大模型部署时，如何处理 "模型权重版本管理"？**A：① 用 DVC/Git LFS 管理模型权重，记录版本（如 v1.0：初始量化模型，v1.1：微调后模型）；② 每次更新模型时，记录变更日志（如 "v1.1：优化医疗领域微调，准确率提升 5%"）；③ 支持版本回滚，若新模型效果差，可快速切换到历史版本。

6. **Q：大模型服务的 "成本优化" 有哪些方法？**A：① 模型层面：4bit 量化减少 GPU 显存需求（用 24G 卡替代 80G 卡）；② 部署层面：弹性扩展（低峰期减少实例数）、共享 GPU（多模型共享一张 GPU，vLLM 支持）；③ 推理层面：动态批处理提升 GPU 利用率，缓存高频请求减少重复计算。

7. **Q：大模型部署后，如何进行 "日常运维"？**A：① 监控：每日查看 Prometheus 指标（延迟、错误率、GPU 状态），每周生成运维报告；② 日志：定期清理日志（保留 7 天），分析高频错误和慢请求；③ 更新：模型更新在低峰期进行，更新后测试验证；④ 备份：模型权重、配置文件每周备份，避免数据丢失。

工程落地是大模型的 "最后一公里"，这篇笔记的话术 + 命令 + 配置直接背，终面遇到工程问题就能稳拿分