模型量化与部署 面试问答

一、量化方法

Q1. 什么是模型量化？为什么能减小体积、加速推理？

• 答题要点：
  • 把高精度浮点（FP32/FP16）的权重与激活，映射到低精度（INT8/INT4/FP8）表示。
  • 核心映射：$q = \text{round}(x / s) + z$，反量化 $x \approx s(q - z)$，其中 $s$ 是 scale（步长），$z$ 是 zero-point。
  • 收益一：显存/内存占用下降——FP32→INT8 缩小 4 倍、FP16→INT4 缩小 4 倍，模型体积与 KV Cache 都变小。
  • 收益二：访存带宽压力下降（LLM 推理是访存密集），且可利用 INT8/FP8 Tensor Core 这类低精度算力加速。
  • 代价：引入量化误差，可能损失精度，需要靠校准/校正补偿。

Q2. 对称量化 vs 非对称量化，各自优缺点？

• 答题要点：
  • 对称量化：$z=0$，映射区间关于 0 对称，只需存 scale；实现简单、计算快（矩阵乘无需减 zero-point）。
  • 非对称量化：带 zero-point $z$，映射区间更贴合实际数据范围，精度更高。
  • 适用：权重通常对称量化（分布近 0 对称）；激活（如 ReLU 后非负）常非对称量化。
  • 权衡：对称实现与硬件更友好，非对称精度更好但多一次偏移计算。

Q3. per-tensor vs per-channel（per-group）量化，为什么 LLM 需要 per-channel？

• 答题要点：
  • per-tensor：整个张量共用一个 scale，实现简单、参数少，但粒度粗、误差大。
  • per-channel：每个输出通道一个 scale，能贴合各通道不同的数值量级，精度更高。
  • per-group：把一行权重按固定大小（如 group=128，GPTQ/AWQ 常用）分组各用一个 scale，粒度更细。
  • LLM 权重存在「离群通道」——个别通道量级远大于其余，per-tensor 会被这个离群值拉大 scale，导致其余通道的有效比特被浪费、信息大量丢失，所以必须 per-channel/per-group。

Q4. PTQ 和 QAT 的区别与适用场景？

• 答题要点：
  • PTQ（训练后量化）：模型训完后直接用少量校准数据统计 scale，不改权重训练，快速、低成本。
  • QAT（量化感知训练）：训练时前向模拟量化误差（fake-quant），让模型「适应」量化，精度更高但需要重新训练、成本大。
  • 场景：大模型（几十 B）重训成本过高，主流用 PTQ——GPTQ/AWQ/GGUF 本质都是 PTQ；QAT 适合小模型或精度要求苛刻、能负担训练成本的场景。

Q5. INT8 量化为什么需要校准（calibration）？校准集怎么选？

• 答题要点：
  • 量化 scale 取决于激活的数值范围，而推理时激活是动态的，无法预先确定，需要用一小批校准数据前向跑一遍统计范围。
  • 校准方法：min-max、percentile（如 99.99% 截断离群）、KL 散度（TensorRT 经典）、MSE 最小化误差。
  • 校准集要求：分布要与线上真实数据一致、能覆盖典型样本与边界；校准集失真会直接导致 scale 失真、精度掉点。
  • 校准集不必大，几十到几百条代表性样本通常够用。

Q6. FP16 vs BF16 区别？为什么训练/推理倾向 BF16？

• 答题要点：
  • FP16：1 符号 + 5 指数 + 10 尾数，尾数精度高但动态范围小（±65504），易溢出。
  • BF16：1 符号 + 8 指数 + 7 尾数，与 FP32 指数位相同、动态范围一致，不易溢出，但尾数精度低。
  • LLM 训练/推理更怕「溢出」（梯度爆炸、inf）而不太怕「舍入误差」，所以 BF16 更稳。
  • BF16 ↔ FP32 转换是直接截断尾数，硬件实现简单；A100/H100 均有原生 BF16 单元。

Q7. FP8（E4M3/E5M2）是什么？和 INT8 比优劣？

