想象你是一位天赋异禀的奶茶师傅。以前你只在自家厨房研发新配方，调好一杯，自己品尝，自己满意就好——这是“离线训练”。突然有一天，你决定在商业街开一家对外营业的奶茶店，顾客排队点单，要求 30 秒出杯、口味稳定、不管周末还是下雨天都不能歇业——这就是“推理服务化”。 从“自己喝”到“卖给别人喝”，中间隔着的不只是招牌和吧台，而是一套完整的运营体系：厨房里的灶台火力怎么分配（GPU 资源调度）、珍珠和茶汤怎么提前备好（模型加载策略）、多个联名品牌共用一个中央厨房如何互不串味（多租户隔离）、新配方怎么先请少量顾客试喝再全量推出（灰度发布）、某家分店停水停电时如何让顾客依然有奶茶喝（高可用保障），以及房租电费人力如何精打细算（成本优化）。这篇文章，就带你从零开始，把这些环节一个个讲透。

岗位关联

推理服务化是 AI 从实验室走向商业化的“最后一公里”。理解它，你才能把模型变成稳定、高效、省钱的线上产品，是 AI 从业者从工程师走向全栈商业思维的关键一跃。

目录
  1. 可视化演示
  2. 服务化概念
  3. GPU资源调度
  4. 模型加载策略
  5. 多租户隔离
  6. 灰度发布
  7. 高可用保障
  8. 成本优化
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

推理服务架构 API网关路由请求 负载均衡分发到GPU实例 训练↔推理分离部署 弹性扩缩容的在线推理服务

服务化概念

以前你只是在自家厨房里试配方，调一杯自己尝一口，觉得好喝就满意了。可一旦决定开店，事情就完全不同——顾客不会管你今天心情如何，他们要的是无论何时推门进店，都能在几十秒内拿到一杯口味标准的奶茶。这正是离线训练与在线推理的本质差别。

离线训练的世界里，数据可以慢慢喂、任务跑挂了重来也无妨；在线推理却是一条必须持续营业的生产线，请求随时进来、随到随答。推理服务化的第一步，就是把“研发厨房”和“营业门店”彻底分开：模型在训练集群里锤炼，然后打包部署到独立的 GPU 服务集群，对外暴露统一的 HTTP 或 gRPC 接口。这个“独立 + 标准化 + 弹性”的组合，就是我们常说的推理服务化。

要把它运营好，先得盯住四个指标：QPS 代表每秒能出几杯，P95 延迟说明最慢那杯要等多久，错误率反映品质稳定性，GPU 利用率则直接关联成本。接口标准化同样关键——模型在训练时是 Python 函数，上线后要变成任何语言都能调用的 API。配合容器编排与负载均衡，服务就能在流量上涨时自动加实例、流量回落时自动减实例。

所以推理服务化的目标，就是像经营一家永不歇业的奶茶店那样，让模型随时可调用、指标可度量、资源可伸缩。门店开起来了，接下来就看厨房里的灶台怎么调度了。

QPSmax⁡=1平均单请求处理时间\displaystyle \text{QPS}_{\max} = \frac{1}{\text{平均单请求处理时间}}
通俗说明：如果一个请求平均 20 毫秒处理完，那这个实例每秒最多能接约 50 个请求；真实场景还要叠加批处理与排队的影响。
  1. 分子"1“代表一秒吞吐量的本质是”一秒内能完成多少次处理"
    时间窗口=1 秒\text{时间窗口} = 1\ \text{秒}
  2. 分母单请求平均耗时指请求从进入服务到返回结果的完整用时
    tavg=窗口内总耗时窗口内请求数t_{\text{avg}} = \frac{\text{窗口内总耗时}}{\text{窗口内请求数}}
  3. 整体含义一秒能容纳几个“平均耗时”，就有几个请求的最大处理能力
    QPSmax⁡=1tavg\text{QPS}_{\max} = \frac{1}{t_{\text{avg}}}

GPU资源调度

厨房里灶台和厨具是有限的。一张 GPU 卡好比一个灶台面——显存决定能同时摆几口锅，算力决定火有多大。订单一多，谁先做、谁后做、能不能几单一起做，全靠调度。

在推理集群里，GPU 是最稀缺的核心资源。调度器首先要做“显存配额管理”：一张 32G 的卡，模型占 12G，剩下 20G 还能不能塞别的小模型？要给每个任务设定显存上限，防止某个模型把整卡占满、压垮邻居。

