想象你周末中午走进一家新开的餐厅，门口挂着“营业中”，可进去以后却发现后厨还没生火、服务员还在换工装、收银机也刚开机。你坐下等了很久，连一杯水都上不来，这顿饭的体验自然很糟糕。AI推理服务也经常这样：模型已经“部署”到集群里了，但真正能服务用户之前，还有一段漫长的冷启动期——要加载几个GB甚至几十GB的模型文件、初始化推理框架、分配GPU显存、预热缓存。这段时间里，请求要么排队，要么直接超时。本文用“餐厅开业”这个生活场景贯穿始终，带你搞懂冷启动的四大优化策略：模型加载加速（提前备菜）、缓存预热（招牌菜提前做好）、渐进式流量引入（先放少量客人进来）、分级就绪检测（厨房各岗位确认好再开张）。学完之后，你就能理解如何让模型“从部署到可用”的时间大幅缩短，让推理服务真正做到快速上线。

岗位关联

对AI云服务架构师和平台工程师来说，掌握冷启动优化能显著缩短模型上线窗口、降低扩容失败率，是保障推理服务SLO（服务等级目标）的核心基本功。

目录
  1. 可视化演示
  2. 冷启动探因
  3. 模型加载加速
  4. 缓存预热策略
  5. 渐进式流量引入
  6. 分级就绪检测
  7. 架构优化设计
  8. 监控与持续调优
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示推理服务冷启动瓶颈分析、四大优化策略（模型加载加速/缓存预热/渐进流量/分级就绪）与健康检查分级设计，理解如何让模型快速上线。

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

推理服务冷启动瓶颈分析 Pod创建→模型加载→权重初始化→推理预热，每步都有耗时瓶颈 中小模型冷启动3-5分钟，大模型可达10分钟以上 T(cold) = T(pod) + T(load) + T(warmup) 全链路耗时分析

冷启动探因

想象你开了一家餐厅，门口挂着“营业中”，但后厨还没生火、服务员还在换工装、收银机也刚开机。这时客人进来，只会体验到极差的“冷启动”。AI推理服务也是一样，模型完成部署并不等于可以服务用户：Pod 真正开始处理请求之前，还有一个漫长的准备阶段。

在 Kubernetes 中，推理应用从 Pod 创建到响应第一个推理请求，通常要经历容器启动、框架初始化、模型加载、显存分配、算子编译、缓存预热等步骤。这个过程可能长达数十秒甚至数分钟，而这期间一旦有流量进来，请求就会排队或超时。若探针把“进程已运行”误判为“可提供服务”，流量就会撞上未就绪实例，造成大量 5xx。

冷启动时间不是孤立指标，它会直接影响扩容效率和发布体验。优化第一步是先把冷启动拆成可观测的阶段，并记录每个阶段的耗时，这样才能知道时间到底花在了哪里。这个拆解过程就像餐厅开业前，把“从开门到上第一道菜”的每个环节都摆到台面上逐一计时。

回到餐厅场景，优秀的店主不会在“营业中”牌子挂出后就不管了，而会盯住“从开门到第一道菜上桌”的每个环节。诊断冷启动，本质上就是在测量这条备菜流水线的耗时分布。

Tcold=Tload+Tinit+Twarm\displaystyle T_{\text{cold}} = T_{\text{load}} + T_{\text{init}} + T_{\text{warm}}
冷启动总耗时等于模型加载、框架初始化和缓存预热三个子阶段的耗时之和。
  1. 总耗时$T_{\text{cold}}$ 表示从 Pod 启动到真正可服务的时间，单位通常为秒或毫秒。
    TcoldT_{\text{cold}}
  2. 模型加载$T_{\text{load}}$ 表示读取模型文件并载入内存或显存的耗时，通常是冷启动中的大头。
    TloadT_{\text{load}}
  3. 框架初始化$T_{\text{init}}$ 表示推理框架、CUDA 上下文等初始化耗时。
    TinitT_{\text{init}}
  4. 缓存预热$T_{\text{warm}}$ 表示热点路径缓存预热所需耗时。
    TwarmT_{\text{warm}}

