推理服务化与加速

• PagedAttention 的显存分页复用机制
• 连续批处理与静态批处理（static batching）的差异
• 对吞吐、显存利用率与延迟的运维收益

PagedAttention 借鉴操作系统的虚拟内存分页思想，将 KV cache 按固定大小的块（block）分配，而非为每个请求连续预留整段显存。这样既避免了因预留不足导致的显存浪费，也消除了请求长度变化造成的显存碎片，GPU 显存利用率得以提升，吞吐量（tokens/s）较传统批处理方案可提升 2-4 倍。连续批处理（continuous batching / iteration-level scheduling）则是在每个解码步骤（iteration）动态地加入新请求、移出已完成请求，而不是像传统静态批处理那样等待一个 batch 全部完成才释放资源。两者结合，使吞吐量（tokens/s）大幅提升，同时保持较低的 TTFT 与 TPOT。

传统自回归解码中，一个 batch 中所有请求必须同步推进，慢请求会拖累整个 batch（头部阻塞）。连续批处理在 token 粒度调度，让 GPU 始终处于接近满载状态；PagedAttention 则从显存层面消除"预留浪费"与"碎片"，二者是吞吐优化的一体两面。运维上意味着同样显存可服务更多并发、支持更长上下文，从而降低单位 token 成本。

• 推理网关的注册与路由能力
• 灰度流量切分策略（权重、header、用户）
• 多模型统一入口与版本管理

推理网关（如基于 Envoy/Kong/自研，或 KServe 的 InferenceGraph、LiteLLM）作为统一入口，通过模型名+版本号注册后端，将请求路由到对应的推理服务实例。灰度切分可以是按权重（如 90/10 流量比例）、按请求属性（header、user_id、tenant）或按金丝雀标记进行。网关维护模型版本与后端实例的映射关系，支持版本拉新、流量逐步放大、异常时快速回退。

多模型多版本共存的核心是"模型版本与流量解耦"，网关负责把逻辑请求映射到具体物理后端。灰度切分让新模型先在真实流量子集上验证质量与延迟，降低全量发布风险。运维上还要求网关记录路由的模型版本信息，便于 trace 与成本分摊。

• 显存三部分的构成与估算
• KV cache 与 batch/并发的关系
• 显存预算与参数调优方法

推理显存主要由三部分构成：模型权重（W，与参数量×精度成正比）、KV cache（随 batch 大小、上下文长度、层数与注意力头数线性增长）、激活内存（transient，随 batch 与序列长度变化）。调优时先估算权重显存（如 7B FP16 约 14GB），再根据目标并发与上下文长度计算 KV cache 预算，最后用 vLLM 的 --gpu-memory-utilization 预留激活与碎片空间。batch 越大、并发越高的同时，KV cache 占比越大，需在"吞吐提升"与"显存容量"之间权衡。

权重是固定的，KV cache 是占用的大头且随并发动态增长。运维价值在于：通过数学估算（KV cache = 序列长度 × 层数 × 每层 KV 大小 × batch）在部署前预判最高并发与上下文，避免 OOM；同时可用 chunked prefill、量化降低权重与 KV 占用，从而放大可承载的 batch。

• TGI 与 vLLM 的核心特性对比
• 显存管理与吞吐优化手段差异
• 选型依据（生态、硬件、性能）

TGI 由 HuggingFace 维护，提供 Rust 内核的推理服务，内置 continuous batching、量化、GRPC/ephemeral 接口，与 HF 生态集成好，支持多 GPU 张量并行。vLLM 以 PagedAttention 为核心，支持显存分页复用、连续批处理、前缀缓存、投机解码，吞吐和其他优化特性更丰富，社区活跃度与吞吐 benchmark 通常更优。部署上二者都支持 Docker/K8s/KServe，均支持 OpenAI 兼容接口。

选型主要看指标与生态：vLLM 在吞吐与显存利用率上普遍领先，且最大化兼容 OpenAI 协议；TGI 在 HuggingFace 生态内集成与部分模型形态（如多模态）支持更友好。运维上还需关注双方对 CUDA、异构硬件（如 Ascend/ROCm）的支持程度，以及前缀缓存、投机解码等高级特性是否可用。

• KV cache 与上下文长度的关系
• OOM 防护手段（限流、截断、告警）
• 引擎级与网关级防护

上下文长度越长，KV cache 占用越大，超限时将触发显存 OOM。防护手段分多层：引擎层设置 max-model-len 作为硬上限，超限请求直接拒绝或按优先级截断；网关层按 token 数限流（如拒绝超过 max_input_tokens 的请求）；调度层控制并发序列数，避免同时大量长上下文请求挤爆显存；同时监控 KV cache 利用率与显存水位，接近阈值时提前告警并降级。

