模型部署与发布

• 模型服务高可用的复制与弹性
• 优雅停机与在途请求排空
• 健康检查（存活/就绪）与流量摘除

模型服务高可用设计包括多副本冗余、弹性扩缩容、健康检查、优雅停机与流量摘除。多副本通过 HPA/自定义指标按 QPS、GPU 利用率、队列长度扩缩容，副本间无状态（模型权重只读）可水平扩展；健康检查分存活探针（进程存活）与就绪探针（模型已加载、可服务请求），就绪探针失败时从 Service/负载均衡摘除流量，避免把请求路由到未就绪的副本；优雅停机要求先停止接收新流量（摘除），再排空在途请求（等待当前推理完成），最后释放 GPU 显存并退出，避免在途请求被中断或 GPU 未释放。差异上，模型服务相比业务服务更"重"：启动慢（需要加载权重、CUDA 初始化），就绪延迟高，因此就绪探针与冷启动预热更关键；有显存等稀缺资源，需防内存泄漏与显存碎片；推理是长占用计算，需考虑并发与批处理压力；部分场景（如 on-demand 特征）有状态依赖。因此模型服务常用"预热 + 就绪门 + 优雅退出 + 迁移"的组合来保证高可用。

高可用题要覆盖"复制、探针、摘流、优雅停机"四个动作，并点出模型服务"启动慢、GPU 资源、在途长请求"与业务服务的差异。

• 模型版本与 stage 管理
• 版本不可变性（immutable）与元数据固化
• 可回滚性（回滚条件、操作流程）

模型版本管理要求每个版本不可变：模型产物（权重、tokenizer、预处理配置、依赖、指标）与元数据（训练数据、特征版本、超参、commit）在发布时一次性固化，不可覆盖，任何变更都产生新版本。MLflow Model Registry 提供 model version、stage（Staging/Production/Archived）、注册依赖与注释，配合对象存储保存不可变产物；自建时可复用"对象存储 + 元数据库 + 版本号"实现同样能力。可回滚性依赖"不可变版本 + 元数据完整"：由于版本不可变，可随时把某个副本切回旧版本；回滚时选择历史 Production 版本，重新部署到推理服务，并配合灰度观察。为保证回滚可操作，需在发布时记录"上一可用版本"、部署清单与配置，并测试回滚路径（如蓝绿/金丝雀中旧版本始终在线）。此外应提供版本提升/回滚的审批与审计日志，防止误操作。

版本题核心是"不可变 + 元数据完整 + 可回滚路径"。回答要强调不可变性是回滚的前提。

• 三种策略的实现机制
• 流量分配与切换方式
• 效果验证与回滚

蓝绿部署：同时维护 Blue（旧）与 Green（新）两套完整环境，新版本（Green）全量部署并验证通过后，通过负载均衡一次性把流量从 Blue 切到 Green，切换快、回滚快（切回即可），但需双倍资源。金丝雀发布：新版本先接入小比例流量（如 5%），逐步递增并实时对比新旧版本指标，达标后全量，风险可控、可逐步回滚，适合对资源占用敏感的场景。影子流量：新版本以"影子"方式接收线上请求的复制流（shadow traffic），但结果不返回给用户、不影响线上，用于在真实流量下验证新版本的正确性、性能与效果，是"零风险"的验证手段，缺点是需双倍推理成本且无法立即验证业务影响。效果验证上，三种策略都需在同一时间窗口内对比新旧版本的模型指标（如 AUC、业务指标）与资源指标（延迟、吞吐、错误率），并设置明确验收阈值与回滚条件；金丝雀用统计显著性检验确认新版本确实更优再放量。

三种策略要讲清"流量如何进、如何验证、如何回滚"，并强调"影子流量零风险但贵、金丝雀风险可控、蓝绿切换快但贵"。

• 流量分配与样本一致性
• 效果评估窗口与样本量
• 自动回滚触发条件

流量分配上，A/B 测试需保证实验组/对照组样本一致性（如按用户 ID 哈希分层，同一用户始终进入同一组），并通过随机化避免偏差；金丝雀发布则按比例分配业务流量（如 1%→5%→20%）。效果评估窗口要足够覆盖业务周期（如一周以覆盖星期效应）并满足统计显著性要求（根据效应量、方差、显著性水平计算样本量），同时对比新旧版本的模型指标与业务指标（转化率、点击率、延迟）。自动回滚条件应"可量化、可判断"：例如新版本业务指标显著低于旧版本（p 值显著且降幅超过阈值）、错误率/延迟超过 SLO、P99 超限、或连续 N 个窗口异常即触发自动回滚到上一稳定版本；同时设置最大放量时限与熔断，避免长期停留在失败状态。回滚后需保留数据用于复盘。

