外观
模型部署术语表
使用建议
本术语表按主题分组，不需要按顺序从头读到尾——把它当成一本词典：遇到不认识的词，用浏览器搜索（Ctrl+F）直接查。每组末尾会对易混淆的术语做单独辨析；带「详见」链接的条目可以跳转到对应章节深入阅读。
基础概念
模型部署（Model Deployment） 把训练好的模型以可服务、可扩展、可观测的形态接入生产系统的全过程，包括模型转换与优化、服务封装、上线发布、监控与迭代。部署不是「导出模型文件」这一步，而是一个持续的生命周期。详见 什么是模型部署。
推理（Inference） 使用训练好的模型对新的输入数据做出预测的过程。推理与训练共用前向传播，但约束完全不同：推理关注延迟、吞吐与成本，且通常使用低精度、编译优化后的模型。
前向传播（Forward Pass） 数据从输入层逐层计算到输出层的过程。训练阶段用它计算损失，推理阶段只保留前向传播部分（没有反向传播与梯度）。
模型服务（Model Serving） 把模型封装成可通过 HTTP/gRPC 等接口访问的在线服务的工程实践，包含请求/响应协议、批处理、模型加载与生命周期管理、健康检查、扩缩容等。详见 服务化与推理 API。
推理引擎（Inference Engine） 负责实际执行模型计算的软件运行时，如 ONNX Runtime、TensorRT、OpenVINO、llama.cpp 等。它负责把计算图映射到底层算子库（cuDNN、oneDNN 等）与硬件上，是「模型服务」下面的执行层。
MLOps 把 DevOps 实践（CI/CD、自动化、监控、可观测性）应用到机器学习全生命周期的工程文化与方法论，覆盖数据、训练、评估、部署、监控与治理。部署是 MLOps 的一个环节，而非全部。详见 MLOps 部署流水线。
模型注册（Model Registry） 集中管理模型制品（版本、元数据、血缘、状态 staging/production）的组件，是模型从实验到生产的「关卡」。代表实现：MLflow Model Registry、Hugging Face Hub、Kubeflow Hub。
数据漂移（Data Drift）输入数据的分布相对训练集发生变化，例如用户群体结构改变、特征取值范围漂移。数据漂移是模型性能下降的常见前兆。
概念漂移（Concept Drift）输入与输出之间的映射关系发生了变化，即「同样的输入，正确的答案变了」。例如风控规则收紧后，同样特征的用户违约概率显著上升。
模型漂移（Model Drift） 模型实际预测性能随时间退化，是数据漂移、概念漂移等因素共同作用的结果。线上通常用 PSI、KS 等指标间接探测。
辨析：推理 vs 推理引擎 「推理」是模型计算这个行为/过程（一次前向传播）；「推理引擎」是执行这个行为的软件。类比：推理 = 「跑」这个动作，推理引擎 = 「腿」这个器官。服务框架（如 Triton、FastAPI）负责调度与协议，推理引擎负责算。
辨析：数据漂移 vs 概念漂移 一句话记忆：数据漂移是「输入变了」，概念漂移是「规则变了」。它们都可能表现为线上指标（如 PSI、KS）异常，但应对方式不同——前者需要重采样/补充数据，后者往往需要重训。
模型与格式
ONNX（Open Neural Network Exchange） 开放、中立的模型交换格式，用计算图统一描述模型结构，实现在 PyTorch、TensorFlow 等框架与推理引擎之间的互操作。详见 模型格式与转换。
TorchScript PyTorch 的静态图序列化格式（.pt/.torchscript）。通过 torch.jit.trace 或 script 生成，可脱离 Python 运行。相比 ONNX，对 PyTorch 算子覆盖更全，但生态互操作不如 ONNX。
TFLite（TensorFlow Lite） TensorFlow 面向移动端/嵌入式设备的轻量格式（.tflite），支持 INT8/FP16 量化，配合 TFLite Runtime / LiteRT 在 Android、iOS、MCU 上运行。
TensorRT engine（.engine / .plan） NVIDIA TensorRT 将 ONNX 等模型编译后生成的高度特化的引擎文件。它绑定具体的 GPU 架构、批大小与精度配置，换显卡或改配置必须重新构建。详见 TensorRT 与边缘部署。
GGUF llama.cpp 生态的模型权重格式，把权重、分词器、超参数打包为单个文件，支持 2~8 bit 整数量化，便于在 CPU/低显存设备上运行本地大模型。
SafeTensors Hugging Face 主导的权重存储格式，核心特性是文件头部记录每张张量的偏移与形状，加载时无需把整个文件读入内存，比 PyTorch 的 pickle 更安全（不执行任意代码）且加载更快。
opset（Operator Set） ONNX 算子集的版本号。每个版本新增或修改算子定义；opset=17 表示模型使用 ONNX 17 号算子集。转换时 opset 过高可能超出目标运行时支持的版本。
动态轴（Dynamic Axes） 模型中允许在推理时变化的维度，典型是批大小（batch）和序列长度。启用动态轴更灵活，但会降低某些引擎（如 TensorRT）的编译优化空间。
计算图（Computational Graph） 把模型表示为「张量流经算子」的有向无环图，是 ONNX、TorchScript、TensorRT 等格式的公共抽象。图优化（算子融合、常量折叠）都发生在这一层。
中间表示（IR, Intermediate Representation） 介于「源框架图」与「目标硬件指令」之间的模型表示。ONNX 是通用 IR，OpenVINO IR（.xml+.bin）是面向其运行时的专用 IR。IR 是编译器/推理引擎分层设计的核心概念。
压缩与优化
量化（Quantization） 用更低精度（如 INT8、FP16、INT4）近似表示权重和/或激活，换取更小的模型体积、更低的显存带宽与更快的计算。精度损失可通过校准与算法改进来控制。详见 量化。
PTQ（Post-Training Quantization，训练后量化） 用少量校准数据统计激活分布后直接量化，不需要重训。成本低、落地快，是绝大多数部署场景的首选；精度敏感时再升级到 QAT。
QAT（Quantization-Aware Training，量化感知训练） 在训练/微调阶段就模拟量化误差（在权重上插入假量化算子），让模型学会容忍低精度。精度最好但需要训练资源。
FP16（半精度浮点） 16 位浮点（1 符号位 + 5 指数位 + 10 尾数位）。相比 FP32 显存减半、带宽占用减半，是 GPU 推理的默认精度。
BF16（Brain Float 16） 16 位浮点但保留与 FP32 相同的 8 位指数、只截断尾数。动态范围与 FP32 一致，适合训练与数值敏感的推理；代价是尾数精度更低。主要作用于 Ampere 及以后架构。
INT8 8 位整数量化。权重与激活以 INT8 计算，通常配合 per-channel/per-tensor 缩放因子（scale/zero-point）。推理速度与能耗显著优于 FP16，但需要校准。
GPTQ（GPT Quantization） 面向 LLM 的训练后权重量化方法（单样本二阶误差最小化），典型得到 4-bit 权重（W4A16）。由论文 GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers 提出，详见 量化经典论文。
AWQ（Activation-aware Weight Quantization） 面向 LLM 的训练后权重量化方法，基于「保护少量对激活影响大的关键权重通道」的思路，4-bit 下质量优于 GPTQ，且对校准集更鲁棒。
蒸馏（Knowledge Distillation） 让一个小模型（student）模仿大模型/集成（teacher）的输出分布来学习，是「模型变小但保持能力」的经典手段。详见 蒸馏、剪枝与低秩分解。
剪枝（Pruning） 移除网络中不重要的权重或神经元（结构化/非结构化），减少计算量与体积。非结构化剪枝需要稀疏算子支持才能兑现加速。
稀疏化（Sparsity） 使权重矩阵中大量元素为零并利用稀疏格式（2:4 稀疏等）跳过零计算。NVIDIA 在 Ampere 架构上通过结构化稀疏提供约 2 倍加速。
低秩分解（Low-Rank Factorization） 把大权重矩阵分解为两个小矩阵的乘积（如 SVD 分解），减少参数量与计算量。LoRA 在训练侧的「低秩适配」思想与之同源。
辨析：PTQ vs QAT 一句话选择：先试 PTQ——它不需要训练，5 分钟就能得到结果；精度不达标且资源允许时再上 QAT。QAT 精度上限更高但成本高一个数量级。
服务与架构
在线推理（Online Inference） 面向实时请求的服务形态：客户端发起请求，服务端同步返回预测，要求低延迟（通常 p99 < 数百毫秒）。典型实现为 HTTP/gRPC 微服务。详见 部署架构模式。
批处理（Batch Inference / Offline） 把大量样本一次性送入模型批量计算，最大化吞吐、摊薄开销，适合离线打标、ETL 类任务，对延迟不敏感。
动态批处理（Dynamic Batching） 服务端把短时间内到达的多个请求自动攒批，凑满一个 batch 后一次执行，从而在保持在线服务的同时提高 GPU 利用率。以最大延迟预算（max_batch_delay）为代价换取吞吐。
连续批处理（Continuous Batching） 面向 LLM 流式生成的调度：请求按 token 粒度动态进出 batch，一个请求生成完立即让出位置给新请求，而不是等整个 batch 同步结束。是 vLLM、TGI 等提升 LLM 吞吐的核心机制。详见 大模型推理优化。
流式推理（Streaming Inference） 服务端边生成边把部分结果（token/分片）推送给客户端（SSE / gRPC stream），显著降低用户的首字等待感知。LLM 聊天场景的事实标准。
边缘部署（Edge Deployment） 把模型部署在靠近数据源的设备上（手机、摄像头、车机、Jetson 等），换取低时延、离线可用与数据隐私。详见 TensorRT 与边缘部署。
Serverless 按请求粒度计费、自动缩放到零的平台形态（如 AWS Lambda、KServe Serverless 模式）。适合流量波动大、延迟要求不极端的场景；冷启动是主要代价。
负载均衡（Load Balancing） 把请求分发到多个模型副本，均衡负载并容忍单点故障。在推理场景常叠加感知队列长度/显存的路由策略。
灰度发布 / 金丝雀发布（Canary / Gray Release） 先把新版本暴露给一小部分流量，验证无异常后再逐步放量。是模型上线最稳妥的发布方式。
蓝绿部署（Blue-Green Deployment） 同时运行新旧两套环境，切换入口流量实现秒级发布与回滚。两套资源并存、成本更高，但回滚最简单。
A/B 测试（A/B Testing） 把流量按策略切分给不同模型（版本），用业务指标（转化率、满意度等）统计性地评估哪个更好。与灰度发布的区别：灰度关注「稳定上线」，A/B 关注「效果比较」。
辨析：批处理 vs 动态批处理 离线批处理是「数据侧攒一批再算」，用户等待结果即可；动态批处理是「服务侧把并发请求攒批」，目的是榨干 GPU 而牺牲一点延迟。前者面向任务，后者面向实时流量。
辨析：在线推理 vs Serverless 在线推理是架构形态（常驻服务、低延迟），Serverless 是平台计费/扩缩容模式（按调用计费、可缩零）。你可以用 Serverless 平台承载在线推理，但 Serverless 也常被用作批处理或事件驱动入口。
硬件与性能
显存带宽（Memory Bandwidth） GPU 显存每秒可读取的数据量（GB/s）。对 LLM 解码这类访存密集型任务，显存带宽直接决定 token 生成速度上限（memory-bound）。详见 GPU 与硬件选型。
TFLOPS（Tera FLOPs per Second） 每秒万亿次浮点运算，衡量 GPU 的算力上限。卷积/矩阵乘等计算密集算子的瓶颈是算力（compute-bound）。
KV Cache LLM 推理时为避免重复计算历史 token 的 K/V 注意力而缓存的中间张量。随序列长度线性增长，是 LLM 显存占用的主要来源，也是 PagedAttention 等内存优化技术的靶点。
TTFT（Time To First Token） 从请求发出到收到第一个输出 token 的耗时。它主要受**预填充（prefill）**阶段影响，是衡量「响应快不快」的关键指标。
TPOT（Time Per Output Token） 每生成一个输出 token 的平均耗时。解码阶段逐 token 串行，TPOT 决定打字机的流畅度。整个输出延迟 ≈ TTFT + TPOT × (输出长度 − 1)。
P99（99th Percentile） 排序后第 99 百分位的延迟值，代表「最差 1% 用户」的体验。服务性能一般以 P50/P99 双指标描述，P99 对长尾更敏感。
QPS（Queries Per Second） 每秒处理的请求数，是服务容量的直观度量。压测与容量规划围绕「目标 QPS 下的 P99 是否达标」展开，详见 压测与容量规划。
吞吐（Throughput） 单位时间处理的样本/Token 总数（如 tokens/s、requests/s）。吞吐与延迟常互相制衡：动态批处理提吞吐会升延迟，压测时需要找到平衡点。详见 性能优化与容量规划。
NVLink NVIDIA 的 GPU 间高速互联总线，带宽远高于 PCIe。张量并行等需要频繁通信的分布式推理依赖 NVLink 获得近线性扩展。
CUDA NVIDIA 的 GPU 通用计算平台与编程模型。CUDA 版本、驱动版本、cuDNN/cuBLAS 库的匹配关系是部署排障的头号问题之一（见 系统基础速查 的 GPU 环境一节）。
监控与运维
PSI（Population Stability Index） 衡量两个分布整体偏移量的指标，常用于监控特征/评分分布漂移。经验阈值：<0.1 稳定，0.1~0.25 需关注，>0.25 严重漂移。详见 监控与可观测性。
KS 检验（Kolmogorov–Smirnov Test） 非参数假设检验，比较两样本分布的最大累计差异。在模型监控中用于判断分布是否发生了统计显著的漂移，也可用于衡量评分对正负样本的区分度。
SLI（Service Level Indicator） 服务质量的量化度量，如可用性 99.9%、P99 延迟、错误率、QPS。是 SLO 的度量依据。
SLO（Service Level Objective） 团队承诺的服务质量目标，如「P99 延迟 < 500ms，月度达成率 ≥ 99.5%」。SLO 定义了「什么算好」，并驱动告警与容量规划。
SLA（Service Level Agreement） 与外部客户签署的服务合同条款，通常比内部 SLO 更宽松（给自己留余量）。违约伴随赔偿/处罚。
可观测性（Observability） 通过指标（Metrics）、日志（Logs）、链路（Traces） 三支柱（三信号）回答「系统为什么变成这样」的能力。模型服务还需叠加模型质量指标（准确率、漂移、LLM 质量分）。详见 可观测性落地。
OpenTelemetry（OTel） CNCF 孵化的开源可观测性标准，统一定义 Trace/Metric/Log 的 API、SDK 与采集协议（OTLP），是接入各类后端（Prometheus、Grafana、Jaeger 等）的公共层。
Prometheus CNCF 的时序数据库与监控系统，通过拉取模型抓取指标，配合 PromQL 查询与 Alertmanager 告警，是 Kubernetes 与推理服务监控的事实标准。
告警（Alerting） 基于规则（阈值、SLO 燃尽等）触发通知的机制。与 SLO 配合时，告警应「可行动」（actionable）：收到告警 → 知道该干什么。避免大量无关告警导致的告警疲劳。
辨析：SLO vs SLA SLO 是你给自己定的内部工程目标（可收紧、可迭代），SLA 是对外承诺的合同条款（留缓冲、带后果）。业内常见做法：SLA 比 SLO 略宽，避免把对外承诺绑死在内部目标上。
LLM 推理
自回归生成（Autoregressive Generation） LLM 逐个 token 预测输出的过程：每个新 token 依赖之前所有 token。解码阶段逐 token 串行，且要携带全部历史上下文，这是 KV Cache 与连续批处理存在的根本原因。
投机解码（Speculative Decoding） 用一个小「草稿模型」一次性猜多个 token，再由大模型并行验证，通过则一次接受多步、失败则回退。在保证输出分布等价的前提下，可将解码速度提升 2~3 倍。
前缀缓存（Prefix / Prompt Caching） 缓存已计算过的公共前缀（system prompt、历史会话）的 KV，新请求直接复用，显著降低 TTFT 与算力消耗。vLLM 的自动前缀缓存（APC）即此机制。
张量并行（Tensor Parallelism） 把单层权重按维度切分到多张卡，各卡协同计算同一层。通信频繁，依赖 NVLink/高速网络，是单机多卡推理的默认并行方式。
流水并行（Pipeline Parallelism） 按层把模型切成多段放在不同卡上，数据依次流经各段（micro-batch 流水化）。适合跨机部署超大模型，通信量远小于张量并行，但存在流水气泡。
PagedAttention vLLM 提出的 KV Cache 分页管理机制：把 KV 按固定大小的块（block）分配，物理不连续、按需分配，消除显存碎片并支持跨请求共享公共前缀。vLLM 的立身之本，详见 PagedAttention 论文精读。
预填充 / 解码（Prefill / Decode） LLM 生成的两阶段：Prefill 一次并行处理整个 prompt，产生首个 token 并填充 KV Cache；Decode 逐 token 生成并更新 KV。两阶段算力/访存特性差异极大，是分离式部署（disaggregated serving）与调度优化的基础。
采样参数（Top-k / Top-p / Temperature） 控制解码随机性的参数：Top-k 只保留概率最高的 k 个 token，Top-p 只保留累计概率达阈值的 token，Temperature 缩放概率分布的尖锐程度。它们是推理 API 的通用参数，不影响显存与吞吐（只影响输出质量）。
LoRA（Low-Rank Adaptation） 低秩适配：冻结原权重，只训练两个小低秩矩阵作为增量。部署时增量可与基座合并（merge）或动态加载，实现低成本多模型切换。
上下文窗口（Context Window） 模型一次能处理的最大 token 数（输入 + 输出）。超长上下文依赖更高效的注意力与更大的 KV Cache 管理，是长文本推理优化的主线之一。
辨析：KV Cache 与显存 LLM 推理时显存中除了模型权重，还要为每个并发请求的每个已生成 token 预留 KV Cache。这就是为什么「模型只有 7B 却要 40GB 显存」——并发数与上下文越长，KV 越大。量化 KV Cache 与 PagedAttention 都是从这块「动态内存」里省空间。