面试 · 方案设计型

考察目标：能否从零设计一个系统/平台，展示架构能力和全局视野约 16 题答题框架：需求 → 方案 → 如何落地 → 如何验证 → 如何治理

Q1：设计一个公司内部大模型推理平台#

需求：公司 10 个业务线、20+ 模型、100+ GPU 卡、需要支持实时推理和离线批处理。

架构设计：

text
┌─────────────────────────────────────────────────────┐
│                    业务接入层                          │
│        OpenAI Compatible API / SDK / CLI             │
├─────────────────────────────────────────────────────┤
│                    AI Gateway                        │
│   LiteLLM Proxy（鉴权/Virtual Key/限流/计费/审计）    │
├────────────────────┬────────────────────────────────┤
│      引擎层         │         编排层（可选）          │
│  vLLM / SGLang /   │   NVIDIA Dynamo / llm-d        │
│  TRT-LLM / Triton  │   PD分离 / KV routing          │
├────────────────────┴────────────────────────────────┤
│              算力调度（Volcano/Kueue）                │
│        Queue / Quota / Priority / Preemption         │
├─────────────────────────────────────────────────────┤
│          K8s 集群（GPU Operator + DCGM）             │
│              存储层（PVC/EFS/MinIO）                  │
└─────────────────────────────────────────────────────┘

核心组件：

AI Gateway：LiteLLM 做统一入口，Virtual Key 管理，多模型路由，成本统计
引擎层：vLLM（通用）+ SGLang（Agent/RAG 场景）
算力调度：Volcano 管理训练/推理/评测任务的 GPU 资源池
可观测：Prometheus + Grafana + OTel GenAI + Langfuse
模型管理：MLflow Registry + Argo Eval Pipeline

如何落地：

Phase 1：单引擎 vLLM + LiteLLM 网关，支撑基础推理
Phase 2：加 Model Registry + Eval Pipeline，平台化模型上线
Phase 3：加 Volcano 调度 + 多租户配额
Phase 4：引入编排层 + PD 分离（大规模时）

如何验证：

功能：10 个业务线都能通过 Virtual Key 调用
性能：TTFT P95 < 1s，TPOT P95 < 50ms
成本：按 Team/Model 维度统计准确
稳定性：可用性 > 99.9%

如何治理：预算告警 + 闲置回收 + 模型评测准入门禁 + 灰度回滚 + 审计日志。

面试官追问

为什么不直接用云厂商托管推理（Bedrock/Vertex/百炼）省事？ 托管上手快、免运维，但：① 规模上来后按 token 计费远贵于自建；② 数据出域 / 合规（国内备案、私有数据不能出公网）；③ 无法深度优化（PD 分离、分级 KV、自定义量化、国产卡受限）；④ 供应商锁定。有规模 + 合规 + 要压成本 → 自建；早期验证 / 无合规压力 / 流量小 → 先用托管，别一上来就自建全套。
上线后拿什么证明平台有效？ 不是"能跑就行"：SLA 达标率（TTFT/TPOT P95）、GPU 有效利用率（目标 60-80%，太低=浪费、太高=排队）、单位 token 成本环比下降、成本归因准确率（能对上 Provider 账单）、模型上线周期（提交→灰度上线时长）、故障 MTTR。

Q2：设计一个 OpenAI-Compatible 模型服务网关#

需求：统一接入多个 LLM Provider（OpenAI/Anthropic/自建），提供鉴权、限流、计费、Fallback。

核心能力：

多 Provider 统一接入：OpenAI、Azure、Anthropic、自建 vLLM 统一成 OpenAI 格式
Virtual Key 体系：每个业务线独立 Key，绑定模型白名单、预算上限、RPM/TPM 限制
模型路由：alias 抽象（如 fast-medium → gpt-4o / qwen-max 轮询）
Fallback：主模型故障 → 自动切备用；上下文超限 → 自动切大上下文模型
成本审计：每次请求记录 tokens + spend，按 Team/Model/Feature 维度报表

技术选型：LiteLLM Proxy + Redis（路由状态）+ PostgreSQL（SpendLogs）

yaml
# Model alias 设计
fast-small: gpt-4o-mini / qwen-turbo / llama-8b
fast-medium: gpt-4o / qwen-max / llama-70b
smart: claude-sonnet / gpt-5.4 / deepseek-v3
local-only: vllm-internal（不 fallback 到公网）