模型加载加速

餐厅里最难准备的，往往是需要长时间解冻、腌制的大块牛肉。模型文件就是推理服务里的“大块牛肉”，经常达到几个GB甚至几十GB，加载它们往往占据冷启动时间的大头。

模型加载耗时主要由文件大小和 IO 带宽决定。如果从远端对象存储拖整个文件，网络延迟和磁盘吞吐都会放大耗时；同时，序列化格式解析也可能成为 CPU 瓶颈。常见的优化思路包括：使用更高效的模型格式（如 Safetensors 等兼容 mmap 的检查点格式），减少 pickle 解析开销；把模型分成多个分片并发读取后合并；用 mmap 让页面按需加载，不必一次性读全；在平台层面提前把模型散到本地缓存目录，甚至用异步加载为下一个副本做预先准备。

并行加载并不是玄学，它背后的逻辑很简单：把一个大任务切成多个小任务，让多个线程同时向存储系统要数据，总耗时就从“整块搬运”变成“最慢那块分片”的耗时。这就像后厨把一头牛分给四个厨师同时处理，而不是一个人从头切到尾。

就像餐厅在营业前把牛肉切好、腌好、备在冷藏柜里，模型加载加速就是让推理引擎的“食材”提前到位，开门后直接下锅，不用等客人点完菜才临时解冻。

Tload=SB,Tload′=max⁡i=1nTi\displaystyle T_{\text{load}} = \frac{S}{B},\quad T'_{\text{load}} = \max_{i=1}^{n} T_i
串行加载耗时等于模型大小除以读取带宽；分片并行后，总耗时约等于最慢分片的耗时。
  1. 模型文件大小$S$ 表示模型文件的总字节数，S 越大加载越慢。
    SS
  2. 读取带宽$B$ 表示从磁盘、内存或网络读取数据的带宽，带宽越高加载越快。
    BB
  3. 串行加载时间$T_{\text{load}} = \dfrac{S}{B}$ 表示整块读取模型文件的耗时。
    Tload=SBT_{\text{load}} = \frac{S}{B}
  4. 并行分片耗时$T_i$ 是第 $i$ 个分片的加载耗时，并行后总耗时取所有分片中的最大值。
    Tload′=max⁡i=1nTiT'_{\text{load}} = \max_{i=1}^{n} T_i

缓存预热策略

餐厅里最受欢迎的招牌菜，如果等客人点单再从头炖，一桌要等半小时。聪明的做法是提前炖好几份放在保温柜里，客人下单后稍微加热就端上桌。推理服务也有自己的“招牌菜”，比如 tokenizer 结果、prompt 缓存、embedding 查询结果等。

冷启动时缓存是空的，第一批请求会“冷手冷脚”地计算所有中间结果，时延很高，甚至触发超时。缓存预热指在服务正式接流前，用一组有代表性的请求让模型先跑一遍，或者把常用特征与中间结果主动写入缓存，让“首请求”不再做冷板凳。

预热需要注意三点：第一，识别热点，只预热高频输入对应的缓存，避免内存被无关数据塞满；第二，设计触发时机，把预热完成作为 readiness 的前置条件；第三，管理缓存容量和过期策略，用 LRU、TTL 防止陈旧数据。大型平台往往有专门的预热任务在后台执行，并与发布流水线联动，确保预热完成前不接入流量。

招牌菜备得越充分，客人点单后上菜就越快；缓存预热做得好，服务接流后第一批请求也能保持稳定低时延，而不是让第一个用户当“试验品”。