• 答题要点：
  • FP8 两种格式：E4M3（1+4+3，尾数多、精度高）、E5M2（1+5+2，指数多、范围大）。
  • 相比 INT8 的优势：指数表示动态范围大，不需要 per-channel 也能覆盖大量级差异，对离群值更鲁棒，激活量化的坑更少。
  • H100/H200 有原生 FP8 Tensor Core 算力（约 2 倍 FP16），推理加速明显。
  • 劣势：尾数位少于 INT8，绝对精度略低；依赖硬件支持（老卡不支持）。

Q8. INT4 量化难点在哪？为什么直接 round-to-nearest 会崩？

• 答题要点：
  • 4 bit 只有 16 个取值，量化误差天然大。
  • 权重离群通道会让 per-tensor/per-channel scale 失真，直接四舍五入会把绝大多数信息抹平，模型输出直接劣化。
  • 必须配套：per-group 细粒度 scale + 误差校正（GPTQ 二阶补偿 / AWQ 保护显著权重）。
  • 实践中 INT4 通常「权重 4bit + 激活保持 FP16」，并配合 group size（32~128）。

Q9. GPTQ 的原理是什么？

• 答题要点：
  • 逐层量化：一次量化一层，用该层输入激活构造误差项。
  • 核心是二阶信息校正：用 Hessian 矩阵 $H = 2XX^\top$ 量化误差；量化某一列权重后，把引入的误差按 $H^{-1}$ 分配到尚未量化的剩余列上做补偿。
  • 源自剪枝里的 OBC（Optimal Brain Compression）思想，推广到大模型做逐层贪心量化，无需重训。
  • 结果：INT4/INT3 下精度接近 FP16，推理端用反量化 kernel 实现加速。

Q10. AWQ 的原理是什么？

• 答题要点：
  • 激活感知量化：统计发现权重并非同等重要，约 0.1%~1% 的「显著权重」贡献了大部分输出。
  • 核心做法：per-channel 等价变换——把显著权重通道乘一个 scale 放大，对应激活通道除以同 scale 缩小，数学上输出不变，但让重要权重量化误差更小。
  • 只依赖激活统计、无需反向传播，比 GPTQ 更简单，还能显式保护部分权重（混合精度）。
  • 效果：INT4 精度与 GPTQ 相当或更好，工程实现更轻。

Q11. GGUF / llama.cpp 的 K-quants 是什么？

• 答题要点：
  • GGUF 是 llama.cpp 的模型文件格式，把权重 + 元数据打包，支持 mmap 直接映射加载。
  • K-quants 是 llama.cpp 的混合量化方案：在 block（super block，如 32/256）内对权重用不同精度组合，如 Q4_K_M、Q5_K_M、Q8_0。
  • Q4_K_M 等效约 4.8 bit/weight，在体积/精度/速度间平衡好，是 CPU/消费级 GPU 的常用档位。
  • 定位：面向 CPU / 端侧 / 本地无高端 GPU 的推理，不是数据中心吞吐方案。

Q12. LLM.int8() 的混合精度分解？

• 答题要点：
  • 观察：LLM 激活存在离群特征（某些列绝对值异常大），且离群列位置相对固定（集中在少数特征维度）。
  • 方案：把矩阵乘法拆成两部分——离群列（约 0.1%）用 FP16 算，其余 99.9% 用 INT8 算，最后相加。
  • 优点：无需校准集也能逼近 FP16 精度。
  • 局限：离群列仍走 FP16、收益有限，后来被 SmoothQuant 等「W8A8 全 INT8」方案取代。

Q13. SmoothQuant 如何解决激活离群问题？

• 答题要点：
  • 痛点：LLM 激活有离群值，导致激活难以 INT8 量化（W8A8 的瓶颈在 A8）。
  • 思路：把量化难度从激活迁移到权重——用 per-channel scale $s$ 把激活平滑缩小、权重对应放大，数学上等价（$Y = X W = (X \text{diag}(s)^{-1})(\text{diag}(s) W)$）。
  • 平滑后激活变得可 INT8；权重本就适合 per-channel 量化，不受影响。
  • 结果：W8A8 全 INT8，无需校准集，推理加速显著。