如何落地：部署 LiteLLM Proxy + PostgreSQL；为每个 Team 生成 Virtual Key；配置 model_list + router_settings + fallbacks。

如何验证：主模型故障时自动切 fallback；Virtual Key 超预算时拒绝请求；成本统计与 Provider 账单对账。

如何治理：预算告警 + Fallback 触发率监控 + Key 定期审计 + 路由策略评审。

Q3：设计一个多模型路由系统#

需求：多个模型后端，按成本/延迟/负载/KV 命中智能路由。

路由策略层次：

text
请求 → Gateway
        ├─ 鉴权（Virtual Key → 可用模型白名单）
        ├─ 路由决策
        │   ├─ cost-based：选最便宜的
        │   ├─ latency-based：选历史延迟最低的
        │   ├─ usage-based：选当前负载最低的
        │   └─ kv-aware：选 KV Cache 命中最长的节点
        ├─ Fallback（如果主模型不可用）
        └─ 限流（超过 RPM/TPM → 拒绝或排队）

灰度路由：同一 model alias 下多个后端（v1/v2），按比例分流，配合监控评估新版本效果。

如何落地：LiteLLM routing_strategy: usage-based-routing-v2；编排层（Dynamo）做 KV-aware routing。

如何验证：路由分布均匀（usage-based）；KV 命中率提升（kv-aware）；灰度比例准确。

如何治理：路由策略可热更新；路由决策日志可追溯；定期评审路由效果。

Q4：设计一个 AI 推理服务可观测体系#

需求：全面观测推理服务的延迟、资源、成本、质量。

三层指标体系：

text
系统指标（延迟 + 资源）
├─ TTFT / TPOT / e2e latency / P50 P95 P99
├─ Queue Length / num_running_requests
├─ GPU Util / 显存 / KV Cache Usage
├─ NIC 带宽 / NCCL 错包（分布式场景）

成本指标
├─ 单请求成本（prompt_tokens × input_price + completion_tokens × output_price）
├─ 租户维度成本（Team/Key 聚合）
├─ 模型维度成本（底层 model 聚合）

效果指标
├─ 质量漂移（同一 benchmark 的新旧版本差异）
├─ 幻觉率（RAG 场景生成内容 vs 检索文档的一致性）
└─ 在线采样评估（随机采样生产流量人工评分）

技术栈：Prometheus + Grafana + OpenTelemetry GenAI 语义约定 + Jaeger/Tempo + Loki + Langfuse

如何落地：

vLLM/SGLang 启用 /metrics + OTel trace
LiteLLM 启用 SpendLogs + OTel
DCGM Exporter 采集 GPU 指标
Grafana 建 Dashboard（延迟/资源/成本/质量四块）
Langfuse 记录全量 LLM 调用

如何验证：指标覆盖全链路；告警及时触发；Trace 能跨服务串联。

如何治理：SLA 监控 + 成本预算告警 + 质量漂移检测 + 定期评测。

Q5：设计一个 GPU 成本统计与治理系统#

需求：按 Team/Model/Feature 维度统计 GPU 成本，治理闲置和超支。

成本采集：

网关层：LiteLLM SpendLogs → 每次请求的模型、token、spend
调度层：Volcano/Kueue queue_usage → GPU 占用时长
资源层：DCGM Exporter → GPU 利用率、功耗

成本归因：

sql
-- 按 Team × Model 的花费矩阵
SELECT team, model, SUM(spend), SUM(tokens)
FROM spend_logs
GROUP BY team, model

-- GPU 闲置成本 = (1 - 平均利用率) × GPU 租金
SELECT
    node,
    (1 - AVG(gpu_utilization)) * gpu_hourly_cost AS idle_cost
FROM dcgm_metrics
GROUP BY 1;

成本治理：

预算预警：单 Team 日消费 > 阈值 → 钉钉/企微通知
闲置告警：GPU 利用率 < 20% 持续 30min → 回收
模型路由优化：按成本将请求优先路由到便宜模型
Scale-to-zero：低频模型空闲时缩到零

如何落地：LiteLLM SpendLogs → PostgreSQL；DCGM → Prometheus；Grafana 成本看板。