h=nhitntotal,h≥htarget\displaystyle h = \frac{n_{\text{hit}}}{n_{\text{total}}},\quad h \ge h_{\text{target}}
缓存命中率是命中次数除以总请求次数，预热后应达到目标命中率，首批请求才能维持低延迟。
  1. 命中次数$n_{\text{hit}}$ 表示在缓存中直接命中的请求次数。
    nhitn_{\text{hit}}
  2. 总请求次数$n_{\text{total}}$ 表示预热后一段时间内的总请求次数。
    ntotaln_{\text{total}}
  3. 命中率$h$ 表示缓存命中率，数值越接近 1 说明缓存效果越好。
    h=nhitntotalh = \frac{n_{\text{hit}}}{n_{\text{total}}}
  4. 目标命中率$h_{\text{target}}$ 是业务可接受的最低命中率，达到该值后服务才能稳定承载流量。
    h≥htargeth \ge h_{\text{target}}

渐进式流量引入

新餐厅开业，哪怕后厨准备得再好，也很少在第一天中午就让所有客人同时涌进来。理性的店主会先请少量朋友试菜，确认口味和服务稳定后，再慢慢扩大接待量。新版本推理服务上线，同样需要渐进式流量引入。

如果一次性把全部流量切给新实例，冷启动期间的小问题就会瞬间放大成全局事故。渐进式策略先把 5% 流量放到新版本，观察错误率、P99 延迟、GPU 利用率等指标，稳定后再升到 10%、50%，最终切到 100%。在 K8s 中，可以先用滚动更新和就绪探针控制 Pod 数量；在服务网格或网关层，则可以通过流量权重更精细地控制新旧版本比例。

渐进式放量的关键是“渐进”必须配合自动回滚：一旦指标恶化，立即把流量切回旧版本，而不是继续放量。这就像餐厅在试营业期间，如果收到关于某道菜的差评，会立刻停售那道菜，而不是让所有桌都被差评淹没。

分批放客不是胆小，而是给“开业流程”安装一个安全气囊：即使某个环节出了问题，最多只影响一小部分客人，不会让整家餐厅的招牌瞬间砸掉。

w(t)=min⁡(1,tTramp)\displaystyle w(t) = \min\left(1, \frac{t}{T_{\text{ramp}}}\right)
新版本流量比例随渐进窗口线性增长，但不会超过 100%，窗口设计越长，风险越小。
  1. 当前时间$t$ 表示从开始放量到当前时刻经过的时间。
    tt
  2. 渐进窗口$T_{\text{ramp}}$ 表示从 0% 放量到 100% 预计需要的总时间。
    TrampT_{\text{ramp}}
  3. 流量占比$w(t)$ 表示当前时刻新版本承担的流量比例。
    w(t)=tTrampw(t) = \frac{t}{T_{\text{ramp}}}
  4. 上限限制$\min(1, \cdot)$ 保证流量比例不会超过 100%。
    min⁡(1,tTramp)\min\left(1, \frac{t}{T_{\text{ramp}}}\right)

分级就绪检测

一家餐厅说自己“可以营业了”，需要很多前提：后厨炉火旺、服务员到岗、餐具消毒完成、收银系统连通。如果只看“大门开了”就营业，客人进门后会发现什么都还没准备好。很多推理服务的就绪检测，就犯了只看端口连不连通的错误。

分级就绪检测把“可服务”拆成多个等级：进程存活、模型加载完成、显存就绪、缓存预热完成、框架可以返回正确推理结果。只有全部满足，才把实例状态置为 Ready，然后才允许 Service 转发流量。否则，一个只启动了进程但模型还在加载的 Pod，被当成健康实例接流量，只会产生一堆超时错误。

实践中可以同时提供 /livez 和 /readyz 两个端点：/livez 做存活检查，/readyz 做就绪检查。由于模型加载很慢，需要先配置 startupProbe 保护慢启动进程，避免被 livenessProbe 误杀。更高级的做法是使用 K8s Readiness Gate，由自定义 controller 在验证模型版本和预热状态后，统一设置 Ready 条件。

只有每道检查都通过，才缓缓打开餐厅大门；分级就绪，就是把“营业中”这块牌子变成一道道可验证的工序，而不是一个简单的时间点。