偏向"实验设计 + 回滚机制"，要点是"随机/分层分配 + 统计显著的评估窗口 + 量化可自动判定的回滚条件"。

• 实验框架与流量分层
• 业务指标与模型指标的统一采集
• 统计显著性检验与决策

A/B 测试框架的工程链路包括：一是流量分配与分层，用实验平台（如自研或开源的实验框架）按用户/实体维度做哈希分层，保证互斥与一致性，并支持正交实验；二是埋点与指标收集，把"业务指标"（转化率、留存、收入、点击率）与"模型指标"（AUC、预估分数分布、首口延迟、覆盖率）统一采集到数据仓库/OLAP，按实验组对齐；三是统计显著性检验，用 t 检验/卡方检验/序贯检验比较新旧版本关键指标，计算 p 值与置信区间，考虑多重比较与辛普森悖论，用 bootstrap 或方差分析提升稳健性；四是决策与发布，满足显著性且方向正确才放量，否则维持或回滚。框架还需支持实验配置、样本量预估、监控与审计，确保实验可复现、结论可信。

回答要覆盖"分配→采集→检验→决策"完整链路，并强调业务指标与模型指标都要纳入、统计显著性检验要严谨。

• 推理性能指标（TTFT、TPOT、吞吐）
• continuous batching 原理
• 延迟与吞吐的权衡

关键推理性能指标包括：首 token 延迟（TTFT，从请求到达到输出第一个 token 的耗时）、单 token 生成本（TPOT/ITL）、端到端延迟、吞吐（tokens/s，单位时间生成的 token 数）与并发/批大小。生成类模型（LLM）的 decode 阶段是瓶颈，逐 token 生成导致吞吐受限。continuous batching（连续批处理）通过在 decode 过程中动态把新请求加入/把完成请求移出当前批次，显著提升 GPU 利用与吞吐，相比静态 batching 能更好地处理长尾请求。权衡上，TTFT 对在线交互体验敏感（首屏延迟），吞吐对大规模推理的成本敏感；增大批大小提升吞吐但可能抬高单体请求延迟与 TTFT，需在服务级别目标（SLO，如 P99 TTFT）约束下优化吞吐。工程上通过 continuous batching、KV cache 复用、投机解码、PD 分离（prefill/decode 分离）等优化，在满足延迟 SLO 的前提下最大化吞吐。

性能权衡题要讲清各指标定义与相互制约，并落到"continuous batching 提升吞吐、在延迟 SLO 约束下权衡"。

• 冷启动耗时的来源（权重加载、CUDA 初始化、量化）
• 预热手段（权重缓存、CUDA graph、显存预留）
• 对弹性扩缩容的影响

模型冷启动慢主要来自权重加载（从存储读入大文件）、CUDA 初始化与 kernel 编译、KV cache 与显存分配、以及量化。优化手段：一是权重加载，用共享内存/镜像缓存、预加载、并行加载与模型分片降低 IO 耗时；二是 CUDA graph，把推理的 kernel 序列提前捕获成图，减少 launch 开销（对固定 shape 的 decode 效果明显）；三是显存预留，通过预分配显存池、预留 KV cache 缓冲避免运行时分配抖动；四是预热，在就绪探针通过前先跑若干次推理（dummy request）完成 kernel 编译与显存分配，配合"就绪门"（warmup 完成才对外服务）。这些优化使弹性扩缩容更快：新副本能快速达到可服务状态，支持应对流量突增的快速扩容，同时配合"初始副本数 + 冷启动提示 + 预热"策略，避免扩缩容抖动导致服务降级。

题目聚焦"冷启动/预热"，回答要拆解耗时的来源并给出对应优化，最后落到"预热使扩缩容更快、更稳"的价值。

• 分布漂移与效果衰减监控
• feedback loop（反馈回路）带来的偏差
• 与业务指标联动与告警

模型线上效果监控需覆盖三方面：一是输入分布漂移（特征/文本/图像分布 vs 训练基线），用 PSI/KS 监测；二是模型输出分布与效果衰减（预估分数分布、AUC 回测、校准度、预测与真实行为的偏差），特别关注 feedback loop——模型上线后影响用户行为，真实标签又回流训练，可能形成"自我强化偏差"（如推荐的 popularity bias），导致效果衰减但指标失真；三是业务指标联动（点击率、转化率、收入、留存），把模型信号与业务结果关联，避免"模型指标好但业务没变化"。告警上应建立多维度告警：分布漂移超阈值、效果指标显著下降、业务指标异常波动、以及"漂移+衰减+业务联动"的组合告警，设置分级与自动处置（如回滚、降级、触发重训）。告警需关联血缘与版本，定位受影响模型与调用方。