如何验证：成本报表与 Provider 账单对账；闲置 GPU 被及时回收。

如何治理：月度成本评审；预算上限自动拦截；闲置资源自动回收。

Q6：设计一个模型灰度发布和回滚流程#

需求：新模型安全上线，出问题秒级回滚。

text
新模型上线流程
├─ 1. 评测通过（Eval Pipeline 自动门禁）
├─ 2. 注册到 Model Registry（标记为 staging）
├─ 3. 部署到 K8s（v2 Deployment）
├─ 4. 网关 10% 流量切到 v2
│   ├─ 观察 TTFT/TPOT/P99 延迟是否恶化
│   ├─ 观察质量指标（采样评估）
│   └─ 观察错误率
├─ 5. 无异常 → 50% → 100% 逐步放量
├─ 6. 全量后注册为 production（老版本标记 archived）
└─ 异常 → 网关切回 v1（秒级） + Registry 回滚

关键设计：

保留最近 3 个 production 版本的权重/engine
回滚必须秒级见效（网关层切流量，不依赖 Pod 重启）
灰度期间日志和 metrics 按 version 维度拆分

如何落地：LiteLLM 路由规则按比例分流；MLflow Registry 管理阶段；Argo Workflows 编排流程。

如何验证：灰度比例准确（10%/50%/100%）；回滚秒级生效；metrics 按 version 拆分。

如何治理：灰度期间在线采样评估；回滚演练；老版本保留策略。

Q7：设计一个 Model Registry + Eval Pipeline#

需求：模型从上传到上线的自动化评测和准入。

Model Registry：

元信息：模型名、版本、阶段（staging/production/archived）
制品路径：权重（S3/MinIO）、tokenizer、engine 配置
评测结果：通用 benchmark + 业务专项 + 安全评测
部署配置：TP size、max-model-len、gpu-memory-utilization

Eval Pipeline（Argo Workflows / Kubeflow Pipelines）：

text
新模型上传 → 触发 Pipeline
├─ Step 1: 加载模型 + 部署临时推理实例
├─ Step 2: 通用能力评测（MMLU/HumanEval/C-Eval）
├─ Step 3: 业务专项评测（真实 prompt 集 + 自动评分）
├─ Step 4: 安全评测（Prompt Injection 防御 / 有害内容拒答）
├─ Step 5: 性能评测（TTFT/TPOT/QPS/显存 基线对比）
├─ Step 6: 合规评测（违法内容生成测试、敏感词检测）
└─ Step 7: 汇总结果 → 写入 Registry + 准入判定

如何落地：MLflow Registry + Argo Workflows + 对象存储 + 评测数据集管理。

如何验证：Pipeline 自动触发；评测结果写入 Registry；准入判定准确。

如何治理：评测数据集定期更新；准入门禁自动化；评测结果可追溯。

Q8：设计一个多租户 AI Infra 平台#

需求：多团队共享 GPU，隔离 + 公平 + 成本归因。

租户模型：

Team：组织单位（如 NLP 团队、推荐团队）
Virtual Key：每个 Team 下按环境（dev/prod）分 Key
权限：Key 绑定可用模型白名单
配额：RPM/TPM + 月度预算上限
隔离：纯网关层软隔离（共享 GPU 池，通过 Queue/Quota 保障公平）
KV 缓存隔离：前缀缓存默认不跨租户复用（缓存 key 带 tenant_id），只对公共前缀开放共享——防止攻击者通过 TTFT 命中差异探测别的租户输入过什么（时序侧信道，见 3-Q17）

资源池设计（Volcano 层级队列）：

text
root
└── ai-org（公司 AI 总配额）
    ├── team-nlp（weight=30, guarantee=64 GPU）
    ├── team-recommend（weight=30, guarantee=64 GPU）
    ├── team-research（weight=20, guarantee=32 GPU）
    └── emergency（weight=100, 不可抢占）

如何落地：LiteLLM Virtual Key + Volcano Queue + Grafana 成本看板。

如何验证：租户间隔离（一个 Team 爆量不影响其他）；配额生效；成本准确归因。

如何治理：预算上限自动拦截；借用机制（cohort）；闲置资源回收。

Q9：设计一个训练、推理、评测一体化平台#