R=∑iwiri,∑iwi=1,R≥Rready\displaystyle R = \sum_{i} w_i r_i, \quad \sum_i w_i = 1,\quad R \ge R_{\text{ready}}
就绪分数是各组件就绪状态的加权求和，只有当加权分达到阈值时，服务才算真正就绪。
  1. 组件就绪状态$r_i$ 表示第 $i$ 个组件是否就绪，取值为 0 或 1。
    rir_i
  2. 组件权重$w_i$ 表示第 $i$ 个组件对整体就绪的重要程度，所有权重之和为 1。
    wi,∑iwi=1w_i,\quad \sum_i w_i = 1
  3. 就绪分数$R$ 是所有组件就绪状态的加权和。
    R=∑iwiriR = \sum_{i} w_i r_i
  4. 就绪阈值$R_{\text{ready}}$ 是内置的就绪门槛，只有 $R \ge R_{\text{ready}}$ 时才允许接流量。
    R≥RreadyR \ge R_{\text{ready}}

架构优化设计

有的连锁餐厅把所有菜品预加工在中央厨房，分店开业时只需要简单加热，所以任何一家分店都能快速开门迎客。推理服务的“中央厨房”就是架构层面的预加载与状态解耦。

想让冷启动更容易优化，推理服务本身要尽量无状态：每个副本不持有用户级状态，模型加载结果可以通过共享存储或本地缓存复用。无状态副本可以随时扩缩容，新增实例不需要从零恢复一堆对话上下文，冷启动成本自然更低。

再从架构上做几件事：搭建高速模型仓库，把模型发布到分布式缓存或容器镜像中，新节点创建时，模型已经近在咫尺；做实例池化预热，让一批备用实例常驻并已完成模型加载，收到扩容信号后直接接流量；做冷热分离，热点小模型常驻 GPU/内存池，冷门大模型按需加载。Serverless 场景下还可以启用容器快照恢复，让新实例直接恢复到“模型已加载”的状态，把冷启动从分钟级压到秒级。

中央厨房把复杂烹饪前置，分店开张自然快；架构解耦与模型预置，让每个推理副本都能“准备好再营业”，而不是让每次扩容都重新经历一次慢启动。

Acluster=1−(1−Ainstance)n\displaystyle A_{\text{cluster}} = 1 - (1 - A_{\text{instance}})^n
n 个冗余副本时，只要至少一个副本可用，整个服务就可用；副本越多，单点冷启动故障的影响越小。
  1. 单实例可用率$A_{\text{instance}}$ 表示一个推理副本处于健康可用状态的概率。
    AinstanceA_{\text{instance}}
  2. 单实例不可用率$1 - A_{\text{instance}}$ 表示一个副本不可用的概率。
    1−Ainstance1 - A_{\text{instance}}
  3. 全部不可用概率$(1 - A_{\text{instance}})^n$ 表示 n 个副本同时不可用的概率。
    (1−Ainstance)n(1 - A_{\text{instance}})^n
  4. 集群可用率$A_{\text{cluster}}$ 表示至少一个副本可用的概率，即整个服务对外可用率。
    Acluster=1−(1−Ainstance)nA_{\text{cluster}} = 1 - (1 - A_{\text{instance}})^n

监控与持续调优

餐厅开业不是一次性的，经理会每天记录“开门到上第一道菜”的时间，检查哪个环节拖延，再持续调整排班和备餐计划。冷启动优化同样需要一套完整的监控和持续调优机制。

需要建立“启动时间线”：Pod 创建时间、镜像拉取耗时、容器启动耗时、模型加载耗时、预热耗时、探针通过时间、首次接流量时间。每条时间线都打上版本号和部署批次，方便对比。这样在发布新版本后，可以立刻看到冷启动时间是否变长、卡在哪个环节。