OOM 防护的核心是"先降解、后崩溃"。在请求进入前就按 token 预算做准入控制，比在引擎内崩溃后再恢复更可控。运维上要打通"请求上下文长度 → token 计费 → KV cache 预算"的链路，让网关与引擎共享同一套 token 估算，避免超限请求进入。还可结合前缀缓存减少长文档重复前缀的 KV 占用。

• 三层各自的职责边界
• 瓶颈识别与设计取舍
• 异步化与背压机制

分层架构通常为：推理网关（路由、鉴权、限流、灰度、token 计量）、请求队列（异步缓冲、削峰填谷、背压、优先级）、模型服务（真正执行推理，含连续批处理调度）。网关负责把复杂流量治理与推理解耦；队列解决"峰值流量超过引擎吞吐"时的不丢请求问题，并支持排队等待而非直接拒绝；模型服务专注吞吐与显存优化。瓶颈往往出现在队列积压（排队延迟上升）与网关单点（吞吐与连接数）。

设计要点是让每层职责单一、可独立扩缩。网关可按需多副本做水平扩展；队列用外部消息队列（如 Kafka/RabbitMQ/Redis scheduler）实现持久化与重试；模型服务是算力瓶颈，需配合连续批处理与自动扩缩。运维需监控每层耗时（网关耗时、排队时间、推理时间），定位慢在哪一层，再决定扩容哪一层的副本。

• 多副本下 KV cache 的会话隔离问题
• 会话亲和（sticky session）实现方式
• 无状态 KV cache 的替代方案

多副本下，同一会话的上下文状态（KV cache）保存在某个内存副本中，若请求被路由到不同副本则状态丢失。保证方式一是会话亲和（sticky session）：由网关基于会话 ID 哈希路由到固定副本，并配合定期健康检查在副本故障时迁移；二是上下文外部化：将对话历史（prompt）或 KV cache 持久化到外部存储，副本可随时重建，实现无状态。前缀缓存（PrefixCaching）在多副本间共享时，可配合分布式 KV cache 缓存服务。

会话亲和简单但绑定副本、损害负载均衡与弹性；外部化上下文更健壮但重建有成本。实际常采用"亲和为主 + 外部重建兜底"：正常时亲和路由保证命中，副本故障时允许重路由并重建上下文。运维上要监控亲和命中率与会话迁移频率。

• 动态批处理（continuous batching）机制
• 延迟与吞吐的权衡
• 批处理参数的调优

动态批处理即连续批处理（iteration-level batching）：在每一解码步动态加入新请求、完成并移除已完成请求，使 GPU 始终处于高利用率状态，同时避免静态批处理中"慢请求拖累整批"的头部阻塞。为控制延迟，需设置最大等待窗口（max_num_seqs、max waiting time）与最长序列预算，保证每步有足够梯度的请求填充 batch，但不让请求等待过久。

GPU 利用率与延迟的权衡核心在"batch 填充率"与"等待时间"。请求太少则 GPU 空转，等待太久则 TTFB 恶化。运维上通过监控平均 batch 大小、GPU 利用率与 TTFT 的关系，动态调整 vLLM 的 max_num_seqs 与 queue 参数，使高吞吐与低延迟达到平衡。这也是扩容告警的重要依据。

• 扩缩容指标选择（队列长度、吞吐、GPU 利用率）
• 冷启动来源（模型加载、图编译）
• 扩缩容策略与预热

自动扩缩的关键指标是"排队长度/等待时间"与"吞吐利用率"，而非单纯的 CPU，因为 GPU 推理的瓶颈在排队与显存。常用 HPA 基于自定义指标（如请求队列长度、进入队列的积压、GPU 利用率）触发扩缩；缩容则需保守，避免频繁重建权重。冷启动主要来自模型权重加载与 CUDA graph 编译，可采取：预留常驻副本、启动时预热请求（warmup）、共享模型存储（如本地缓存/页缓存）、使用 KServe 的 scale from zero 配合预热。

扩缩容设计的核心是"指标要反映真实瓶颈"：队列长度反映积压，GPU 利用率反映算力紧张。冷启动与扩缩容矛盾——扩缩容越快，冷启动影响越大，因此要么保留热备副本，要么用预热脚本把权重和图优化提前完成。监控上要区分"新副本就绪时间"与"真正可服务时间"。

• 量化类型与精度损失
• 质量评估方法（离线评测）
• 延迟/吞吐收益验证

量化（如 INT8、FP8、AWQ 的 4bit 权重量化）通过降低权重与激活精度减少显存占用并提升吞吐，但会引入近似误差，可能影响输出质量。运维验证需建立"量化前后的对照评测"：用同一离线评测集（如 MMLU、GSM8K、业务 case 集）对比量化前后 pass-rate/准确率，同时用压测对比量化前后的延迟、TTFT/TPOT、吞吐与显存占用。只有质量损失在可接受范围内且收益显著时才允许上线。