本题强调"监控不只是看指标，还要理解 feedback loop 的偏差"，并落到"分布/效果/业务三级联动告警"。

• 三种形态的延迟、成本、更新特征
• 场景适配（实时 OCR、离线批算、端侧）
• 选型权衡

在线服务（实时推理）追求低延迟、高可用，常部署在 GPU 集群或云函数，模型更新快（可灰度发布）、但持续占用资源、成本高，适合交互式场景（搜索、推荐、对话、实时风控）。批处理推理对延迟不敏感，用 Spark/调度任务在离线集群批量跑，成本低、可扩容、模型更新按批次进行，适合大规模离线打分、报表、回溯预测。边缘部署把模型部署到端侧/边缘设备（手机、IoT、边缘网关），延迟最低（本地推理）、隐私好、不依赖网络，但算力受限、需模型量化/裁剪、更新困难（需 OTA 分发），适合对延迟和隐私敏感的场景。选型时综合延迟要求、数据量、成本预算、更新频率与隐私合规：实时交互选在线，海量离线算选批处理，端侧/弱网选边缘；也可混合（如在线 + 边缘兜底、批处理 + 在线联动）。

选型题按"延迟、成本、更新"三个维度对比，再给场景映射，体现权衡思维。

• 上线前离线验证
• 灰度期在线验证与指标对比
• 自动回滚条件

模型上线验证分"离线"与"在线"两阶段。离线阶段先做回测：用历史数据对比新旧版本的核心模型指标（AUC、F1、校准误差、样例抽查），确认新版本不劣于旧版本并满足预设阈值。在线阶段通过灰度发布小流量观察：在线对比新旧版本在同一时间窗口的模型指标与业务指标（转化率、延迟、错误率），计算差异是否符合预期与统计显著性。灰度期观察应设置足够的观察时长与样本量，并监控资源与稳定性。自动回滚条件的核心是"可量化、可判定"：例如新版本业务指标显著劣于旧版本（p 值显著且降幅超阈值）、错误率/延迟超 SLO、P99 超限、或连续 N 个观测窗口异常，触发自动回滚到上一稳定版本；同时设置最大观察时限与熔断兜底。回滚后保留数据复盘并重新评估。

验证题要体现"离线+在线"双阶段与"量化回滚条件"，强调结论由数据而非主观判断驱动。

• 三种策略风险等级
• 场景适配（高可用、渐进、零风险验证）
• 资源与成本权衡

蓝绿部署适合"风险高、需快速切换与快速回滚"的场景，因为新版本全量切、切回也快，但需要双倍资源，适合 rebuild 后有完整回滚能力、愿意为可用性付双倍成本的关键服务。金丝雀适合"风险中等、需渐进验证"的场景，小流量逐步放量、实时对比，回滚粒度细、资源占用可控，是最常用且平衡的生产发布策略，适合大多数业务模型。影子流量适合"验证需求高、但零风险优先"的场景，新版本只接收影子流量、结果不外发，能真实验证新版本性能与质量而不影响用户，适合高风险首次上线前的验证，但需双倍推理成本、无法立即评估业务影响。总体按风险等级：高风险/需快速回滚用蓝绿，中风险渐进用金丝雀，需零风险验证用影子流量（常作为金丝雀/蓝绿的前置验证）。

题目要求"风险等级映射"，回答要给出"风险↔策略"的对应关系，并补充资源成本说明。

• 三种拓扑的资源与性能特征
• 延迟、隔离、更新与成本权衡
• 选型考量

同进程部署：模型推理与业务逻辑跑在同一进程，省去网络往返、延迟最低、部署简单，但模型会占用 CPU/内存/显存，与业务争抢资源，且模型更新需重启整个业务进程、故障相互影响，适合轻量模型与低并发场景。独立服务：推理作为独立微服务（如 Triton/KServe 部署），业务通过 RPC/HTTP 调用，资源隔离、可独立扩缩容与更新、支持 GPU 与批处理，是最主流的生产拓扑，代价是增加一次网络调用与序列化开销。边缘部署：把推理放到端侧/边缘节点，本地推理、延迟最低、隐私好、不依赖网络，但算力受限、需量化、更新难，适合弱网/离线/隐私敏感场景。选型上综合模型复杂度、延迟要求、并发、GPU 需求、更新频率与运维成本：追求极致性能且模型轻选同进程，追求可扩展与 GPU 利用选独立服务，端侧弱网选边缘；常用"独立服务为主，边缘/同进程兜底"的组合。