通过 Prometheus 指标和告警规则，把冷启动时长、就绪前请求失败率、首请求时延纳入发布准入检查。CI/CD 中增加“冷启动回归测试”：模拟一次新副本上线，如果启动时间超过阈值就阻断发布。每次优化都记录前后数据，形成规范，沉淀到团队的发布流水线和知识库。这个循环就像餐厅每天复盘“备菜-出餐-翻台”的每个细节，不断把耗时砍掉。

持续调优不是一次性工程，而是像餐厅每天复盘每个环节一样，让“上线到可用”的时间越来越短。今天快 1 秒，明天快 2 秒，积累下来就是稳定的发布体验和更高的服务可用性。

η=Tbefore−TafterTbefore×100%\displaystyle \eta = \frac{T_{\text{before}} - T_{\text{after}}}{T_{\text{before}}} \times 100\%
冷启动优化率用优化前后耗时差值与优化前耗时的比值表示，数值越高说明优化越明显。
  1. 优化前耗时$T_{\text{before}}$ 表示启动优化前一次冷启动的总耗时。
    TbeforeT_{\text{before}}
  2. 优化后耗时$T_{\text{after}}$ 表示实施优化后一次冷启动的总耗时。
    TafterT_{\text{after}}
  3. 节省时间$T_{\text{before}} - T_{\text{after}}$ 表示通过优化节省下来的时间。
    Tbefore−TafterT_{\text{before}} - T_{\text{after}}
  4. 优化率$\eta$ 表示相对优化前耗时提升了多少百分比。
    η=Tbefore−TafterTbefore×100%\eta = \frac{T_{\text{before}} - T_{\text{after}}}{T_{\text{before}}} \times 100\%

AI 应用场景

云原生推理平台的金丝雀发布

阶段：模型部署与发布

解决的问题：传统方式下，K8s 就绪探针只检查端口连通性，模型还在加载时实例就被当成健康节点，流量一旦切换过来就会大量超时。通过 startupProbe 拉长保护期、readinessProbe 等待模型加载和预热完成、服务网格权重 5% 到 100% 渐进放量，并配置异常自动回滚，可以让新版本发布对用户几乎无感。

具体案例：某推荐系统部署新版 embedding 模型时，模型加载从 45 秒降到 8 秒，发布期间 5xx 错误率从 2.1% 降到 0.03%，发布窗口从原来的半小时缩短到 8 分钟。

Serverless 推理服务的快速冷启动

阶段：推理资源调度

解决的问题：Serverless 推理平台会频繁扩容缩容，每次扩容都要重新拉取镜像、加载模型、预热缓存，冷启动成本非常高。使用模型分片并行加载、共享缓存预热和容器快照恢复，可以让新实例在秒级恢复到“模型已加载”的状态。

具体案例：某大模型 API 平台高峰期每分钟扩 20 个副本，通过容器快照和并行加载，冷启动从 90 秒降到 3 秒，峰值期间请求成功率稳定在 99.9% 以上。

Python 演示

