面试 · 概念解释型

考察目标：能否用自己的话讲清楚核心概念，展示对领域理解的深度和广度 约 30 题，覆盖 AI Infra 核心术语 答题框架：是什么 → 为什么需要 → 如何落地

Q1：什么是 AI Infra / AI Inference？#

是什么：AI Infra 是让 AI 模型从"能跑"到"可服务化、可并发、可观测、可灰度、可回滚、可治理成本、可合规上线"的基础设施能力。AI Inference 特指模型推理层面的基础设施。

为什么需要：大模型不能靠本地脚本跑生产——需要服务化、并发优化、成本治理、合规上线。传统 DevOps 不懂 LLM（不知道 token、KV Cache、模型路由），需要专门的 AI Infra 层。

如何落地：AI Infra 建立在 K8s/CI-CD/可观测等通用基础设施之上，增加 LLM 专属能力——推理引擎管理（vLLM/SGLang）、KV Cache 优化、模型路由、Token 成本计量、备案合规等。核心主线：模型推理基础 → 推理服务化 → 性能优化 → 算力调度 → 稳定性可观测 → 平台治理。

Q2：AI Infra 和 DevOps / SRE / MLOps 有什么区别？#

是什么：四个领域关注点不同但层层递进。

为什么需要区分：MLOps 管传统 ML（训练-部署流水线），AI Infra 管大模型（推理引擎+性能优化+多卡分布式+网关+合规），两者的工程挑战完全不同——大模型有 KV Cache、PD 分离、MoE 等专属问题。

如何落地：DevOps/SRE 是 AI Infra 的前置能力（见前置要求），AI Infra 在其上增加 LLM 专属层。

Q3：什么是 prefill / decode？#

是什么：LLM 推理的两个阶段。Prefill 一次性处理输入 prompt 所有 token，计算 KV Cache 并生成首 token。Decode 从第二个 token 开始，每次用上一个 token + KV Cache 计算下一个 token，自回归生成。

为什么需要区分：两者资源需求截然相反——Prefill 是 compute-bound（算力密集，SM 利用率 80-95%），Decode 是 memory-bound（访存密集，SM 利用率 20-40%）。这个差异是 PD 分离、Chunked Prefill 等所有优化的基础。

如何落地：部署推理引擎时理解参数对不同阶段的影响——max-num-batched-tokens 影响 prefill，max-num-seqs 影响 decode 并发。TTFT 反映 prefill 瓶颈，TPOT 反映 decode 瓶颈。

Q4：什么是 KV Cache？#

是什么：LLM 推理中缓存在 GPU 显存中的 Key 和 Value 矩阵。作用：避免 Decode 阶段对之前 token 的重复 Attention 计算。

为什么需要：自回归生成中，每次生成新 token 都要与之前所有 token 做 Attention。不缓存则每步重算，O(n²) 计算量。缓存后只算新 token 与历史的关系。

如何落地：每层 Transformer 都存 K 和 V。以 LLaMA 70B（GQA，8 组 KV head）为例，每 token 约 320KB（FP16），10 万 token ≈ 32GB。注意 320KB 是 GQA 的数字——同规模的纯 MHA（KV head 数 = query head 数）约为其 8 倍（≈2.5MB/token），谈显存估算前必须先问清楚是 MHA 还是 GQA。KV Cache 是推理显存第一消耗者（长上下文场景超过权重），所有降本优化（MLA、FP8 KV、分级 KV、PD 分离）都围绕它展开。

Q5：什么是 TTFT / TPOT / tokens/s？#

是什么：

• TTFT（Time To First Token）：从请求发出到首个 token 返回的时间，反映 Prefill 阶段耗时
• TPOT（Time Per Output Token）：Decode 阶段每个 token 的平均耗时
• tokens/s：系统每秒生成的总 token 数（input + output），吞吐量指标