需求：训练产出 → 评测 → 推理部署，全链路平台化。

text
训练子系统           评测子系统          推理子系统
┌──────────┐      ┌──────────┐       ┌──────────┐
│ PyTorch  │      │ Eval     │       │ vLLM /   │
│ DeepSpeed│ ───→ │ Pipeline │ ───→  │ SGLang   │
│ Volcano  │      │ Registry │       │ Gateway  │
└──────────┘      └──────────┘       └──────────┘
       │                │                  │
       └────────────────┼──────────────────┘
                        │
              统一的 GPU 资源池
              (Volcano / Kueue)

关键设计：

训练和推理共享 GPU 池但有独立调度策略
紧急推理需求可抢占实验性训练任务
评测结果自动触发发布流程

如何落地：Kubeflow Training Operator（训练）+ Argo Workflows（评测）+ vLLM（推理）+ Volcano（调度）。

如何验证：训练→评测→发布全链路自动化；资源池利用率 > 80%。

如何治理：优先级策略（推理 > 训练 > 实验）；抢占配合 checkpoint；成本分摊。

Q10：设计一个引擎层（vLLM/SGLang）+ 编排层（Dynamo）的多节点推理平台#

需求：大规模推理，需要 PD 分离 + KV 路由。

架构：

text
编排层（NVIDIA Dynamo）
├─ Disaggregated Serving：将 prefill/decode 分配到不同节点
├─ KV-aware Routing：按 KV Cache 命中率路由请求
└─ 动态 GPU 分配：根据负载调整 prefill/decode 节点比例

引擎层
├─ Prefill 节点组：2 台 H100 × 8 卡（SGLang，RadixAttention 复用 KV）
├─ Decode 节点组：4 台 H100 × 8 卡（vLLM，多个实例 DP 横扩）
└─ KV 传输网络：InfiniBand 400Gbps

网关层
└─ LiteLLM：模型 alias + 鉴权 + 成本统计

如何落地：

Prefill 节点：SGLang（RadixAttention 复用前缀 KV）
Decode 节点：vLLM（多实例 DP，横向扩展）
KV 传输：400Gbps InfiniBand + GPU Direct RDMA
Dynamo 做 Router + Scheduler

如何验证：TTFT 降低 30-50%（prefill 独立优化）；吞吐提升 2-3x（decode 可无限扩展）；KV 传输不是瓶颈（NIC < 80%）。

如何治理：prefill/decode 节点比例动态调整；KV 传输延迟监控；KV-aware routing 命中率。

面试官追问

不上 PD 分离 / 编排层行不行？为什么不用更简单的方案？ 大多数场景应该先不上——PD 分离引入 KV 跨节点传输、两套硬件、编排复杂度，只有当单节点混部时 prefill/decode 互相干扰严重、且规模大到能摊薄复杂度才值得。替代阶梯：先用单引擎 + Chunked Prefill 缓解干扰 + DP 横扩吞吐 + 分级 KV 省 prefill；顶不住再上 PD 分离。别为"架构先进"上 PD 分离。
上线后拿什么证明 PD 分离真的赚了？ 对比开/关：TTFT P95（应降 30-50%）、单卡有效 tokens/s、KV 传输是否成新瓶颈（NIC < 80%、KV 传输延迟占 TTFT 比例）、以及综合单位成本——分离多用了一套硬件，要算净账，不能只看延迟降了。

Q11：设计一套符合国内备案合规的模型服务#

需求：满足《生成式人工智能服务管理暂行办法》的备案要求。

备案四要素实现：

text
语料安全 → 训练数据审查（去重去毒 + 内容检查报告）
生成内容安全 → 输入输出双重审核
  ├─ 敏感词过滤（实时）
  ├─ LlamaGuard 内容安全分类（输入+输出）
  └─ NeMo Guardrails 对话控制
问题拒答 → 安全评测验证拒答率 > 98%
自愿承诺 → 法人签署备案承诺书

上线公示 → 产品页面标注模型名称 + 备案号

技术实现：在每个 LLM 调用的前后插入安全闸口（LiteLLM Guardrails + LlamaGuard），违规直接拒绝。

如何落地：

LiteLLM Proxy 配置 Guardrails 插件
输入侧：敏感词过滤 + LlamaGuard 分类
输出侧：LlamaGuard 分类 + 违规拦截
审计日志：全量 Prompt + Response + Safety Check 记录