Q14. QLoRA 如何在量化模型上微调？

• 答题要点：
  • 三重技术：NF4（4-bit NormalFloat 量化，对正态分布权重更优）+ 双量化（对量化 scale 常数再做一次量化）+ paged optimizer（优化器状态换页到 CPU，防显存尖峰）。
  • 微调时基座权重保持 4bit 冻结，前向反量化回 BF16 参与计算，只更新 LoRA 低秩适配器。
  • 让「单卡微调大模型」成为可能，显存下降一个数量级，效果接近全参微调。
  • 注意：这是「在量化模型上微调」，与「量化已微调好的模型」是两件事。

Q15. 量化后的精度损失怎么评估？

• 答题要点：
  • Perplexity（PPL）：语言模型困惑度，量化后 PPL 上升越小越好，是最快的粗筛指标。
  • 下游任务 benchmark：MMLU（知识）、GSM8K（数学）、HumanEval（代码）等，按业务选关键任务。
  • 业务回归：准备自有评测集（含典型与边界 case），量化前后做输出 diff 对比。
  • 工业实践：先 PPL 快速筛方案，再跑关键任务 + 人工抽查，最后压测上线。

Q16. 量化 vs 剪枝 vs 蒸馏的区别与适用场景？

• 答题要点：
  • 量化：降低数值精度、不改变结构，硬件友好、收益立竿见影，是当前最主流的压缩手段。
  • 剪枝：删除不重要的权重/结构（稀疏化），压缩比大，但需要稀疏硬件/库支持才能转化为实际加速。
  • 蒸馏：用大模型教小模型，改变模型结构，精度可控，但需要额外训练成本。
  • 三者可叠加：先蒸馏出小模型，再剪枝，再量化，逐级压缩。

Q17. KV Cache 量化（INT8/FP8）的收益与风险？

• 答题要点：
  • 收益：长上下文/大批量下 KV Cache 占显存大头，量化到 INT8/FP8 可省一半以上 KV 显存，从而支持更长上下文或更大 batch。
  • 风险：attention 分数对 K/V 精度敏感，直接整块量化可能影响长文生成质量。
  • 做法：按 head / channel 分组量化，或只量化 K 不量化 V，配合反量化开销权衡。
  • 相关深度见 CUDA 与 AI 训练推理加速。

二、部署框架

Q1. 主流 LLM 推理框架有哪些？各自定位？

• 答题要点：
  • vLLM：PagedAttention + continuous batching，生态最好、吞吐高，在线服务首选之一。
  • TensorRT-LLM：NVIDIA 官方，kernel 级优化（算子融合、INT8/FP8/INT4 量化、in-flight batching），单卡极致性能，但工程复杂度高。
  • SGLang：RadixAttention 前缀缓存 + 结构化输出（JSON 约束）加速，多轮/多模态场景有优势。
  • llama.cpp / Ollama：CPU / 端侧 / 本地推理，GGUF 量化，轻量易用。
  • ONNX Runtime：通用跨平台推理引擎，做图优化，边缘与多平台部署。
  • Triton Inference Server：服务编排层，多模型/多版本管理、动态 batching。

Q2. vLLM 的 PagedAttention 是什么？解决什么问题？

• 答题要点：
  • 借鉴操作系统虚拟内存分页思想，把 KV Cache 切成固定大小 block（page），按需分配、物理上不连续存储。
  • 解决的问题：传统 KV Cache 按 max_len 连续预分配，产生大量内部碎片与显存浪费，限制 batch 与序列长度。
  • 效果：显存利用率逼近物理上限，同样显存能跑更大 batch、更长上下文。
  • 常与 continuous batching 配套，是 vLLM 吞吐优势的核心。

Q3. continuous batching 是什么？和静态 batching 的区别？

• 答题要点：
  • 静态 batching：一批请求必须等最长的那个结束后才整批释放，短请求拖累整批，GPU 有空闲。
  • continuous batching：迭代级动态调度，某个请求生成结束就立即腾出位置、新请求立即进入，GPU 持续满负荷。
  • 因为 decode 阶段是 memory-bound，batch 越大带宽利用率越高，continuous batching 能显著提高吞吐。
  • 可结合 推理请求动态批处理调度器（满批触发 + 超时触发的 C++ 实现）理解。