为什么需要：三者是推理性能的核心指标，分别反映首 token 延迟、逐 token 延迟、系统吞吐。TTFT 高 → 查 prompt 长度/prefill 算力；TPOT 高 → 查显存带宽/batch 大小；tokens/s 低 → 查并发容量。

如何落地：通过 vLLM/SGLang 的 Prometheus metrics 采集，配 Grafana 看板。SLA 典型目标：实时对话 TTFT < 1s、TPOT < 50ms；代码补全 TTFT < 200ms、TPOT < 30ms。

Q6：什么是 Continuous Batching？#

是什么：LLM 推理的核心调度策略：每生成一个 token 后，调度器检查哪些请求已完成、哪些等待中的请求可以加入。也叫 Inflight Batching、Iteration-level Scheduling。

为什么需要：传统 Static Batching 等整批完成再换下一批，短请求完成后 GPU 空等长请求。请求长度方差越大，浪费越严重。

如何落地：vLLM、SGLang、TRT-LLM 均原生支持。效果：同等硬件吞吐量提升 3-10 倍（取决于请求长度方差）。

Q7：什么是 Continuous Batching 和 Dynamic Batching 的区别？#

是什么：两种批处理策略，适用场景不同。

为什么需要区分：LLM 的 decode 是逐 token 生成的，可以在任意 token 步长后切换请求；传统模型是一次性前向，必须等整批完成。

如何落地：LLM 推理用 Continuous Batching（vLLM/SGLang 默认），传统模型用 Dynamic Batching（Triton 配置）。

Q8：什么是 Model Registry / AI Gateway / 模型灰度 / fallback？#

是什么：

• Model Registry：模型的"制品仓库"，记录模型版本、权重路径、评测结果、阶段状态（staging/production/archived）
• AI Gateway：LLM 推理的统一入口，在传统 API Gateway 之上增加模型路由、Virtual Key、Token 计费、Fallback 等 LLM 专属能力（完整能力与落地见 Q19）
• 模型灰度：新模型上线时只分配部分流量（如 10%），观察指标无异常后逐步提升到 100%
• Fallback：主模型不可用时自动切换到备用模型

为什么需要：模型数量多后必须版本管理；多团队共享需要统一入口和成本统计；新版本上线不能全量替换；模型故障需要自动兜底。

如何落地：MLflow 做 Registry，LiteLLM 做 AI Gateway，网关层按比例分流做灰度，配置 fallback 链做降级。

Q9：什么是 MoE 模型（总参数 vs 激活参数）？#

是什么：MoE（Mixture of Experts）是 2026 年大模型的主流架构范式。模型包含多个"专家"子网络，每次推理只激活其中部分。

• 总参数：模型中所有专家的参数之和，反映"知识容量"
• 激活参数：每次前向传播实际使用的参数量，反映"推理成本"

为什么需要：Dense 模型的能力和成本同时受限于参数量。MoE 让模型能力（总参数）和推理成本（激活参数）解耦——1.6T 知识容量但只算 49B 参数。

如何落地：以 DeepSeek-V4 为例（下文 1.6T/49B 为示例数字，实际以官方参数为准）：总参数 1.6T，激活参数 49B（约 3%）。部署时全部 expert 权重都要加载（显存需求大），但推理计算量小（速度快）。MoE 推理需要 EPLB 解决专家路由不均衡。

Q10：什么是 MLA（Multi-head Latent Attention）？#

是什么：DeepSeek 系列带火的核心技术，通过在 K 和 V 的计算中插入低秩瓶颈（latent space），将 KV Cache 的显存占用压缩到传统 MHA 的 1/8~1/16。

为什么需要：纯 MHA（KV head 数 = query head 数）的 KV Cache 在长上下文场景显存爆炸——同规模下每 token 约为 GQA 的 8 倍（LLaMA 70B GQA ≈ 320KB/token，等规模 MHA ≈ 2.5MB/token），128K 上下文的 MHA KV 可达数百 GB。MLA 压缩后同样显存可服务更多并发。（注：320KB 是 GQA 数字，别拿它论证"MHA 爆显存"。）