如何验证：违法内容生成率 = 0；拒答率 > 98%；备案号公示在产品界面。

如何治理：安全评测定期跑；攻击样本库更新；审计日志合规抽查。

Q12：设计一个 RAG 场景的分级 KV 复用 + 成本治理方案#

需求：RAG 场景每次请求带相同 system prompt + 知识库文档，前缀高度重复。

分级 KV 设计：

text
L0（GPU HBM）：当前热门文档的 KV Cache
L1（CPU DRAM）：LRU 淘汰文档的 KV Cache
L2（远程 SSD/分布式缓存）：全量知识库的 KV Cache

KV-aware Routing：请求路由到已有该文档 KV 的节点

成本治理：

统计分文档集的 KV 命中率 → 指导知识库分片策略
按文档召唤频率动态调整 L0/L1 分配
命中率越高、可复用前缀越长，省下的 prefill 越多（RAG 前缀重复度高，收益通常可观；别套"省 69%"这类固定百分比，口径见 3-Q12）
按租户/Tenant 拆分 KV 成本（谁的知识库谁的 KV 成本）

技术选型：LMCache（三级存储）+ Dynamo/llm-d（KV-aware routing）

如何落地：LMCache 部署 + SGLang RadixAttention + KV-aware routing 配置。

如何验证：KV 命中率 > 80%；prefill 成本下降 > 60%；文档集分片策略有效。

如何治理：命中率监控；知识库变更触发缓存预热；按租户 KV 成本归因。

面试官追问

不上分级 KV、只用引擎自带 Prefix Cache 行不行？ 小规模 / 单实例够用就别上——LMCache 要额外部署运维。分级 KV 的价值在跨实例共享 + 持久化 + 容量扩到 CPU/SSD：多实例、前缀集大到单卡显存放不下、重启不想丢缓存时才需要。阶梯：引擎自带 APC/RadixAttention（零部署）→ 不够再上 LMCache 三级。
上线后拿什么证明有效？ 分文档集/租户的 KV 命中率、prefill FLOPS / GPU 算力消耗下降、TTFT P95 改善；同时监控命中率是否因 system prompt 变动或知识库更新而掉（掉了要预热 / 排查前缀稳定性）。
跨租户复用要小心：私有文档的 KV 默认按租户隔离，避免时序侧信道泄露（见 3-Q17）。

Q13：设计一个推理服务压测方案#

需求：上线前验证推理服务能承受的目标 QPS，找出瓶颈。

压测方案设计：

text
1. 压测目标定义
   ├─ 目标 QPS（如 100）
   ├─ SLA（TTFT P95 < 1s, TPOT P95 < 50ms）
   └─ 最大并发数

2. 压测数据准备
   ├─ 真实业务 prompt 采样（不要只用 "Hello"）
   ├─ 多种 prompt 长度混合（短/中/长）
   ├─ 多种输出长度（10 token / 100 token / 500 token）
   └─ 流式 + 非流式混合

3. 压测工具
   ├─ vLLM benchmark_serving.py（官方）
   ├─ Locust / k6（自定义场景）
   └─ wrk（简单 HTTP 压测）

4. 压测步骤
   ├─ 阶梯加压（10 → 50 → 100 → 200 QPS）
   ├─ 持续压测（目标 QPS 持续 30 分钟）
   └─ 极限压测（找到崩溃点）

5. 监控指标
   ├─ 延迟：TTFT/TPOT/P50/P95/P99
   ├─ 资源：GPU Util/显存/KV Cache/Queue
   ├─ 吞吐：tokens/s/QPS
   └─ 错误率/超时率

如何落地：vLLM benchmark_serving.py + Prometheus + Grafana 压测看板。

如何验证：目标 QPS 下 SLA 达标；找到瓶颈点（GPU/显存/网络）；确认扩容阈值。

如何治理：每次模型/参数变更后回归压测；压测结果归档；扩容阈值根据压测数据设定。

Q14：设计一个模型量化上线流程#

需求：将 FP16 模型量化为 FP8/INT4 上线，确保精度不下降。