Q4. TensorRT-LLM 的优化手段？

• 答题要点：
  • 编译期图优化：算子融合（LayerNorm + MatMul、attention 内融合）、常量折叠、内存复用。
  • 量化：INT8（校准）、FP8（Hopper 原生算力）、INT4（配合 GPTQ/AWQ）weight-only。
  • in-flight batching（等价 continuous batching）+ KV Cache 精细管理。
  • 生成专用 CUDA kernel，针对特定 GPU 架构极致调优；缺点是模型支持面与工程复杂度高于 vLLM。

Q5. llama.cpp / Ollama 适合什么场景？GGUF 格式的作用？

• 答题要点：
  • 场景：CPU 推理、本地离线、隐私敏感、消费级 GPU/端侧跑中小模型。
  • Ollama 是 llama.cpp 之上的封装，提供模型管理、下载与 HTTP API，降低使用门槛。
  • GGUF：统一模型文件格式（权重 + 元数据 + tokenizer），支持 mmap 加载、多量化档位切换。
  • 定位是「可用性优先的本地推理」，不是数据中心高吞吐方案。

Q6. ONNX / ONNX Runtime 在部署链路里的角色？和 TensorRT 的关系？

• 答题要点：
  • ONNX：模型交换格式，跨框架（PyTorch/TensorFlow 等）的中间表示，标准算子集。
  • ONNX Runtime：跨平台推理执行引擎（CPU/GPU/边缘），做图优化（算子融合、常量折叠、量化）。
  • 关系：PyTorch 先 torch.onnx.export 导出 ONNX，ONNX 再作为 TensorRT builder 的输入构建 engine；ONNX Runtime 也可直接跑 ONNX，不依赖 TensorRT。

Q7. Triton Inference Server 是什么？动态 batching 怎么做？

• 答题要点：
  • NVIDIA 的推理服务框架，负责多模型/多版本管理、动态 batching、并发调度、HTTP/gRPC 接口与监控。
  • 动态 batching：把到达的请求攒批，达到 batch 阈值或超时后一起送引擎推理，提高 GPU 利用率。
  • 与 vLLM/TensorRT-LLM 等后端配合，是「生产级多模型服务」的编排层。

Q8. 典型部署链路：PyTorch → ONNX → TensorRT engine → runtime，各步骤做什么？

• 答题要点：
  • 导出（export）：torch.onnx.export 把模型转成 ONNX，做算子兼容性检查。
  • 构建（build）：TensorRT builder 解析 ONNX，做图优化、算子融合、量化（含 INT8 校准），产出序列化的 engine 文件。
  • 部署（runtime）：加载 engine、deserialize、创建 context、分配输入输出内存、执行推理。
  • 工程细节（动态 shape、多 context、内存池）见 vega_03_面试QA题库、vega_02_CUDA平台深度解析。

Q9. 框架选型怎么权衡？

• 答题要点：
  • 在线高吞吐、多用户 → vLLM / SGLang（生态好、调度强）。
  • 单卡极致性能、追求最低延迟 → TensorRT-LLM（kernel 级优化）。
  • CPU / 端侧 / 本地 → llama.cpp / ONNX Runtime。
  • 多模型生产服务 → Triton Inference Server 做编排层 + 上述引擎做后端。
  • 还需考虑：GPU 型号（是否支持 FP8）、是否需要量化、是否多机分布式、团队工程成本。

Q10. SGLang 相比 vLLM 的差异？

• 答题要点：
  • SGLang 亮点：RadixAttention 前缀缓存（自动复用共享前缀的 KV，多轮对话/多样本推理收益大）。
  • 结构化输出：约束解码（JSON Schema/正则）实现高效、token 数可控。
  • vLLM 亮点：生态更成熟、调度策略丰富、多模态与分布式支持广。
  • 实际差异集中在「前缀缓存实现」与「结构化输出」，两者吞吐在各自优化场景互有胜负。