如何落地：MLA 缓存的是低秩 latent vector，decode 时从 latent vector 恢复完整 K/V。本质是用计算换显存。DeepSeek-V4 支持 1M 上下文，MLA 是关键使能技术。与 GQA/MQA 的区别：MLA 质量接近 MHA，而 GQA/MQA 有质量损失。

Q11：什么是推理的"引擎层"和"编排层"？#

是什么：2026 年推理服务化的关键架构分层。

• 引擎层：跑单个模型。vLLM、SGLang、TRT-LLM、Triton。负责 PagedAttention、Continuous Batching、量化等
• 编排层：管多个节点协同。NVIDIA Dynamo、llm-d。负责 disaggregated serving（PD 分离跨节点）、KV-aware routing、动态 GPU 分配

为什么需要：引擎层擅长"单模型单节点"，但跨节点 PD 分离、按 KV Cache 命中率路由、跨节点负载均衡需要上层调度器。

如何落地：引擎层 + 编排层不互斥，Dynamo/llm-d 站在 vLLM/SGLang 之上做跨节点调度。大规模（>10 节点）+ PD 分离场景引入编排层。

Q12：什么是 PD 分离（Prefill/Decode Disaggregation）？#

是什么：将 LLM 推理的 Prefill 阶段和 Decode 阶段分配到不同的 GPU 节点。Prefill 节点高算力配置，Decode 节点高显存带宽配置，之间通过高速网络传输 KV Cache。

为什么需要：Prefill（compute-bound）和 Decode（memory-bound）资源需求截然相反，放同 GPU 互相干扰。分离后各自独立优化，TTFT 降低 30-50%，吞吐提升 2-3x。

如何落地：vLLM KVConnector（引擎内）或 NVIDIA Dynamo（编排层）实现。需要 100Gbps+ RDMA 网络传输 KV Cache。2026 年已是生产主流（DeepSeek、Meta 大规模上线）。

Q13：什么是分级 KV Cache？#

是什么：三级 KV Cache 架构，把 KV Cache 从"全放 GPU"变成"分级存储"：

• L0（GPU HBM）：当前活跃请求的 KV，延迟 <1μs
• L1（CPU DRAM）：短期 LRU 淘汰的温 KV，延迟 ~10μs
• L2（SSD/NVMe 远端）：长期缓存/共享前缀，延迟 ~100μs

为什么需要：128K 上下文的 KV Cache 约 40GB，全放 GPU 显存太贵（H100 总共 80GB）。分级后热数据在 GPU，温冷数据在便宜存储。

如何落地：LMCache（Google GKE/CoreWeave/Cohere 已用于生产）或 HiCache（SGLang）。收益取决于可复用前缀占比和命中率——命中率越高、复用前缀越长，省下的 prefill 越多。（业界常引"128K 上下文、80% 命中率省约 69% prefill 成本"，这是特定 benchmark 条件下的数字，不是通用常数，机制与口径见 3-原理 Q12。）

Q14：什么是 EPLB（Expert Parallelism Load Balancer）？#

是什么：DeepSeek 开源的 MoE 专家并行负载均衡器。

为什么需要：MoE 模型的 expert 路由极度不均衡，热门 expert 负载是冷门的 10-20 倍。不解决则集群吞吐被热门 expert 所在 GPU 卡死。

如何落地：EPLB 动态调整 expert 到 GPU 的映射——将热门 expert 的副本分散到多张空闲 GPU，冷门 expert 合并到同一张 GPU。周期性重平衡，不影响在线请求。MoE 推理必备组件。

Q15：什么是 Chunked Prefill？#

是什么：将长 prompt 的 Prefill 阶段切成多个小块，与 Decode 交替调度。