然后是“动态批处理”——把多个请求攒成一锅一起算。GPU 擅长并行计算，单请求单独算很浪费；将 8 个请求拼成 batch，总耗时可能只比单个请求多一点点，单个请求的平均成本大幅下降。此外还有优先级抢占（VIP 请求插队）和多卡并行（超大模型拆到多张卡联合计算）。

灶台调度得好，后厨就快。但不管是几口锅，顾客进门时如果珍珠还没煮好，依然要干等。接下来就是出杯前的最后准备——模型加载策略。

QPSbatch=BtB\displaystyle \text{QPS}_{\text{batch}} = \frac{B}{t_{B}}
通俗说明：把 B 个请求凑成一个 batch 一起推理，总耗时 t_B 远小于 B 个请求分别推理的时间之和。
  1. 分子 B 是批大小一次打包进模型的请求个数
    B=batch 内请求数B = \text{batch 内请求数}
  2. 分母 t_B 是单批总耗时在 GPU 上并行计算一个 batch 的端到端时间
    tB=排队+前向计算+返回t_{B} = \text{排队} + \text{前向计算} + \text{返回}
  3. 整体含义批吞吐等于“一批处理多少个”除以“一批花多少时间”
    QPSbatch=BtB\text{QPS}_{\text{batch}} = \frac{B}{t_{B}}

模型加载策略

一家合格的奶茶店，绝不会等顾客点单后才开始煮珍珠。提前把珍珠煮好、茶汤泡好、杯子和封口机就位，顾客一声“珍珠奶茶，去冰”，三十秒出杯。推理服务也一样，模型需要先“备好料”才能接客。

这个备料过程就是冷启动预热。模型文件从磁盘加载到显存要时间，加载完还要初始化 CUDA 上下文、创建推理引擎、跑一两个 dummy 请求做 warmup。没有预热的实例，前几个请求会慢得离谱，甚至直接超时报错。

业界常用这些手段把预热时间压下来：模型缓存复用——多个副本共享同一份已加载权重；共享内存加载——用 mmap 或 safetensors 让多个进程映射同一物理内存页；生命周期管理——空闲实例自动回收，需要时再快速拉起。这样既省显存，又缩短准备时间。

料备好了，店才能开。但如果是几家品牌共用一个中央厨房，还得把各家的珍珠、茶汤分门别类放好，谁也不许偷尝谁家的配方，账也要分开算。下一节就是多租户隔离。

Twarm=Tload+Tinit+Tprobe\displaystyle T_{\text{warm}} = T_{\text{load}} + T_{\text{init}} + T_{\text{probe}}
通俗说明：一次完整的模型实例就绪时间 = 权重加载 + 引擎初始化 + 探针预热三段之和。
  1. T_load 权重加载把权重文件从磁盘读入显存的时间
    Tload=模型文件大小磁盘读取速率T_{\text{load}} = \frac{\text{模型文件大小}}{\text{磁盘读取速率}}
  2. T_init 引擎初始化创建 CUDA 上下文和执行引擎
    Tinit=算子编译+显存分配T_{\text{init}} = \text{算子编译} + \text{显存分配}
  3. T_probe 探针预热跑一个最小请求让所有算子真正触发
    Tprobe=首次前向推理耗时T_{\text{probe}} = \text{首次前向推理耗时}

多租户隔离

几家奶茶品牌深度联营，共用一个中央厨房：灶台共用、冷柜分格、账本分开。A 品牌爆单时可以把 B 品牌的锅抢走吗？当然不行。每个品牌的原料、配方、现金流都要严格隔开，这就是多租户隔离的日常图景。

推理平台通常同时服务多个客户（多租户）。首先要做资源配额隔离：每个租户有显存和算力上限，既保证基本盘，又防止某个租户的突发流量把整卡打爆。其次要做性能噪声隔离：通过排队、限流、独立线程池，让 A 租户的洪峰不会拉长 B 租户的 P95 延迟。

安全数据隔离同样重要——模型参数、推理输入输出都要按租户做权限隔离，避免数据越权访问。最后是计量计费：按 token 数、请求数或 GPU 时长记录用量，让每个租户为自己的消耗买单。这四板斧合起来，才是一个商业上可持续的多租户平台。

厨房里各家的料都分好了，接下来要考虑：研发出一款新配方，总不能让全部门店一夜之间全换吧？门店的招牌、收银系统、员工培训全部要跟着换，风险太大了。先找几个熟客试试——这就是灰度发布。