text
量化上线流程
├─ 1. 量化前评测（FP16 baseline）
│   ├─ 通用 benchmark（MMLU/HumanEval）
│   ├─ 业务专项评测
│   └─ 记录 baseline 分数
│
├─ 2. 量化方案选择
│   ├─ H100/H200 → FP8（权重+激活+KV Cache）
│   ├─ A100 → AWQ INT4（单卡跑大模型）
│   └─ 精度敏感 → 至少 FP8
│
├─ 3. 量化与校准
│   ├─ FP8：直接加载 FP8 权重（如有）
│   ├─ AWQ：用校准数据集确定量化参数
│   └─ SmoothQuant：激活平滑后量化
│
├─ 4. 量化后评测
│   ├─ 同一批 benchmark 对比
│   ├─ 精度下降 < 2% → 通过
│   └─ 精度下降 > 5% → 换方案或放弃
│
├─ 5. 性能验证
│   ├─ 显存占用对比
│   ├─ TTFT/TPOT/tokens/s 对比
│   └─ 性能提升达标 → 进入灰度
│
├─ 6. 灰度发布
│   ├─ 10% 流量 → 对比输出质量
│   └─ 无异常 → 全量
│
└─ 7. 持续监控
    └─ 质量漂移检测（量化可能在长生成场景露馅）

如何落地：AWQ/GPTQ 量化脚本 + Eval Pipeline + 灰度发布。

如何验证：量化前后 benchmark 分数对比；灰度期间在线采样评估。

如何治理：量化模型必须有 FP16 baseline 对照；长生成场景重点监控；定期跑质量漂移检测。

Q15：设计一个推理服务的容量规划方案#

需求：根据业务增长预测 GPU 需求，提前采购/扩容。

text
容量规划方法
├─ 1. 历史数据分析
│   ├─ 过去 3-6 个月的 QPS 趋势
│   ├─ 峰值/均值比
│   └─ 增长率（月环比）
│
├─ 2. 业务预测
│   ├─ 新业务线接入计划
│   ├─ 用户增长预测
│   └─ 季节性波动（大促/节假日）
│
├─ 3. 单 GPU 容量测算
│   ├─ 单卡最大 QPS（压测得到）
│   ├─ 单卡最大并发数
│   └─ 显存/算力瓶颈分析
│
├─ 4. GPU 需求计算
│   ├─ 目标 QPS / 单卡 QPS = 最少 GPU 数
│   ├─ 冗余系数 1.3-1.5（故障/升级/峰值）
│   └─ 考虑 PD 分离后的 prefill/decode 节点配比
│
├─ 5. 采购/扩容计划
│   ├─ 提前期（GPU 采购周期 4-12 周）
│   ├─ 分批采购（避免一次买太多）
│   └─ Spot Instance 补充弹性容量
│
└─ 6. 持续校准
    ├─ 每月复盘实际 vs 预测
    └─ 调整模型和冗余系数

如何落地：历史 QPS 数据 → 容量预测模型 → GPU 采购计划。

如何验证：预测误差 < 20%；实际 QPS 在预测范围内；GPU 利用率 60-80%（不闲置不排队）。

如何治理：月度容量评审；峰值前预扩容；闲置 GPU 及时回收/降配。

Q16：设计一个多区域推理服务灾备方案#

需求：多区域部署，单区域故障时自动切换，保证服务可用性。

text
多区域架构
├─ 区域 A（主）
│   ├─ LiteLLM Gateway（主）
│   ├─ vLLM/SGLang 集群
│   └─ 模型权重存储
│
├─ 区域 B（备）
│   ├─ LiteLLM Gateway（备）
│   ├─ vLLM/SGLang 集群
│   └─ 模型权重存储（同步）
│
└─ 全局 DNS / 流量入口
    ├─ 健康检查 → 主区域故障时切到备
    └─ 按地域就近路由（延迟优化）

故障切换策略：

主区域故障 → DNS 切到备区域（TTL 60s 内生效）
单模型故障 → LiteLLM Fallback 切到备用模型
单实例故障 → K8s 自动重启 + HPA 扩容

如何落地：多区域 K8s 集群 + 全局负载均衡（Cloudflare/阿里云 GTM）+ 模型权重跨区域同步。

如何验证：故障注入测试（kill 主区域）；RTO < 5 分钟；RPO = 0（无状态推理）。