为什么需要：防止一个超长 prompt（如 128K）的 Prefill 把整个 batch 的其他请求憋死——128K prefill 占满 GPU 2-3 秒，同 batch 的 decode 请求全部等待。

如何落地：vLLM 通过 --enable-chunked-prefill --max-num-batched-tokens 2048 开启。低延迟场景和长上下文场景建议常开。

Q16：什么是量化（FP8/INT8/INT4/FP4）？#

是什么：用低精度数据类型存储和计算模型权重，以降低显存占用和加速推理。

为什么需要：显存是推理成本的核心。以 70B 为例，FP16 权重约 140GB、FP8 约 70GB——权重本身在 H100-80G 上从需 2 卡放权重降到 1 卡即可，省下的显存还能留给更大的 KV Cache 池（更高并发），FP8 同时带来计算与 KV Cache 减半。（口径提醒：实际需要几张卡还要叠加 KV Cache 与激活，按 max-model-len 和并发目标测算，不能只看权重大小。）

如何落地：H100/H200 无脑 FP8（权重+激活+KV Cache 全 FP8）；A100 用 AWQ INT4 或 SmoothQuant INT8；精度敏感场景（代码/数学）至少 FP8。

Q17：什么是 OpenTelemetry GenAI 语义约定？#

是什么：OpenTelemetry 社区为 LLM/Agent 可观测定义的一组语义约定（span/metric/event 的标准属性命名）。重要口径：截至 2026 年，gen_ai.* 语义约定绝大部分仍处于 experimental / development 阶段——只有 client span 部分刚开始趋稳，agent/framework span 仍是 experimental，不存在"已正式发布的稳定完整标准"，仍在演进。

常用标准属性（部分，仍可能变动）：

• 请求：gen_ai.request.model、gen_ai.request.max_tokens、gen_ai.request.temperature、gen_ai.request.top_p
• 用量：gen_ai.usage.input_tokens、gen_ai.usage.output_tokens
• 响应：gen_ai.response.finish_reasons、gen_ai.response.id
• 操作/提供方：gen_ai.operation.name、gen_ai.provider.name（标识这条 telemetry 属于哪个 provider 的格式）

成本不是官方标准属性：规范里没有 cost_currency/cost_amount 这类字段。成本要自己用 token 数 × 单价算出来，再以自定义属性（社区惯例如 gen_ai.usage.cost_usd）挂上去。面试时说"OTel 内建成本属性/六层标准化属性"是错的。

为什么需要：不同推理引擎（vLLM/SGLang/TRT-LLM）和中间件（LiteLLM/LangChain）各有自己的指标格式，用统一约定后可标准化接入追踪与指标系统，不用为每个引擎写自定义 instrument。但因为还在 experimental，落地要锁版本、用 OTEL_SEMCONV_STABILITY_OPT_IN 控制属性版本，避免升级后属性名变动打爆看板。

如何落地：vLLM 启动加 --otlp-traces-endpoint，LiteLLM 配置 OTel 导出，统一接入 Jaeger/Tempo + Prometheus；成本属性自己算完再打点。

Q18：什么是 Speculative Decoding？#

是什么：投机解码——用小模型或额外预测头"猜"几个 token，大模型一次验证多个。

为什么需要：LLM decode 串行生成（每次 1 token），GPU 大量时间在等待。Speculative Decoding 把串行变成批处理验证，提升 GPU 利用率。

关键：不损失质量——大模型用 accept-reject（修正版拒绝采样）验证草稿 token，被接受 token 的分布与目标模型逐 token 一致，最终输出分布与不用投机解码完全相同（仅受硬件数值精度影响）。它只加速、不改变结果——这是它能无脑上生产的前提（原理见 3-原理 Q5）。

如何落地：Medusa（额外草稿头，1.5-2.5x）、EAGLE（特征预测 + tree attention，2-3x）。适用代码补全、格式化输出等输出规律强的任务；创意写作等不可预测任务加速比低（草稿命中率低），但质量不受影响，只是收益小。