Rt=Rtotal×wt∑iwi\displaystyle R_{t} = \frac{R_{\text{total}} \times w_{t}}{\sum_{i} w_{i}}
通俗说明：租户 t 的预期吞吐 = 总吞吐 × 该租户权重 / 所有租户权重之和。
  1. 分子总吞吐 × 租户权重先按权重把总资源切给租户
    Rtotal×wtR_{\text{total}} \times w_{t}
  2. 分母权重归一化把所有权重加总，保证比例正确
    ∑iwi=w1+w2+⋯+wn\sum_{i} w_{i} = w_{1} + w_{2} + \dots + w_{n}
  3. 整体含义租户分到的份额由权重占比决定，配额公平可预期
    Rt=Rtotal×wt∑iwiR_{t} = \frac{R_{\text{total}} \times w_{t}}{\sum_{i} w_{i}}

灰度发布

新饮品配方在没有验证之前，聪明的店主绝不会把全部门店的招牌都换掉。他会先请最熟的老顾客试喝，观察口味、肠胃反应，确认没问题再推广到更多门店。模型上线也一样，尤其是一个推荐系统或风控模型，一旦“翻车”影响的是全量用户。

灰度发布的第一步是金丝雀发布：先部署一个新版本实例，把 5%（或更小）的流量引过去，观察它的错误率和延迟是否正常。流量的切分方式可以是随机权重，也可以按用户 ID 哈希，还可以按设备、城市等特征路由——这就是流量分流策略。

灰度期间要实时对比新旧版本的核心指标：QPS、P95 延迟、业务指标（如点击率、转化率）。一旦新版本指标异常（错误率超过阈值、延迟飙升），自动回滚机制立即把流量切回旧版本。而新旧版本共存期，还需要保证二者能共享受限的 GPU 资源，这就是版本兼容共存。

新配方验证通过，终于可以在全城门店推广了。但连锁经营最怕的就是单点故障——万一总店停电了呢？我们需要一套应急预案，让每一家分店都能随时顶上。

wnew=TnewTtotal\displaystyle w_{\text{new}} = \frac{T_{\text{new}}}{T_{\text{total}}}
通俗说明：新版本分到的流量权重等于新版本流量占总流量的比例。
  1. 分子新版本流量灰度阶段切给新实例的请求数
    Tnew=当前灰度流量T_{\text{new}} = \text{当前灰度流量}
  2. 分母总流量新旧版本流量之和
    Ttotal=Told+TnewT_{\text{total}} = T_{\text{old}} + T_{\text{new}}
  3. 整体含义权重从 0.05 逐步升到 1，就是完整的灰度放量过程
    wnew=TnewTtotalw_{\text{new}} = \frac{T_{\text{new}}}{T_{\text{total}}}

高可用保障

真正成熟的连锁品牌，从不会把身家性命押在一家店铺上。即使是总店，也会预留至少一家位置相近的分店作为后备。某家店停水停电，只要把客流引导到分店，顾客依然能在十分钟内拿到奶茶。

推理服务的高可用保障秉承同一思路。首先是多副本冗余：同一模型的实例至少部署两个，分布在不同的物理机甚至可用区。其次是健康检查：网关定期向实例发送探活请求，就像店长每天检查设备，发现响应变慢或失败，立刻把该实例从负载均衡中摘除。

当故障实例被摘除后，故障自动转移机制会把流量导向健康实例，用户几乎无感知。弹性伸缩则是另一层兜底：根据 CPU、GPU 利用率或请求队列深度自动增加实例，扛住突发流量。这些机制共同撑起一个目标——服务可用性足够高。

可靠的门店网络保证了“随时有奶茶喝”，但房东的账单不会撒谎。每多开一家店、多亮一盏灯都是成本。于是精明的老板开始思考：怎么用最少的店租，做出最多的营业额？

A=MTBFMTBF+MTTR\displaystyle A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}
通俗说明：可用性 = 平均无故障时间 / （平均无故障时间 + 平均恢复时间）；MTTR 越小，可用性越高。
  1. 分子 MTBF（平均无故障时间）系统两次故障之间的平均正常工作时长
    MTBF=累计运行时间故障次数+1\text{MTBF} = \frac{\text{累计运行时间}}{\text{故障次数} + 1}
  2. 分母 MTBF + MTTR代表一个完整的“故障-恢复”周期
    MTTR=从故障到恢复的平均时长\text{MTTR} = \text{从故障到恢复的平均时长}
  3. 整体含义恢复得越快，故障周期越短，可用性越接近 1
    A=MTBFMTBF+MTTRA = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}