Q11. 动态 shape / dynamic batch 在推理引擎里怎么支持？

• 答题要点：
  • 构建阶段用 optimization profile 定义维度范围：min / opt / max。
  • 运行时按实际 shape 在范围内选择，TensorRT 用 setInputShape（TRT8+）/ setBindingDimensions（旧版）设置。
  • 多 context 各自绑定不同 profile 以服务不同 batch；超出 max 范围需重新 build。
  • 相关实现细节见 vega_03_面试QA题库。

三、性能与显存优化

Q1. 如何估算 LLM 推理显存？

• 答题要点：

  • 权重：参数量 × 每参数字节数（FP16=2B、INT8=1B、INT4=0.5B）。
  • 示例：7B 模型 FP16 ≈ 14GB 权重。
  ❯Text复制

  权重显存 = 参数量 × bytes_per_param
  7B FP16: 7e9 × 2 = 14 GB
  7B INT4: 7e9 × 0.5 = 3.5 GB

  • 还要加：KV Cache（见 Q2）+ 激活 + 中间 buffer + 框架开销。
  • 经验：显存 = 权重 + KV Cache + 10%~20% 余量，长上下文场景 KV 可能远超权重。

Q2. KV Cache 是什么？显存占用公式？为什么长上下文是显存杀手？

• 答题要点：

  • 自回归推理中缓存历史 token 的 K/V，避免每个新 token 都重新计算全部历史。
  • 公式：$2 \times \text{layers} \times \text{kv\_heads} \times \text{head\_dim} \times \text{seq\_len} \times \text{batch} \times \text{bytes}$（K、V 各一份，故乘 2）。
  • 示例：Llama-2 7B（32 层、32 KV 头、head_dim 128、FP16），seq 4096、batch 1：
  ❯Text复制

  KV = 2 × 32 × 32 × 128 × 4096 × 1 × 2 ≈ 2.1 GB

  • 长上下文（如 128k）下 KV 随 seq_len 线性增长，会远超权重本身，成为显存主要瓶颈。

Q3. KV Cache 有哪些优化手段？

• 答题要点：
  • 量化：KV 存 INT8/FP8，省一半以上显存。
  • PagedAttention：分页存储，消除碎片、提升利用率。
  • GQA/MQA：共享 KV 头、减少 KV 头数量（如 MQA 只 1 个 KV 头）。
  • MLA（DeepSeek 多潜注意力）：低秩压缩 KV，只存小 latent，显存大幅下降。
  • 淘汰/滑动窗口：超长序列丢弃远端 KV 或限制窗口。

Q4. 吞吐 vs 延迟；prefill 和 decode 两阶段各自瓶颈？

• 答题要点：
  • 延迟指标：TTFT（首 token 延迟，受 prefill 影响）、TPOT（每 token 延迟，受 decode 影响）；吞吐 = 每秒生成 token 数。
  • prefill：一次性并行处理 prompt 所有 token，计算密集，产生 KV Cache。
  • decode：逐 token 生成，每步读全部 KV Cache，访存密集。
  • 在线服务要同时优化：prefill 决定响应体感，decode 决定吞吐与单 token 成本。

Q5. 为什么 prefill 是 compute-bound、decode 是 memory-bound？

• 答题要点：
  • prefill 一次算完整个 prompt，矩阵大、算力利用率高（MFU 高），瓶颈在计算。
  • decode 每步只算 1 个 token，矩阵乘退化为「矩阵×向量」，计算量极小，但要读入全部 KV Cache，访存量 ≫ 计算量。
  • 结论：decode 阶段瓶颈是显存带宽，因此提高 batch、减少 KV 访存（量化/压缩）是核心优化方向。

Q6. 投机采样（speculative decoding）的原理？为什么能加速 decode？

• 答题要点：
  • 用一个小模型（draft）快速自回归生成多个候选 token，再用大模型（target）一次前向并行验证这些候选。
  • 验证通过则一次接受多个 token，减少大模型的串行调用次数（decode 是大模型的访存瓶颈）。
  • 用接受/拒绝机制保证输出分布与 target 原始分布一致，不损失精度。
  • 收益来自「多个 token 摊薄一次大模型前向的 KV 读取代价」。