Q19：什么是推理网关（AI Gateway）？#

是什么：LLM 推理的统一入口，在普通 API Gateway 之上增加 LLM 专属能力：模型路由、Virtual Key（租户隔离）、Token 计费、成本统计、Fallback、Prompt 审计、Guardrails。

为什么需要：普通 API Gateway 不懂 LLM——不知道 token、模型路由、prompt 成本。多模型、多团队共享需要统一入口做鉴权、限流、计费、审计。

如何落地：LiteLLM Proxy 是开源首选。配置 model_list（模型后端）+ router_settings（路由策略 + fallback）+ general_settings（master_key + database_url）。为每个业务线生成 Virtual Key 绑定模型白名单 + 预算 + RPM/TPM 限流。

Q20：什么是推理服务的冷启动？#

是什么：推理实例从零启动到能服务请求的过程，主要是模型权重加载。70B 模型冷启动 3-5 分钟，405B 模型 10-20 分钟。

为什么需要关注：scale-to-zero 场景下，第一个请求会触发冷启动，如果客户端 timeout 太短（30s）会超时失败。

如何落地：核心思路是"少加载、别缩零、给足时间"——权重预缓存本地 NVMe + keep-warm 至少 1 副本 + startupProbe 放宽 + 客户端 timeout 匹配 + 启动后发预热请求。完整优化清单见场景题 4-Q12。

Q21：什么是 KV-aware routing？#

是什么：编排层（Dynamo/llm-d）的智能路由策略，将请求路由到"KV Cache 已命中最长的节点"，避免重复 prefill。

为什么需要：分级 KV 管"去哪找缓存"，但同一前缀的 KV 可能只存在于部分节点。如果请求路由到没有缓存的节点，还得重新 prefill。KV-aware routing 把请求送到有缓存的节点。

如何落地：Dynamo/llm-d 在 Router 层查询各节点的 KV Cache 状态，选择命中前缀最长的节点。与分级 KV 互补使用。

Q22：什么是 RAG 推理？它和普通推理有什么不同？#

是什么：RAG（Retrieval-Augmented Generation）推理是在 prompt 中拼接检索到的知识库文档，再让模型生成回复。推理引擎本身不变，但 prompt 特征不同。

为什么需要区分：RAG 的 prompt 前缀（system prompt + 知识库文档）高度稳定且重复，是 Prefix Cache 和分级 KV 的最佳场景。

如何落地：RAG 推理优化重点——开启 Prefix Cache（vLLM）/ RadixAttention（SGLang）+ 分级 KV（LMCache）+ KV-aware routing。RAG 的 system prompt + 文档前缀高度重复，命中率往往能做得很高，省下的正是这部分重复前缀的 prefill 计算；具体比例取决于文档前缀在总 prompt 中的占比与命中率（别把某个 benchmark 的固定百分比当通用值）。

Q23：什么是推理服务的 SLA？#

是什么：Service Level Agreement，服务等级协议，定义延迟、可用性、质量等承诺。

为什么需要：没有 SLA 就没有扩缩容和告警的依据。业务侧需要知道"这个模型服务能保证什么"。

如何落地：LLM 推理 SLA 典型指标：

• TTFT P95 < 1s（实时对话）/ < 200ms（代码补全）
• TPOT P95 < 50ms
• 可用性 > 99.9%
• 错误率 < 0.1%
• 成本：单 token 成本 < X 元

Q24：什么是推理服务的 batch size？它怎么影响性能？#

是什么：每步 forward 处理的 token 数（不是请求数）。由 max-num-batched-tokens（vLLM）控制。

为什么需要：batch size 是吞吐和延迟的 trade-off 旋钮。大 batch → 吞吐高但单请求 TPOT 上升；小 batch → 延迟低但 GPU 利用率低。