成本优化

奶茶店的房租是固定的，哪怕只卖出一杯，也要付全天租金。要降低每杯奶茶的成本，要么在同样租金下卖出更多杯，要么在顾客稀疏的时段把门店关掉一部分。推理服务的成本博弈，本质就是如何把 GPU 这块昂贵“店面”用到极致。

第一种手段是碎片化打包：一张 80G 的大卡，部署一个大模型后可能还剩 20G 显存碎片，把这些碎片塞进几个小模型，等于给“废弃角落”也招了租。第二种是混部部署：在线推理任务和离线训练任务交替使用 GPU——白天推理忙、晚上训练忙，让算力 24 小时都有活干。

第三种是弹性扩缩容策略：根据 QPS 曲线和队列深度自动调整实例数，高峰期加足马力，深夜果断缩容。最后是成本效益分析：自建机房与云上按量购买各有利弊，是长期租固定实例划算，还是突发流量买按量实例划算，需要把单位成本算清楚。

从开店选址到后厨调度，从备料到隔离，从灰度到高可用，再到最后的精打细算，推理服务化就是一场完整的商业运营。它不只是一个调 API 的工程问题，而是让模型学会“自己养活自己”的商业艺术。

Cper req=Chourly×NinstQPS×3600\displaystyle C_{\text{per req}} = \frac{C_{\text{hourly}} \times N_{\text{inst}}}{\text{QPS} \times 3600}
通俗说明：单个请求的分摊成本 = 每小时单实例成本 × 实例数 ÷ （每秒请求数 × 3600 秒）。
  1. 分子每小时成本 × 实例数一个小时所有实例的总花费
    Chourly×NinstC_{\text{hourly}} \times N_{\text{inst}}
  2. 分母总请求数一个小时内服务完成的请求总量
    QPS×3600 s\text{QPS} \times 3600\ \text{s}
  3. 整体含义利用率越高、实例越精准，每笔请求的成本就越低
    Cper req=Chourly×NinstQPS×3600C_{\text{per req}} = \frac{C_{\text{hourly}} \times N_{\text{inst}}}{\text{QPS} \times 3600}

AI 应用场景

大模型 API 平台的自动扩缩容

阶段：模型部署与在线服务

解决的问题：传统方式按峰值流量固定购买 GPU 实例，夜间利用率仅 10%-20%，成本白白烧掉。

具体案例：某 MaaS 平台部署 Llama-70B，接入请求网关后根据 QPS 与队列深度自动扩缩容：白天高峰自动扩到 20 个实例，凌晨压缩到 3 个实例；同时开启动态批处理，单卡吞吐提升 2.3 倍，月度 GPU 成本下降 47%。

多租户大模型推理网关

阶段：多租户服务治理

解决的问题：多个企业客户共用一套模型服务，互相抢算力导致体验不稳，账也算不清。

具体案例：某 AI 公司为 5 家客户提供统一 API，按租户设置显存配额与 QPS 限流，并按 token 计量计费。大客户配额 60% 保障 P95 延迟稳定，小客户按量付费、突发时排队等待，平台整体稳定性显著提升，客户续费率提高 30%。

推荐模型灰度发布

阶段：模型上线与迭代

解决的问题：推荐模型直接全量上线，一旦指标暴跌，损失的是全站 GMV。

具体案例：某电商推荐团队用用户 ID 哈希切 5% 流量到新模型，实时对比点击率与转化率；48 小时后指标正向，逐步放量到 50% → 100%；若异常则自动回滚，全程无需人工干预。

Python 演示