Q7. 批处理对吞吐/延迟的影响？如何权衡 batch size？

• 答题要点：
  • 增大 batch：decode 阶段访存被摊薄，吞吐上升；但单请求延迟上升、显存（尤其 KV）增加。
  • 减小 batch：单请求延迟低，但 GPU 利用率与吞吐下降。
  • 权衡：在线服务用 continuous batching 动态调 batch；延迟敏感业务限制最大 batch；显存上限由 KV Cache 决定。
  • 也常按 SLA 分级：高优请求小 batch 保延迟，普通请求大 batch 保吞吐。

Q8. 算子融合为什么快？举例说明。

• 答题要点：
  • 减少 kernel launch 次数（每次 launch 有固定开销）。
  • 避免中间结果写回 global memory 再读回（访存是 LLM 推理的主要瓶颈）。
  • 例：RMSNorm + 残差连接 + QKV 投影融合成一个 kernel；attention 内 QK^T、softmax、×V 融合。
  • FlashAttention 本质也是把整个 attention 融合成少次访存。

Q9. FlashAttention 解决了什么？

• 答题要点：
  • 标准 attention 需要把 $QK^\top$（n×n）和 softmax 结果显式写回显存，显存 O(n²)、IO 巨大。
  • FlashAttention 用分块（tiling）+ 在线 softmax，避免完整 n×n 矩阵落显存，显存降到 O(n)。
  • 收益：长序列下更快、更省显存；是当前 attention 实现的标配。

Q10. 多卡并行策略 TP / PP / DP / EP 各自适用场景？

• 答题要点：
  • TP（张量并行）：单层权重切分到多卡，每卡算一部分，通信密集（AllReduce），适合单机内 NVLink 高速互联。
  • PP（流水线并行）：按层切分，微批次流水执行，通信少但有流水空泡（pipeline bubble）。
  • DP（数据并行）：多副本各吃一批数据，吞吐线性扩展，但不能降低单请求显存。
  • EP（专家并行）：MoE 的专家分布到多卡，all-to-all 通信，按 top-k 路由。
  • 实践：超大模型 TP + PP 组合；MoE 模型用 EP + DP/TP。

Q11. 量化对推理速度的实际影响？

• 答题要点：
  • INT8：Tensor Core 算力约为 FP16 的 2 倍，访存减半，端到端通常 1.3~2 倍提速。
  • INT4：显存进一步减半，但 GPU 无原生 INT4 Tensor Core，需要反量化开销，速度未必快于 INT8，主要价值是省显存（换取更大 batch / 更长上下文）。
  • 提速幅度取决于模型是否 memory-bound：访存瓶颈越明显，量化收益越大。

Q12. MFU（模型 FLOPs 利用率）是什么？为什么 decode 阶段 MFU 很低？

• 答题要点：
  • MFU = 实际实现 FLOPs / 硬件理论峰值 FLOPs，反映算力利用率。
  • prefill 阶段矩阵大、MFU 高；decode 阶段每步计算量小、访存大，算力大量空闲，MFU 常 < 10%。
  • 意义：decode 低 MFU 说明瓶颈在访存而非算力，优化应聚焦「喂饱带宽」（大 batch、KV 压缩、投机采样）而不是单纯堆算力。

四、工程实践

Q1. 模型上线前的评估流程？

• 答题要点：
  • 精度评测：PPL + 关键任务 benchmark + 自有业务回归集，量化前后对比。
  • 性能评测：TTFT / TPOT / 吞吐，扫描不同 batch 与 seq_len 的曲线。
  • 稳定性压测：长跑、高并发、OOM、超时、异常输入边界。
  • 建立量化模型与原模型的输出 diff 对比，形成上线评估报告。

Q2. 推理服务的架构设计？