如何落地：高吞吐场景 max-num-batched-tokens=8192-16384；低延迟场景 2048-4096。配合 max-num-seqs（最大并发序列数）一起调。

Q25：什么是推理引擎的 PagedAttention 和 RadixAttention？#

是什么：两种 KV Cache 管理机制。

• PagedAttention（vLLM）：类比 OS 虚拟内存分页，把 KV Cache 按 Block（16 token）分页，不要求连续显存。显存利用率 60% → 96%+。
• RadixAttention（SGLang）：把 KV Cache 组织成 Radix Tree，不同请求可共享任意长度的公共前缀。多轮场景命中率 60-85%。

为什么需要：传统 KV Cache 需要预分配连续显存，要么浪费（按最大长度分配）要么碎片化。分页/树结构解决这两个问题。

如何落地：vLLM 默认 PagedAttention；SGLang 默认 RadixAttention（--disable-radix-cache=false）。通用场景用 vLLM，多轮/Agent/RAG 用 SGLang。

Q26：什么是多模态 / VLM 推理？和纯文本推理有什么不同？#

是什么：VLM（Vision-Language Model，如 Qwen-VL、InternVL、Llama-Vision）在纯文本 LLM 前面接一个 vision encoder（通常是 ViT）+ 一个投影层（projector/connector）。图片先过 vision encoder 编码成视觉特征，再由 projector 映射成和文本 token 同维度的 "image token"，和文本 token 拼在一起喂给 LLM。

和纯文本推理的不同：

• image token 展开：一张图会展开成几百到几千个 token（分辨率越高、patch 越多，token 越多）。一张高清图轻松吃掉几 K 上下文，prefill 负担远大于同样字数的文本。
• prefill 特殊性：首 token 前要先跑完 vision encoder + projector（compute-bound），TTFT 里多一块"视觉编码"耗时；encoder 通常不与 LLM 一起做 continuous batching，容易成为独立瓶颈。
• 多模态 KV Cache：image token 进 LLM 后一样占 KV Cache，长图/多图请求 KV 占用很大；相同图片的视觉特征/KV 可缓存复用（多轮追问同一张图收益明显）。
• 前缀缓存：文本前缀能命中，但图片部分只有"同一张图"才可能命中（按图像 hash），前缀稳定性比纯文本 RAG 差。

如何落地：vLLM/SGLang 均支持主流 VLM；部署要点是给 vision encoder 留算力、按图像 token 数重新估算 max-model-len 和显存、对高分辨率图设 token 上限（避免单请求爆 KV）。

Q27：什么是约束解码 / 结构化输出（Structured / Constrained Decoding）？#

是什么：强制模型输出满足某种结构（JSON Schema、正则、EBNF 语法）的解码技术。做法是在每步采样前，把语法编译成状态机（FSM / 下推自动机 PDA），根据当前状态算出"合法 token 掩码"，把不合法 token 的 logits 置 -inf，模型只能在合法集合里采样——100% 保证输出结构正确，而不是靠 prompt"求"模型输出 JSON。

代表实现：Outlines（把正则/JSON Schema 编译成 FSM）、XGrammar（用下推自动机支持上下文无关文法，把语法编译搬到 C 层、配合词表分区与 token 掩码缓存，2026 年是 vLLM/SGLang/TRT-LLM 的默认结构化后端，速度最快）。

对吞吐的影响：

• 编译开销：首次遇到某个 schema 要编译状态机，复杂/首见 schema 有 compile 延迟，复用同一 schema 可摊薄（XGrammar 的 JIT + 缓存就是优化这块）。
• 每步掩码开销：每步要算合法 token 掩码，早期实现会拖慢 decode；现代实现用掩码预计算/缓存把这块降到很低，吞吐损失通常可控。
• 净收益：省掉"输出不合法 → 重试解析"的往返，端到端反而更稳更快。