python51 行
"""Simplified autoscaling simulator for inference service."""import math  class InferenceService:    def __init__(self, capacity_per_instance=10, max_instances=5):        self.capacity_per_instance = capacity_per_instance        self.max_instances = max_instances        self.instances = 1        self.queue = []        self.served = 0        self.dropped = 0     def update_instances(self, demand_qps):        # target instances to cover current demand        target = max(1, min(self.max_instances,                            int(math.ceil(demand_qps / self.capacity_per_instance))))        # scale up immediately, scale down conservatively        if target > self.instances:            self.instances = target        elif target < self.instances:            if demand_qps < self.capacity_per_instance * self.instances * 0.6:                self.instances = target     def step(self, incoming):        self.queue.extend(incoming)        capacity = self.instances * self.capacity_per_instance        processed = min(capacity, len(self.queue))        self.served += processed        self.queue = self.queue[processed:]        if len(self.queue) > 100:            self.dropped += len(self.queue) - 100            self.queue = self.queue[:100]  def simulate(seconds=60):    svc = InferenceService()    for t in range(seconds):        demand = 20 + 15 * math.sin(t / 5)        incoming = max(0, int(demand + (t % 3)))        svc.update_instances(demand)        svc.step([f"req-{t}-{i}" for i in range(incoming)])    return svc  if __name__ == "__main__":    svc = simulate()    print("instances:", svc.instances)    print("served:", svc.served)    print("dropped:", svc.dropped)    print("queue:", len(svc.queue))
目的：模拟一个随 QPS 波动自动扩缩容的推理服务，观察实例数变化与请求丢失情况。
  1. target = max(1, min(self.max_instances, int(math.ceil(demand_qps / self.capacity_per_instance))))根据当前需求算目标实例数，至少 1 个、至多 5 个
  2. if target > self.instances:需求上涨时立即扩容，宁可多开一个台也不能让顾客排队
  3. if demand_qps < self.capacity_per_instance * self.instances * 0.6:需求跌到当前容量的 60% 以下才缩容，避免实例数频繁抖动
  4. self.queue.extend(incoming)新请求先进入等待队列
  5. capacity = self.instances * self.capacity_per_instance当前总处理能力是实例数 × 单实例容量
  6. processed = min(capacity, len(self.queue))一次性处理所有能处理的请求
  7. self.dropped += len(self.queue) - 100队列超过 100 时丢弃新请求，保护服务不被打垮
  8. demand = 20 + 15 * math.sin(t / 5)用正弦波模拟白天高峰、夜间低谷的请求节奏

常见误区

误区训练完模型，把权重文件传到一台 GPU 服务器，用 Flask 包一层接口，就算完成推理服务化了。

正解真实线上推理要面对流量抖动、资源竞争、冷启动、故障恢复等复杂问题。服务化是一整套工程体系：资源调度、模型预热、多租户隔离、灰度发布、高可用和成本治理缺一不可。就像开奶茶店不等于摆个奶茶机，还要管供应链、排班和突发客流。

为何常见：本地 Demo 和真实线上系统的差距被严重低估，很多人误以为“能跑通”就等于“能上线”。

误区只要 GPU 显存够大，模型推理性能就一定好。

正解显存只决定“模型能不能装下”，真正的吞吐瓶颈常常是计算单元、内存带宽和批处理策略。显存够但算力吃满，加显存毫无收益；同样显存下，合理 batch 可以让吞吐翻倍。

为何常见：部署时最容易感知到的硬件参数就是显存大小，让人误以为大显存等同高性能。

误区线上 QPS 不够，就一直加副本实例，加到满意为止。

正解实例数量超过需求后边际收益递减，还会带来通信开销、显存浪费和账单压力。理想做法是按需求曲线动态扩缩容，让实例数与负载匹配，而不是盲目堆机器。

为何常见：水平扩展是解决性能问题的首选直觉，但忽略了成本与边际效应。

误区只要租户之间容器或虚拟机级别隔开，就完成了多租户隔离。

正解虚拟机隔离解决的是安全边界，但推理平台的核心矛盾是性能噪声：一个租户的突发流量可能挤占共享 GPU 算力。所以还要做资源配额、排队限流和指标隔离，否则即使虚拟机分开了，邻居照样能让你变慢。

为何常见：“隔离”这个词容易让人联想到虚拟化，而忽略了算力共享带来的性能干扰。

误区在网关面板上把新版本流量权重改到 5%，就算完成灰度发布。

正解百分比只是第一步。真正的灰度包含：监控新旧版本核心指标对比、设置自动回滚阈值、处理新旧版本资源共存、以及放量节奏设计。只调权重不做观测，等于闭着眼睛开车。

为何常见：灰度发布的表象是“流量切分”，操作简单，因此容易让人忽略背后完整的验证闭环。

面试题

Q1. 推理服务化最核心的目的是？

单选题 · easy

  • A.加快训练收敛速度
  • B.把模型变成在线服务← 正确答案
  • C.替代业务关系数据库
  • D.自动清洗海量训练数据