拓扑选型题要对比"延迟、隔离、更新、资源"四个维度，并给出场景化选型建议。

• 就绪探针与存活探针
• 在途请求排空机制
• 显存释放与优雅退出

模型服务健康检查：存活探针（liveness）检查进程是否存活、是否死锁；就绪探针（readiness）检查模型是否已加载、可服务请求，就绪失败时从负载均衡摘除流量，避免把请求路由到未就绪副本。优雅停机：进程收到 SIGTERM 后，先停止接收新流量（从 Service 摘除/IP 摘除，或 readiness 置为 false），再进入"排空窗口"等待在途请求完成（设置超时，超出则强制终止），最后释放 GPU 显存（删除缓存、上下文、KV cache）并退出。实现上，服务常提供 /healthz（存活）与 /readyz（就绪）端点；停机时用 preStop hook 做摘流与排空，配合 Kubernetes 的 terminationGracePeriod 与生命周期钩子；显存释放需在退出前显式清理 CUDA 上下文，避免残留进程占用显存导致后续调度失败。优雅停机与就绪探针结合，可实现在发布/滚动更新/缩容时无中断、无资源泄漏。

本题聚焦"探针 + 排空 + 显存释放"三个实现细节，回答要给出具体机制（端点、preStop、terminationGracePeriod）。

• 显存估算（权重 + KV cache + 激活）
• CPU/内存配比
• 并发上限与吞吐估算

显存估算：模型显存 ≈ 权重大小（参数量 × 字节数，如 FP16 约 2 字节/参）+ 推理工作区（KV cache、激活、中间张量）+ 框架开销。KV cache 大小 ≈ 序列长度 × 层数 × 头数 × 头维度 × 每个 token 字节数 × 并发数，因此并发越高显存越大，需按目标并发预留。CPU/内存配比：虽然推理主要在 GPU，但预处理、tokenizer、调度与批处理仍需 CPU 与内存，一般按"GPU 显存为上界、CPU 内存为其 2~4 倍、CPU 核数按并发与批处理"配置。并发上限估算：并发上限由显存（KV cache 上限）与算力（batch 内吞吐）共同决定，通常先按显存可容纳的最大 batch 数，再结合延迟 SLO 与 continuous batching 适配，用压测（load test）验证不同并发下的 P99 延迟与吞吐，确定能同时满足 SLO 的最大并发，并据此设置副本数与弹性扩缩容阈值。资源规划应基于实测压测数据而非纯理论估算。

资源规划题要给出"显存=权重+KV cache+工作区"的估算框架，并强调以压测校准并发上限与副本数。

• 回滚触发条件（指标劣化、稳定性违约、资源异常）
• 秒级回滚的实现机制（多版本在线、切换式发布）
• 秒级回滚的边界（数据副作用、下游生态、根因复盘）

回滚触发条件必须"可量化、可自动判定"，主要包括四类：一是业务/模型指标劣化，新版本的关键指标显著劣于旧版本（如转化率、AUC 下降超阈值且统计显著）；二是稳定性指标违约，错误率、P99 延迟、超时率超过 SLO，或连续 N 个观测窗口异常；三是资源异常，如显存泄漏、OOM、GPU 利用率异常；四是上线流程类问题，如灰度期发现特征缺失、数据异常或与上游兼容性问题。条件应以"阈值 + 滑动窗口 + 统计显著性"组合判定，避免单点抖动误触发，同时保留人工熔断入口用于紧急情况。

秒级回滚的工程实现依赖"多版本同时在线的切换式发布"：蓝绿部署中旧版本环境始终在线，通过负载均衡/网关一次性把流量切回旧版本，秒级完成；金丝雀发布中保留旧版本副本，把新版本流量比例归零即可；更细粒度的是网关层按权重/Header 做版本路由，回滚仅需改路由配置即秒级生效。其工程前提是"版本不可变 + 旧版本资源常驻或可快速拉起"，因此生产上需为关键模型预留旧版本热备副本或快速拉起通道。 但秒级回滚存在明确边界：一是"代码/配置可秒回，数据不可秒回"，若新版本已写入线上数据（模型打分入库、下游调用副作用、特征回写），回滚模型无法自动撤销已产生的数据影响，需配套幂等设计与数据补偿；二是"推理回滚易、生态回滚难"，模型被多个下游消费时需联动调用方与缓存；三是回滚是止损而非终结，需记录回滚前后指标、复盘根因（数据漂移、特征错误、代码缺陷）后决定修复路径；四是回滚窗口内可能涌入新请求，需配合限流与告警。因此工程上把"秒级回滚"定位为快速止损手段，配合"数据幂等 + 下游联动 + 根因复盘 + 流程演练（game day）"才构成完整闭环。