如何落地：vLLM guided_json / guided_regex / guided_grammar（后端默认 XGrammar）；SGLang 原生约束解码。适合工具调用、Agent 参数、抽取类任务。

Q28：什么是 Multi-LoRA Serving（多适配器服务）？#

是什么：一个底座模型（base）+ 多个 LoRA adapter，在同一张卡/同一个引擎上同时服务不同微调版本。请求带上要用哪个 adapter，引擎推理时把对应的低秩增量（BA）叠加到 base 权重上。因为 adapter 很小（几十到几百 MB），可以驻留成百上千个。

为什么需要：多租户/多业务各有自己的微调版本，若每个都单独起满血实例，显存和成本爆炸。Multi-LoRA 让它们共享 base 权重和 KV Cache 池，边际成本接近单模型。

代表方案：S-LoRA（提出 Unified Paging——用统一显存池同时管理不同 rank 的 adapter 权重和不同长度的 KV Cache，配合异构批处理的自定义 CUDA kernel，单卡可服务上千 adapter，吞吐相比朴素方案提升数倍）；vLLM/SGLang 都内建 multi-LoRA 支持。

如何落地：--enable-lora --max-loras N --max-lora-rank R，请求里指定 adapter 名；冷/热 adapter 动态换入换出（LRU）；注意同一 batch 混不同 adapter 时的 kernel 效率与 max-loras 上限。

Q29：GQA / MQA 是什么？和 MHA、MLA 是什么关系？#

是什么：都是在"多少组 KV head"上做文章来压 KV Cache：

• MHA（Multi-Head Attention）：每个 query head 配一套独立 K/V head，KV Cache 最大。
• MQA（Multi-Query Attention）：所有 query head 共享一套 K/V head，KV Cache 最省，但质量损失偏大。
• GQA（Grouped-Query Attention）：折中——query head 分组，每组共享一套 K/V head（如 LLaMA 70B 是 64 query head → 8 组 KV head）。KV Cache 是 MHA 的 1/8，质量几乎无损，是当前开源模型主流。

和 MLA 的区别：GQA/MQA 靠减少 KV head 数量压缩（物理上少存几套 K/V）；MLA 靠低秩投影把 K/V 压成一个小 latent vector（存的东西变小，decode 时再恢复）。MLA 质量更接近 MHA、压缩比更高，但多了恢复计算。

为什么重要：KV Cache 大小直接决定并发和长上下文能力。"每 token 多少 KB"完全取决于 KV head 数——同规模模型，MHA 约是 GQA 的 8 倍。谈显存/并发估算前必须先问清是 MHA 还是 GQA。

Q30：temperature / top-p / top-k / logprobs 这些采样参数对推理意味着什么？#

是什么：控制 decode 阶段"怎么从下一个 token 的概率分布里采样"的参数。

• temperature：给 logits 除以 T 再 softmax。T→0 趋近贪心（确定、可复现），T 大更随机发散。
• top-p（nucleus）：只在累积概率达 p 的最小 token 集合里采样，动态截断长尾。
• top-k：只在概率最高的 k 个 token 里采样，固定截断。
• logprobs：返回所选 token（及 top-n 候选）的对数概率，用于置信度评估、重排序、评测、投机解码验证。

对推理/工程的意义：

• 可复现性：temperature=0（greedy）才可能复现，但即便如此，不同 batch 组成、不同并行度下的浮点累加顺序仍可能带来微小差异——"greedy 就一定 bit 级一致"是常见误解。
• 缓存/结构化：这些参数不改变 prefix cache 命中（KV 只与 token 序列有关），但会影响 speculative decoding 的接受率、结构化解码时的候选分布。
• 成本：参数本身不改吞吐，但 temperature 高、无 stop 约束容易让输出更长 → output token 更多 → 成本上升。
• 排查：线上"同样输入结果不稳定"先查是不是 temperature>0 或多实例路由到了不同版本。