量化质量损失的评估必须结合业务语义，不能只看困惑度。运维上要建立量化模型的"质量门禁"流程：量化产物需通过评测集指标阈值（如准确率下降 < 1%），并做灰度对比线上输出。延迟收益要实测而非估算，因为量化有时反而不利于某些硬件（如缺少 INT8 加速的卡）。

• 前缀缓存/提示词复用原理
• 命中率对成本与延迟的影响
• 收益评估方法

前缀缓存（vLLM 的 prefix caching、SGLang 的 RadixAttention）将对公共前缀（系统提示、文档、few-shot 示例）的 KV cache 计算出来并复用，避免对相同前缀重复 prefill。实现上可用基于 Radix 树的前缀匹配，支持前缀共享与 LRU 淘汰。命中率越高，越多的 prefill 计算被跳过，TTFT 显著下降、吞吐提升、token 成本（prefill 算力）降低。收益评估可通过"前缀命中率"指标与"重复 prefill 节省的 GPU 时间"量化。

前缀缓存尤其适合"长公共系统提示 + 模板化场景"（客服、文档问答）。收益核心在 prefill 阶段（对长 prompt 的 token 计算量大），命中即省。运维上要监控前缀命中率、缓存大小与淘汰率，并设计缓存 key 使公共前缀稳定（避免把用户个性化内容混入前缀）。

• 冷启动的两大来源（权重加载、图编译）
• 预热方法与策略
• 首请求延迟优化

冷启动延迟主要来自两部分：模型权重从存储加载到显存（GB 级，耗时秒级到分钟级），以及首次推理时的 CUDA graph 捕获与算子编译（耗时数秒到数十秒）。预热（warmup）方法包括：镜像时预加载权重或使用本地缓存/页缓存；服务启动后立即发送若干构造的预热请求，触发 CUDA graph 捕获与显存分配；预留常驻副本避免冷启动出现在热路径；KServe 支持 scale-from-zero 配合 warmup 探针。

首请求延迟直接决定用户体验，冷启动若发生在真实请求上会显著放大 P99。运维上把预热作为"就绪门禁"的一部分——只有预热完成（就绪探针通过）才对外服务，避免把冷启动成本转嫁给用户。监控上需区分"启动就绪时间"与"可服务时间"。

• 多租户配额与限流
• 优先级队列与排队策略
• 降级与保障机制

多租户隔离通过"配额 + 优先级 + 降级"三层实现：配额层按租户配置 QPS 与 token 配额（rate limit），超限请求排队或拒绝，并支持突发（burst）与公平调度；优先级层在队列中区分关键业务（VIP）与普通业务，优先级高的请求优先获得调度；降级层在资源紧张时，对低优先级租户限速、降级（如缩短上下文、降低输出质量）或丢弃，保障高优先级核心业务。可用网关 + 队列（如基于 Redis/vLLM 的多租户调度）实现。

多租户隔离的核心是"坏邻居隔离"——一个租户的流量洪峰不能拖垮其他租户。需要同时有配额准入（防止超售）与优先级调度（资源紧张时保核心）。运维上要监控各租户的配额使用率、排队时间与降级次数，形成"配额治理报表"并按业务线分摊成本。

• 显存碎片的产生原因
• 多模型共存策略（按需加载、预留、调度）
• 碎片整理与调度优化

显存碎片来自不同模型（或不同大小请求）反复分配/释放显存，导致地址空间被切成小块，无法容纳整块请求。降低碎片影响的手段：按需加载——模型在使用时才加载到显存，闲置即卸载，避免常驻占用；显存预留——为常驻模型预留固定显存区，减少动态分配；模型调度——用 Binpack/Spread 策略安排模型在 GPU 上的布局，配合内存池（如 cudaMallocAsync）与统一设备内存管理。vLLM 的 PagedAttention 本身也缓解了 KV cache 碎片。

多模型共存的关键在于"显存是稀缺资源，需按使用率调度"。碎片问题的本质是分配粒度过大且频繁，PagedAttention（分页）与内存池（细粒度复用）能显著缓解。运维上要监控 GPU 显存碎片率与模型加载/卸载频率，平衡"常驻带来的热切换"与"按需加载带来的冷启动"。

• 三种手段的原理与收益
• 各自的代价与适用场景
• 组合使用与权衡

量化通过降低精度减少显存占用与带宽需求，收益是吞吐提升、可承载更大 batch，代价是潜在精度损失与部分硬件不支持低精度加速。动态批处理（连续批处理）通过 token 粒度调度提升 GPU 利用率，收益是吞吐显著提升，代价是实现复杂度与可能的调度开销。投机解码用一个小模型（draft model）先预测多个 token，再由大模型并行验证，收益是单请求延迟下降（减少序列化解码），代价是额外显存与 draft 模型质量不稳定时可能更慢。