python75 行
import threadingimport time class ModelShard:    def __init__(self, name, load_seconds):        self.name = name        self.load_seconds = load_seconds        self.loaded = False     def load(self):        time.sleep(self.load_seconds)        self.loaded = True        return self.name class ModelLoader:    def __init__(self, shards):        self.shards = shards     def load_serial(self):        start = time.time()        for shard in self.shards:            shard.load()        return time.time() - start     def load_parallel(self):        start = time.time()        threads = [threading.Thread(target=shard.load) for shard in self.shards]        for t in threads:            t.start()        for t in threads:            t.join()        return time.time() - start class CacheWarmer:    def __init__(self, hot_keys):        self.cache_map = {}        self.hot_keys = hot_keys     def warm(self):        for key in self.hot_keys:            time.sleep(0.2)            self.cache_map[key] = "warm"        return len(self.cache_map) class TrafficController:    def __init__(self, max_weight=100, step=10):        self.max_weight = max_weight        self.step = step        self._cur_weight = 0     def next_weight(self):        self._cur_weight = min(self.max_weight, self._cur_weight + self.step)        return self._cur_weight def main():    shards = [ModelShard("encoder", 1.2), ModelShard("embedding", 0.6), ModelShard("head", 0.4)]    loader = ModelLoader(shards)    serial_time = loader.load_serial()     loader2 = ModelLoader(shards)    parallel_time = loader2.load_parallel()     warmer = CacheWarmer(["user:1", "user:2", "user:3"])    warmed = warmer.warm()     tc = TrafficController()    weights = [tc.next_weight(), tc.next_weight(), tc.next_weight()]     print("serial load: %.2fs" % serial_time)    print("parallel load: %.2fs" % parallel_time)    print("warmed keys:", warmed)    print("traffic weights:", weights) if __name__ == "__main__":    main()
目的：模拟推理服务冷启动优化中的并行模型加载、缓存预热和渐进式流量控制，展示三种策略的核心逻辑。
  1. threads = [threading.Thread(target=shard.load) for shard in self.shards]为每个模型分片创建独立线程，准备并行加载。
  2. for t in threads: t.start()启动所有线程，让分片几乎同时开始读取。
  3. for t in threads: t.join()等待所有分片加载完成，确保返回时模型已完整就绪。
  4. self.cache_map[key] = "warm"将热点 Key 提前写入缓存，模拟预热过程。
  5. self._cur_weight = min(self.max_weight, self._cur_weight + self.step)每次调用把流量权重增加一个步长，模拟渐进放量。

常见误区

误区我在 readinessProbe 里只检查 8080 端口能不能连上，连上就 Ready，可为什么上线后还有很多请求超时？

正解端口通只代表进程存在，不代表模型加载完成和缓存预热结束。这就像餐厅大门开了，但后厨还没准备好。就绪探针应主动调用 /readyz，并等待模型加载、缓存预热全部完成后返回 200。

为何常见：开发环境模型小、加载快，端口一通就能推理，容易让人忽略生产环境大模型加载需要几十秒的问题。

误区冷启动请求老超时，我直接把网关超时从 3 秒改成 60 秒，用户是不是就能等到了？

正解拉长超时只是让用户等更久，不是解决冷启动。真正要做的是让服务尽快就绪：用 startupProbe 保护慢启动、就绪后再接流量，而不是用超时掩盖一切问题。

为何常见：超时配置是门槛最低的“解决办法”，改一个参数看似立刻生效，实际上掩盖了真实瓶颈。

误区预热时把所有样本和中间结果都塞进缓存，内存不够就扩容，这样总没错吧？

正解预热必须与热点匹配，盲目灌数据会占满内存，甚至挤占模型本身需要的显存和内存空间。应识别高频 Key，用 LRU/TTL 管理，并把预热完成作为就绪条件之一。

为何常见：看到“预热”两个字，容易理解成把所有数据都跑一遍，忽略了业务访问分布的偏斜性。

误区权重从 5% 慢慢升到 100% 就安全了，不用一直盯指标。

正解渐进式流量只是控制爆炸半径，真正决定是否继续放量的是监控反馈。如果没有错误率和延迟告警，异常往往要升到 50% 以后才暴露出来。

为何常见：把策略本身当成了结果，忽略了“放量-观测-决策”的闭环，这是发布流程里最常见的认知偏差。

面试题

Q1. 推理服务的冷启动通常发生在哪个阶段？

单选题 · easy

  • A.模型训练过程中
  • B.数据离线清洗时
  • C.Pod启动到可服务之间← 正确答案
  • D.用户请求全部完成后

答案：C。冷启动指 Pod 创建后到能正常处理推理请求之间的准备期，对应选项中的“Pod启动到可服务之间”。训练、离线清洗和请求结束后都不属于推理服务的冷启动阶段。

Q2. 以下哪项能直接缩短模型文件加载耗时？