答案：B。推理服务化的本质是把训练好的模型从离线环境剥离，变成独立、弹性、标准化的在线服务。A 是训练优化的目标，C 是数据库的职责，D 是数据工程的事，都与“让模型对外营业”无关。

Q2. GPU 显存配额管理的直接作用是？

单选题 · easy

  • A.缩小模型文件的体积
  • B.防止租户挤占他人显存← 正确答案
  • C.提升单次推理的精度
  • D.减少业务网络带宽消耗

答案：B。显存配额给每个任务设定显存上限，防止一个模型或租户把整卡占满、挤压邻居。它不改变模型体积、精度或网络带宽，而是解决“灶台被霸占”的问题。

Q3. 模型冷启动时主要的耗时环节是？

单选题 · easy

  • A.用户输入文本预处理
  • B.权重载入显存与算子初始化← 正确答案
  • C.日志数据采集与上报
  • D.网关路由表动态刷新

答案：B。冷启动指实例从无到有的准备过程，主要包括把权重文件加载进显存、创建 CUDA 上下文和执行引擎。用户输入预处理是运行时行为，日志与路由均不属于模型加载范畴。

Q4. 动态批处理最重要的收益是什么？

单选题 · mid

  • A.降低单请求端的延迟
  • B.提高 GPU 吞吐摊薄开销← 正确答案
  • C.大幅减少模型参数
  • D.提升离线训练效率

答案：B。动态批处理把多个请求拼成一个 batch 并行计算，GPU 利用率大幅提升，单位请求的计算开销被摊薄。它可能略微增加单个请求排队延迟，但显著提高整体吞吐，且与模型参数、离线训练无关。

Q5. 金丝雀发布切小流量是为了验证？

单选题 · mid

  • A.新版本在真实流量下稳定← 正确答案
  • B.旧版本日志留存完整性
  • C.模型权重文件的唯一性
  • D.机房总体耗电的下降

答案：A。金丝雀发布让一小部分真实请求先打到新版本，目的是在低风险范围内验证其稳定性、延迟和业务效果。与旧版本日志、权重唯一性、机房功耗没有直接关系。

Q6. 缩短 MTTR 对系统可用性的影响是？

单选题 · mid

  • A.故障发生频率显着增加
  • B.恢复更快可用性提升← 正确答案
  • C.训练耗时变得更短
  • D.监控告警不再需要

答案：B。可用性公式 A = MTBF / (MTBF + MTTR) 中，MTTR 越小，分母越小，A 越大。缩短恢复时间直接提升可用性，但不会改变故障频率，更不会影响训练耗时。

Q7. 单实例 50 QPS，峰值需求 300 QPS，最小实例数是？

单选题 · hard

  • A.6 个实例← 正确答案
  • B.2 个实例
  • C.8 个实例
  • D.10 个实例

答案：A。实例数 = 峰值需求 ÷ 单实例容量 = 300 ÷ 50 = 6。这是按理想线性扩展估算的最小值，实际部署通常还会加 20%-50% 冗余来应对单点故障和流量毛刺。

Q8. 多租户隔离需要覆盖以下哪些资源？

多选题 · mid

  • A.显存与算力的配额← 正确答案
  • B.模型参数与用户数据← 正确答案
  • C.性能噪声与请求排队← 正确答案
  • D.离线训练脚本仓库

答案：ABC。多租户隔离要管三类：资源配额（显存/算力上限）、数据安全（模型参数与用户数据权限）、性能噪声（排队与限流避免互相干扰）。训练脚本仓库属于开发协作范畴，不在推理服务隔离范围内。

Q9. 完整灰度发布流程通常包含哪些环节？

多选题 · hard

  • A.新版本部署至少量实例← 正确答案
  • B.按策略切分部分流量← 正确答案
  • C.实时对比新旧版本指标← 正确答案
  • D.删除旧版本后全量上线

答案：ABC。灰度发布先部署少量新实例，再按权重或特征切分流量，同时持续对比新旧版本的核心指标，异常时自动回滚。D 的做法是“一次性替换”，没有灰度缓冲，风险极高。

Q10. 以下哪些是降低推理成本的有效手段？

多选题 · mid

  • A.小模型填充显存碎片← 正确答案
  • B.在线离线混合部署← 正确答案
  • C.无限扩增服务实例
  • D.按流量指标自动缩容← 正确答案

答案：ABD。碎片化填充提高显存利用率，混部让算力闲时也有活干，自动缩容避免低峰浪费，三者都是降本利器。无限扩增实例只会增加成本，不能降低成本。