• 答题要点：
  • 分层：网关（鉴权/限流/路由）→ 调度器（攒批/排队/优先级）→ 模型 worker（引擎实例，常驻显存）。
  • 可靠性：健康检查、超时重试、降级兜底、模型池（多实例轮转）。
  • 关键设计点：显存不足时的排队策略、请求粘性与取消、多模型路由。
  • 可与 推理请求动态批处理调度器 的满批+超时触发思路对照。

Q3. 模型热加载 / 热更新（无停机升级）？

• 答题要点：
  • 蓝绿/双缓冲：新版本先加载进显存并预热（跑几条请求），再切换流量，旧版本在请求 drain 后卸载。
  • 灰度切换：按比例把流量切到新版本，异常可回滚。
  • 无停机关键：请求粘性（已进入旧版本的请求跑完再释放）+ 显存预规划（新旧并存需要双份显存）。

Q4. 监控指标有哪些？

• 答题要点：
  • 吞吐与延迟：QPS、TTFT、TPOT、P50/P99/P99.9 延迟。
  • 资源：GPU 利用率、显存占用、队列长度、batch 大小分布。
  • 质量与错误：错误率、超时率、输出 token 数、重复/截断率。
  • 配合 SLI/SLO 设告警阈值，延迟类重点看 P99 而非平均值。

Q5. 容量规划与自动扩缩容？

• 答题要点：
  • 需求侧：峰值 QPS × 平均输入/输出 token 数 → 估算所需吞吐与显存。
  • 供给侧：单实例吞吐上限、单卡显存上限（权重 + KV × batch × max_seq）。
  • 扩缩容：基于队列长度、GPU 利用率、P99 延迟等自定义指标（HPA），预热时间要纳入弹性策略。

Q6. 多模型 / 多版本灰度上线？

• 答题要点：
  • 用模型注册中心管理版本与 tag，按版本路由流量。
  • 灰度节奏：5% → 20% → 50% → 100%，每步对比新旧版本指标（延迟/错误率/业务指标）。
  • 异常自动回滚：指标劣化触发切回旧版本。
  • 与 A/B 实验结合，量化/框架升级都走同一灰度通道。

Q7. 量化后某条 case 答错了，怎么定位？

• 答题要点：
  • 复现该 case，对比原模型与量化模型输出 diff，确认是量化引入而非模型本身问题。
  • 检查校准集是否覆盖该 case 的数据分布（校准失真常见）。
  • 看系统性指标（PPL、该任务 benchmark）是整体下降还是个别 case。
  • 处置：换校准集、换量化方案（GPTQ vs AWQ）、调 per-group 粒度或改用更高精度档。

Q8. 显存 OOM 怎么定位和解决？

• 答题要点：
  • 先定位阶段：加载时 OOM（权重装不下）vs 推理时 OOM（KV/激活/碎片）。
  • 观察显存曲线，区分是「权重 + KV」超限还是碎片/峰值尖刺。
  • 解决：降 batch / 降 max_seq、KV 量化、PagedAttention、weight-only 量化、CPU offload、多卡并行。
  • 训练侧另用梯度检查点、梯度累积；推理侧优先动 KV 与 batch。

Q9. 推理成本优化？

• 答题要点：
  • 提高 GPU 利用率：continuous batching、多模型共卡、错峰调度。
  • 量化降显存 → 同卡更大 batch、更长上下文，摊薄单 token 成本。
  • 前缀缓存（RadixAttention）复用共享前缀的 KV，减少重复计算。
  • 资源侧：spot/竞价实例、异构卡型、按 SLA 分级（低优请求用更省资源档）。

Q10. 端侧/边缘部署 vs 云端部署的差异？

• 答题要点：
  • 云端：算力强、易扩缩容、模型可大；但延迟受网络影响、数据需上云。
  • 端侧：隐私、离线、低延迟、成本低；但算力/显存/功耗受限，需小模型 + 量化。
  • 端侧方案：TensorRT / NCNN / MNN / RKNN / NNIE（可结合 VEGA 跨平台后端经验，见 vega_00_总览与架构），常用 INT8 量化。
  • 选型维度：数据敏感度、实时性要求、设备算力与功耗预算。

---