单选题 · mid

  • A.增大网关超时时间
  • B.提高日志输出等级
  • C.降低推理并发上限
  • D.使用内存映射加载模型← 正确答案

答案：D。内存映射（mmap）让模型文件按需读入内存，避免整块加载，能直接减少加载耗时。网关超时、日志等级和并发上限都不会让模型文件更快进内存。

Q3. 缓存预热的主要目标是什么？

单选题 · easy

  • A.让热点数据提前就位← 正确答案
  • B.减小模型文件大小
  • C.减少推理副本数量
  • D.降低网络带宽费用

答案：A。缓存预热的核心是让高频请求依赖的中间结果提前进入缓存，减少首批请求的冷缓存开销。它不会改变模型文件大小，也不以降低网络费用为目标。

Q4. 渐进式流量引入的核心价值是？

单选题 · mid

  • A.立刻提高模型吞吐
  • B.异常时只影响少数用户← 正确答案
  • C.省去监控与告警
  • D.让模型文件加载更快

答案：B。渐进式放量让新版本先接收一小部分流量，一旦出问题，影响面被限制在少数用户。它不直接提升吞吐，也不能替代监控，更不会加速模型加载。

Q5. Pod 的 readinessProbe 应重点检查什么？

单选题 · mid

  • A.仅检查端口是否监听
  • B.模型加载和预热是否完成← 正确答案
  • C.容器日志是否正常输出
  • D.镜像是否已经拉取完成

答案：B。就绪探针应确认实例是否具备实际服务能力，即模型加载和缓存预热是否完成。端口监听只代表进程活着，日志和镜像状态也不能代表推理服务已就绪。

Q6. 下列哪些做法属于冷启动优化策略？

多选题 · hard

  • A.模型分片并行加载← 正确答案
  • B.服务启动前缓存预热← 正确答案
  • C.流量按权重渐进放开← 正确答案
  • D.无限提高就绪探针超时

答案：ABC。并行加载、缓存预热和渐进式放量都是经典优化手段。无限提高探针超时只是逃避问题，并不能减少冷启动时间，所以不属于有效策略。

Q7. 关于分级就绪检测，正确的说法有？

多选题 · mid

  • A.进程存活不等于可服务← 正确答案
  • B.模型加载完即可接流量
  • C.预热完成后再置为就绪← 正确答案
  • D.就绪检测只需检查端口

答案：AC。分级就绪要求把进程、模型、预热等多个状态都检查后再置为 Ready。模型加载完还不够，因为缓存可能还是冷的；只检查端口更是常见误判。

Q8. 新版本从 5% 流量逐步升到 100% 属于？

单选题 · easy

  • A.模型并行加载
  • B.缓存预热调度
  • C.渐进式流量引入← 正确答案
  • D.内存映射优化

答案：C。将流量按 5%、10%、50%、100% 逐步放大的过程就是渐进式流量引入。并行加载、缓存预热和 mmap 都属于加速准备阶段的手段。

Q9. 多副本可用性公式 A=1-(1-a)^n 说明什么？

单选题 · hard

  • A.副本越多单点风险越高
  • B.冗余副本能降低单点风险← 正确答案
  • C.模型文件一定会被压缩
  • D.冷启动时间与副本无关

答案：B。该公式表示 n 个独立副本同时不可用的概率是 (1-a)^n，所以整体可用率随副本数量增加而提高。它说明冗余架构能降低单点冷启动故障带来的风险，与模型压缩无关。

Q10. Serverless 推理平台减少冷启动可采用哪些手段？

多选题 · extreme

  • A.模型分片并行加载← 正确答案
  • B.采用快照恢复实例← 正确答案
  • C.预热模型缓存← 正确答案
  • D.禁止使用任何探针

答案：ABC。并行加载让模型更快进内存，快照恢复让新实例跳过重复加载，缓存预热让首批请求不再冷缓存。探针是保障就绪的必要机制，禁止探针只会让流量打到未就绪实例。