题目关键词是"触发条件"与"工程边界"。回答要先给出可量化、可自动判定的触发条件，再讲清秒级回滚的本质是"切换式发布"（旧版本在线、流量可瞬时切回），最后点明边界——秒级回滚只覆盖服务与流量，数据副作用与下游生态无法秒级回滚，体现对生产事故处置的务实认知。

• 版本不可变性（immutable）与回滚前提
• 回滚到历史版本的操作流程（选版本、拉产物、切换、验证）
• 回滚后的监控、审计与根因复盘

模型仓库（MLflow Model Registry 或自建）的版本不可变性是回滚机制的地基：每个已注册版本一经发布即不可覆盖、不可删除（或仅可归档），模型产物（权重、tokenizer、预处理配置、依赖清单）与元数据（训练数据版本、特征版本、超参、commit、评估指标）一次性固化并与版本号绑定。由于版本不可变，任何时间点都能精确重建"当时那个模型"，回滚本质是切换到仍可用的历史不可变版本，从而保证可复现、可回滚与可审计。

回滚到历史版本的操作流程一般分六步：一是确认回滚目标，根据生产版本的元数据与发布记录，确定要回滚到的上一个稳定版本（stage 为 Production 或 Archived 的历史版本）；二是从模型仓库拉取该版本的产物与依赖清单（含 Python 环境、框架版本），确保与当前推理服务兼容；三是按发布策略执行切换（蓝绿切流、金丝雀比例归零或网关路由切换），并同步回滚配套配置（特征版本、预处理参数、Prompt 模板）；四是回滚后立即做健康与效果验证，对比回滚前后指标（错误率、延迟、业务指标）确认恢复到预期水平；五是持续监控观察并记录审计日志（谁、何时、从哪个版本回滚到哪个版本、关联工单）；六是复盘根因并决定后续修复路径（修数据、修特征还是修模型）。整个流程应预先演练并固化为 Runbook，确保真实事故时可按步骤快速执行。

回答要抓住"不可变性是可靠回滚的前提"这一核心：没有不可变版本就没有可靠的回滚目标。操作流程则体现"选版本→拉产物→切换→验证→审计→复盘"的完整闭环，并强调回滚不是终点而是止损，根因修复与流程演练同样重要。

• 量化精度损失的来源（舍入误差、动态范围截断、异常值）
• 离线评测方法（校准集、任务指标、输出级数值对比、性能实测）
• 线上监控与验证（灰度对比、输出分布漂移、重校准）

部署前的离线评测应围绕"精度、性能、鲁棒性"三个维度展开。精度评测：用与训练分布一致且有代表性的校准集/评测集，对比量化前后模型在任务指标（准确率、AUC、F1、BLEU/困惑度等）上的差异，设置可接受的下降阈值（如 ≤1%）；同时做输出级数值对比（logits、输出分布 PSI/KS、embedding 距离），识别量化引入的系统性偏差，重点检查动态范围大、存在异常值（outlier）的层是否被截断或溢出。性能评测：在目标硬件上实测量化前后的延迟（TTFT/TPOT/P99）、吞吐（tokens/s）、显存占用与功耗，确认收益与成本。鲁棒性评测：覆盖长尾输入、长序列、极端数值场景，验证量化模型在分布外样本上的稳定性，并做多硬件架构（不同 GPU 的 INT8/FP8 支持度）兼容性测试。

线上监控与验证应"先灰度、后全量、持续盯"：量化版本先走小流量灰度，在线对比量化版与原始精度版（或旧版本）的输出分布与业务指标（如回复采纳率、点击率、生成质量评分），统计显著达标后再放量；持续监控量化模型的特有风险：输出分布漂移、异常 token/乱码比例、长尾输入下的退化、数值溢出告警，以及线上分布与校准集的偏差扩大（一旦明显偏离说明校准集已失效，需要重校准或重量化）。配套措施包括：量化模型与原始模型 A/B 可切换、量化参数与校准集版本化（记录用哪份数据、哪种算法校准），以及监控告警触发的自动回滚或降级到未量化版本。

题目分"离线评测"与"线上监控"两个阶段。回答要点是量化不是无代价压缩：离线要评测精度/性能/鲁棒性并设置阈值，线上要灰度对比输出分布与业务指标并监控量化特有退化风险，同时把校准集与量化配置版本化，保证可复现与可回退。