面试 · 对比辨析型
考察目标：能否说清两个相近概念/工具/技术的本质差异，展示选型决策能力 约 20 题，含对比表格 答题框架：差异 → 替代方案 → 如何选
Q1：vLLM vs SGLang？#
| 维度 | vLLM | SGLang |
|---|---|---|
| 核心武器 | PagedAttention（分页管理 KV Cache） | RadixAttention（Radix Tree 前缀共享） |
| KV Cache 共享 | Automatic Prefix Caching（block 级 hash，跨请求持久共享，仅显存不足才按 LRU 淘汰） | Radix Tree（token 级，前缀树持续共享） |
| 前缀命中率 | 稳定（hash 精确匹配前缀，非碰运气） | 稳定 + 多前缀/分叉管理更灵活（多轮可达 60-85%） |
| 结构化输出 | 支持 | 原生约束解码（JSON Schema/正则/EBNF） |
| 前端 DSL | 无 | Python + sgl.gen/sgl.fork |
| DeepSeek 优化 | 一般 | 最深度（MLA + MoE + EPLB） |
| 社区 | 最大最活跃 | 快速增长 |
| 适用场景 | 通用推理，开箱即用 | Agent/多轮对话/RAG 固定前缀/MoE |
辨析要点（常被说错）：两者的前缀缓存都是跨请求持久命中——vLLM Automatic Prefix Caching 用 block-hash + LRU（只有显存不足才淘汰），SGLang 用 Radix 树，命中都不是"碰运气"。真正差异是 Radix 树对"多前缀/分叉"场景（同一 system prompt 下大量不同分支、树状会话/Agent）管理更灵活，命中率更稳；vLLM 的 block-hash 在高分叉场景命中率略低。别答成"主动共享 vs 幸运命中"。
如何选：通用场景 + 快速上线 → vLLM；MoE 模型 / Agent / 多轮 / RAG（多分叉前缀）→ SGLang。
Q2：vLLM vs Triton Inference Server？#
| 维度 | vLLM | Triton |
|---|---|---|
| 定位 | LLM 专用推理引擎 | 通用推理服务器（CV+NLP+LLM） |
| LLM 优化 | PagedAttention + Continuous Batching | 依赖 backend（如 tensorrtllm） |
| 多模型混部 | 不支持（一个进程一个模型） | 原生支持 |
| 多框架 | LLM 开源模型 | TensorRT/ONNX/PyTorch/TF/Python 等十余种 |
| 编排 | 无 | Ensemble + BLS |
| 适用场景 | 纯 LLM 服务 | 多模型、多框架、LLM+传统模型混部 |
如何选：纯 LLM 服务 → vLLM；多模型混部（LLM + Embedding + Rerank + CV）→ Triton。
Q3：TensorRT-LLM vs vLLM？#
| 维度 | TRT-LLM | vLLM |
|---|---|---|
| 编译 | 必须离线编译 .engine（30 分钟+） | 运行时动态加载 |
| 极致性能 | 最好（图级优化，kernel 融合深） | 接近 |
| FP8 支持 | 最成熟（权重+激活+KV全FP8） | 较好 |
| 动态性 | 参数改一个要重新编译 | 完全动态 |
| 跨硬件 | 只 NVIDIA | NVIDIA/AMD/TPU 等 |
| 上手难度 | 高 | 低 |
| 适用场景 | H100 极致性能、Triton 栈 | 通用、快速迭代、多硬件 |
如何选：快速迭代/多硬件 → vLLM；H100 极致性能 + 稳定不变 → TRT-LLM。常见做法：迭代期用 vLLM，稳定后转 TRT-LLM。
Q4：vLLM vs SGLang vs TRT-LLM 三者对比？#
| 维度 | vLLM | SGLang | TRT-LLM |
|---|---|---|---|
| 核心优势 | 社区最大，通用易用 | RadixAttention，DeepSeek 优化 | 极致性能，FP8 最成熟 |
| MoE/MLA 优化 | 一般 | 最深度 | 中等 |
| 多轮/Agent | 中（Prefix Cache） | 最优（RadixAttention） | 中 |
| 编译 | 无 | 无 | 必须离线编译 |
| 跨硬件 | 好（NVIDIA/AMD/TPU） | 中（NVIDIA 为主） | 只 NVIDIA |
| 上手难度 | 低 | 低 | 高 |
| 适用场景 | 通用、快速上线 | MoE/Agent/RAG | H100 极致性能 |
如何选：MoE 模型（DeepSeek）→ SGLang；通用快速上线 → vLLM；H100 极致性能 → TRT-LLM。
Q5：Online vs Batch Inference？#
| 维度 | Online Inference | Batch Inference |
|---|---|---|
| 延迟要求 | 秒级（TTFT < 2s） | 分钟到小时级 |
| 调用方式 | HTTP/gRPC 实时 API | 文件批处理 |
| 成本 | 全价 | ~50% 折扣（OpenAI/Anthropic Batch API） |
| 弹性要求 | 高（实时响应） | 低（可排队） |
| 适用场景 | 用户对话、实时 Agent | 数据清洗、离线标注、批量评估 |
如何选：实时场景 → Online；离线大数据量 → Batch（省 50% 成本）。
Q6：Prefill vs Decode？#
| 维度 | Prefill | Decode |
|---|---|---|
| 处理方式 | 并行处理所有输入 token | 串行逐个生成 |
| 计算特征 | Compute-bound | Memory-bound |
| GPU SM 利用率 | 高（80-95%） | 低（20-40%） |
| 每次 token 数 | input_len（一次性） | 1 per step |
| 瓶颈 | 算力（FLOPS） | 显存带宽 |
| 优化方向 | 加大 batch、FP8 计算、Chunked Prefill | KV Cache 压缩、CUDA Graph、增大 batch |
如何选：不需要选，两者是同一请求的不同阶段。但 PD 分离可以把它们分到不同 GPU 各自优化。
Q7：TTFT vs TPOT？#
| 维度 | TTFT | TPOT |
|---|---|---|
| 全称 | Time To First Token | Time Per Output Token |
| 对应阶段 | Prefill + 首 token 生成 | Decode 每个 token |
| 单位 | 秒（绝对值） | 毫秒（平均值） |
| 影响因素 | prompt 长度、GPU 算力、KV Cache 命中 | 显存带宽、batch 大小、模型复杂度 |
| 高延迟原因 | 长 prompt、KV Cache Miss | 大 batch 竞争带宽、显存不足 |
如何选：两者独立，TTFT 高不一定 TPOT 高。TTFT 高查 prefill，TPOT 高查 decode。总延迟 = TTFT + output_tokens × TPOT。
Q8：AI Gateway vs 普通 API Gateway？#
| 维度 | 普通 API Gateway | AI Gateway |
|---|---|---|
| 路由 | URL/Host 路由 | 模型名/Model Group 路由 |
| 限流 | QPS/RPS | RPM + TPM（token per minute） |
| 鉴权 | API Key | Virtual Key（模型+预算绑定） |
| 计费 | 无/简单 | Token 级计费，按模型/租户拆分 |
| Fallback | HTTP 级 | 模型级（还可自动切更大上下文的模型） |
| 审计 | HTTP 日志 | Prompt+Response+Token 日志 |
如何选：LLM 服务必须用 AI Gateway（普通网关不懂 token/模型路由/成本统计）。LiteLLM 是开源首选。
Q9：Volcano vs Kueue？#
| 维度 | Volcano | Kueue |
|---|---|---|
| 定位 | 批调度器（替代 kube-scheduler） | 队列管理（admission gate） |
| API 风格 | 自有 CRD（Volcano Job/PodGroup） | 贴近原生 K8s（原生 Job + Label） |
| Gang Scheduling | 原生 PodGroup | all-or-nothing admission |
| 跨集群 | 无 | MultiKueue |
| 生态集成 | Kubeflow/MPI/Spark | RayJob/PyTorchJob/JobSet |
| 成熟度 | 稳定多年 | v1beta2（SIG 项目，发展快） |
| 学习曲线 | 中 | 低（贴近 K8s 原生） |
如何选：纯 AI 训练 + K8s 原生 → Volcano；想要 upstream 方案 + API 贴近原生 → Kueue。
Q10：Volcano vs Slurm？#
| 维度 | Volcano | Slurm |
|---|---|---|
| 平台 | K8s 原生 | 独立 HPC 调度器 |
| 容器化 | 原生容器 | 模块加载为主 |
| 生态 | Kubeflow/K8s 生态 | HPC（MPI/CUDA/Lustre） |
| 运维 | 与 K8s 统一 | 需要独立集群 |
| 适用团队 | K8s 背景 | 传统 HPC 背景 |
如何选：K8s 背景 → Volcano；已有 HPC 集群 + Slurm 经验 → 继续 Slurm；混合栈：Slurm 管训练，K8s+Volcano 管推理。
Q11：Volcano vs Kueue vs Slurm 三者对比？#
| 维度 | Volcano | Kueue | Slurm |
|---|---|---|---|
| 平台 | K8s 原生 | K8s 原生 | 独立 HPC |
| 定位 | 批调度器 | 队列管理 | HPC 调度器 |
| 容器化 | 原生 | 原生 | 模块加载 |
| Gang Scheduling | PodGroup | admission gate | 原生 |
| 跨集群 | 无 | MultiKueue | 多集群 |
| 适用场景 | K8s AI 训练 | K8s 原生批处理 | 传统 HPC |
如何选：K8s 原生 AI 训练 → Volcano 或 Kueue；传统 HPC → Slurm。
Q12：HAMi vs MIG vs MPS？#
| 维度 | HAMi | MIG | MPS |
|---|---|---|---|
| 隔离粒度 | vGPU 级（显存+算力） | 物理切分（固定规格） | SM 并发共享 |
| 显存隔离 | 支持 | 物理隔离 | 无 |
| 灵活性 | 灵活（任意比例） | 固定（1g/2g/3g/7g） | 灵活 |
| 硬件要求 | NVIDIA GPU | A100/H100 专属 | NVIDIA GPU |
| 国产化 | 支持 | 不支持 | 不支持 |
| 适用场景 | K8s 原生 GPU 共享 | 生产多租户强隔离 | 同租户多进程 |
如何选：强隔离 + 固定规格 → MIG；灵活 + 国产化 → HAMi；同租户多进程并发 → MPS；开发测试 → Time-Slicing（无显存隔离）。
Q13：Inference Infra vs Training Infra？#
| 维度 | Inference Infra | Training Infra |
|---|---|---|
| 核心关注 | 延迟（TTFT/TPOT）、吞吐（QPS）、显存 | 吞吐（Tokens/s）、收敛速度、显存 |
| 调度 | 在线服务调度 | 批作业调度（Gang Scheduling） |
| GPU 使用模式 | 持续在线 | 短期高密度使用 |
| 弹性 | HPA/KEDA/scale-to-zero | 批处理队列 |
| 关键工具 | vLLM/SGLang/LiteLLM | PyTorch DDP/DeepSpeed/Megatron |
| 通信 | NCCL（TP 场景同机为主） | NCCL（跨机 AllReduce） |
| Checkpoint | 不涉及（无状态） | 核心机制（断点续训） |
如何选：岗位方向选择——喜欢在线服务/低延迟优化 → Inference；喜欢分布式系统/大规模计算 → Training。
Q14：引擎层 vs 编排层？#
| 维度 | 引擎层 | 编排层 |
|---|---|---|
| 职责 | 跑单个模型 | 管多个推理节点协同 |
| 代表 | vLLM/SGLang/TRT-LLM | NVIDIA Dynamo/llm-d |
| PD 分离 | 引擎内机制（如 vLLM KVConnector） | 跨节点 disaggregated serving |
| 路由 | 无 | KV-aware routing |
| 关系 | 编排层不替代引擎层 | 编排层在引擎层之上 |
如何选：单节点能扛住流量 → 引擎层 + 网关即可；需要跨节点 PD 分离/KV 路由/多节点负载均衡 → 引入编排层。
Q15：Dynamo vs llm-d？#
| 维度 | NVIDIA Dynamo | llm-d |
|---|---|---|
| 主导方 | NVIDIA | Red Hat / 社区 |
| 定位 | 全功能编排层（含 PD 分离、KV 路由） | 轻量级 KV-centric 路由 |
| 硬件绑定 | NVIDIA 生态（深度优化 NVLink/RDMA） | 硬件无关 |
| 部署复杂度 | 较高（依赖 NVIDIA 栈） | 较低（K8s CRD） |
| 适用场景 | 大规模 NVIDIA 集群、需要 PD 分离 | 中小规模、多硬件、需要 scale-to-zero |
如何选：大规模 NVIDIA 集群 + PD 分离 → Dynamo；中小规模 + 多硬件 + scale-to-zero → llm-d。
Q16：LMCache 分级 KV vs vLLM 自带 Prefix Cache？#
| 维度 | LMCache（分级 KV） | vLLM Prefix Cache |
|---|---|---|
| 存储层级 | GPU + CPU DRAM + SSD 三级 | GPU 内存 |
| 命中范围 | 跨请求、跨实例共享 | 同实例同 prefix 请求 |
| 持久性 | L1/L2 跨实例重启可恢复 | 进程内，重启即失 |
| 有效复用 | 高（跨实例共享 + 持久化，可复用前缀更多） | 中（仅单实例进程内、重启即失，可复用面更窄） |
| 复杂度 | 需要部署 LMCache 服务 | 引擎自带，一行参数开启 |
如何选：RAG/多轮/固定前缀 → LMCache 分级 KV（跨实例共享 + 持久化）；简单前缀复用 → vLLM Prefix Cache（零部署成本）。两者可叠加使用。
Q17：TP vs PP vs EP vs DP？#
| 并行策略 | 切分粒度 | 通信代价 | 适用场景 |
|---|---|---|---|
| TP（张量并行） | 单层权重切分到多卡 | 每层 2 次 AllReduce（高） | 单机 NVLink 域（≤8卡） |
| PP（流水线并行） | 不同层分到不同设备 | 层边界传激活值（低） | 跨机部署首选 |
| EP（专家并行） | MoE 的 expert 分布 | 路由分发（中） | MoE 模型专属 |
| DP（数据并行） | 完整模型多副本 | 无（网关分流） | 扩吞吐首选 |
如何选：优先级是能 DP 不 TP；必须跨机优先 PP；MoE 加 EP。典型组合：单机 TP=8，跨机 TP=8+PP=N，MoE 用 TP+EP。
Q18：FP8 vs INT8 vs INT4 量化对比？#
| 维度 | FP8 | INT8 (SmoothQuant) | INT4 (AWQ/GPTQ) |
|---|---|---|---|
| 权重大小 | 1 byte | 1 byte | 0.5 byte |
| 精度损失 | 极小（< 1%） | 小（1-2%） | 中（2-5%） |
| 硬件要求 | H100/H200 | Ampere+ | Ampere+ |
| KV Cache | 可 FP8 | INT8 + FP16 KV | FP16 KV |
| 计算加速 | 硬件原生 2x | 1.5-2x | 主要省显存 |
| 适用场景 | H100 基线 | A100 通用 | 单卡跑 70B |
如何选：H100/H200 → FP8（无脑）；A100 → AWQ INT4（单卡跑大模型）或 SmoothQuant INT8（通用）；精度敏感场景至少 FP8。
Q19：HPA vs KEDA？#
| 维度 | HPA | KEDA |
|---|---|---|
| 全称 | Horizontal Pod Autoscaler | Kubernetes Event-Driven Autoscaling |
| 数据源 | metrics.k8s.io + custom.metrics | Prometheus/Kafka/Redis 等 60+ |
| scale-to-zero | 不支持 | 支持 |
| 部署复杂度 | K8s 内置 | 需安装 KEDA Operator |
| 适用场景 | 简单 CPU/内存扩缩 | 自定义指标/事件驱动/scale-to-zero |
如何选：简单 CPU/内存扩缩 → HPA；需要 Prometheus 指标/scale-to-zero/事件驱动 → KEDA。LLM 推理场景必须用 KEDA 或 HPA + 自定义指标（GPU 指标）。
Q20：PD 分离 vs 混合部署？#
| 维度 | PD 分离 | 混合部署（无分离） |
|---|---|---|
| 架构 | Prefill 节点 + Decode 节点分离 | 同一 GPU 跑 prefill + decode |
| TTFT | 低（prefill 不被 decode 干扰） | 高（decode 抢占 prefill 算力） |
| 吞吐 | 高（decode 可无限扩展） | 中（互相干扰） |
| 复杂度 | 高（KV 跨节点传输 + 两套硬件） | 低（单引擎搞定） |
| 网络要求 | 100Gbps+ RDMA | 无特殊要求 |
| 适用场景 | 大规模 + 流量波动大 | 小规模 + 流量平稳 |
如何选：小规模 + 流量平稳 → 混合部署（简单）；大规模 + prefill/decode 冲突严重 → PD 分离。不是银弹，看场景。