三种手段解决不同瓶颈：量化解决显存/带宽瓶颈，动态批处理解决利用率瓶颈，投机解码解决延迟瓶颈。组合使用时需注意叠加效应（如量化后的 draft 模型），遇不一致时择机取舍。运维上应针对不同瓶颈场景选择对应手段并实测收益。

• 三个版本的解耦思想
• 版本标识与产物管理
• 灰度发布流程

模型版本、引擎版本与提示词版本是三个独立维度，应分别版本化并解耦：模型版本用模型注册表（Model Registry）管理权重与元数据；引擎版本用镜像管理（vLLM/TGI 升级）；提示词版本用 Prompt 管理平台管理。发布时三者可独立灰度——如升级引擎版本但保持模型与提示词不变，或改提示词但不动模型。每个请求要携带三者的版本信息（request metadata），便于追溯与回滚。

解耦的核心是"三个版本各自建立可回滚的发布单元"，避免一次性大爆炸发布。运维上通过统一的请求元数据（model_version、engine_version、prompt_version）实现可观测性与事故定位；任一变更是独立变更，可单独灰度、单独回滚。

• 传统健康检查的局限
• 亚健康检测手段
• 质量探针与降级

传统就绪/存活探针只检查进程存活与接口响应，无法反映"能生成但不准确"的亚健康。检测手段包括：质量探针——周期性向服务发送带已知期望答案的校验请求，比对输出质量（相似度/正确率）；统计指标——监控重复生成率、空输出率、异常 token 率等异常信号；黄金样本集——用固定评测集周期性打分，偏离基线即告警。亚健康时通过灰度回落或自动切换备选模型降级。

让健康检查反映质量，本质是把"功能性健康"扩展到"质量健康"。质量探针有成本（占用推理资源），应低频采样并与真实流量结合。运维上建立"质量基线"并设置容忍阈值，量化漂移即触发降级，这比等待用户投诉更早发现模型劣化。

• 多副本负载均衡
• GPU 故障检测与隔离
• 请求重试策略

高可用设计：多副本负载均衡——网关按负载与亲和把请求分发到多副本，避免单点并实现水平扩展；GPU 故障检测——通过 nvidia-smi、DCGM、健康检查监控 GPU 状态（ECC 错误、温度、驱动异常），故障时自动摘除副本并重启/隔离；请求重试——对瞬时故障（超时、连接断开）在幂等前提下重试到其他副本，重试需带退避（backoff）与次数上限，避免雪崩。结合探针把故障副本从负载均衡中摘除。

高可用的核心是"故障自动隔离 + 快速重试"。GPU 故障是硬故障，需尽早检测并摘除，避免请求被反复发给坏卡。重试必须控制放量（避免重试风暴），并对耗时类请求限制重试次数。运维上要监控副本健康状态、故障摘除次数与重试率。

• 核心性能指标采集
• GPU 资源指标采集
• token 计费与告警阈值

TTFT（首 token 延迟）、TPOT（每输出 token 时间）与吞吐（tokens/s）由推理引擎（vLLM 等）暴露的 metrics 采集，可通过 Prometheus 拉取；GPU 利用率、显存、温度、功耗由 DCGM exporter 采集。token 计费在网关侧统计输入/输出 token 数并归属到业务线。告警上：TTFT/TPOT 设 P99 阈值，吞吐与 GPU 利用率设下限（利用率低提示资源浪费），token 成本设配额告警。

推理指标的特殊性在于"token 维度"而非纯请求维度。TTFT 反映首帧体验，TPOT 反映生成速度，两者需分别设阈值。GPU 利用率与 token 计费联动能发现"贵但利用率低"的资源浪费。告警要分层：性能类（延迟/吞吐）、资源类（GPU）、成本类（token 配额）。

• CUDA graph 原理与收益
• 算子融合对连续批处理的影响
• 收益验证方法

CUDA graph 把一串 GPU 内核捕获为一张图，一次性提交，减少内核启动开销（CPU 侧开销），对短序列/小批量尤为显著，可降低延迟抖动。算子融合（如 attention 与激活融合、FlashAttention）减少内核间内存往返，提升吞吐。连续批处理中动态 shape 会破坏静态 CUDA graph，需用捕获时设定 shape 或配合动态图模式。验证收益通过压测对比开启/关闭 CUDA graph 与融合的 TTFT、TPOT、吞吐与 GPU 利用率。

图优化与算子融合的收益在"减少内核启动与内存往返"上，属于引擎级优化，需在真实负载下验证而非纸面估算。使用时注意动态 shape 与 CUDA graph 的兼容性，必要时用 chunked prefill 或固定 batch 模板。运维上通过 A/B 基准对比选择最优配置。