城市里有两类餐馆。一类是常年营业的大酒楼，不管有没有客人，厨师、水电、房租一样也不少——这就像传统的 AI 服务器，买回来就得养着，流量低潮时依然在烧钱。另一类是“按铃开火的深夜食堂”：门前挂一口铜铃，客人按下铃，主厨才穿围裙、点灶台、开火出菜；没人按铃，整间厨房熄灯休息，一分钱电费都不花。AWS Lambda 就是这间深夜食堂的厨房，而 AI 模型，就是主厨那本秘不外传的菜谱。这篇文章要讲的是：怎么把 AI 模型这位“主厨”请进这种按铃才开火的厨房——菜谱太厚怎么办（模型体积）、开门第一单为什么特别慢（冷启动）、怎么让出菜又快又省钱（配置与优化），最后端出一桌真能营业的实战案例。读完之后你会发现，用 Serverless 部署 AI 推理，相当于给模型雇了一群“随叫随到、按秒计薪”的兼职主厨。

岗位关联

对 AI 从业者来说，掌握 Lambda 部署 AI 推理，意味着你交付的不再是“一个模型文件”，而是一项“按用量付费、自动扩缩容”的 AI 服务能力——这是 MLOps、云架构与 AI 工程化面试与实战中的高频考点。

目录
  1. 可视化演示
  2. 无服务器基础
  3. AI推理难点
  4. 函数配置优化
  5. 部署载体策略
  6. 冷启动攻坚
  7. 性能成本调优
  8. 部署实践案例
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示Serverless架构下Lambda函数处理AI推理请求的完整链路，对比冷启动与热启动的延迟差异，并分析内存配置对推理性能的影响。

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

Serverless 推理优劣势 冷启动慢：需加载运行时与模型 热启动快：复用执行环境 按需计费：无流量零成本 延迟=冷+推理 预热与分层是关键

无服务器基础

深夜食堂的经营哲学是“客人不按铃，主厨就不开火”：没有订单时，厨房灯灭人歇；订单一来，立刻点火。传统酒楼则相反，不管有没有客人，厨师都得在岗，房租水电照付——这正是传统 AI 服务器与 Serverless 的本质差异：你不再租下一整间酒楼，而是按“实际出菜”付费。

“无服务器”（Serverless）并不是没有服务器，而是服务器这层复杂性被云厂商“藏”起来了。AWS Lambda 就是这种思想的载体：你只写一个函数（菜谱），交给 AWS，剩下的事情——容器怎么起、机器在哪、怎么扩容——都由平台代管。对 AI 部署而言，这意味着模型推理服务可以像一道“招牌菜”一样，被放进一个随时待命的厨房。

Lambda 的三个核心特性构成了这道菜的基础：一是事件驱动，S3 上传、API 请求、消息队列都能“按铃”触发函数；二是按需计费，没有调用就零成本；三是自动扩缩容，订单暴涨时平台自动“加灶台”，订单回落时自动收摊。

把这个公式套回深夜食堂：你只付“有人点菜的那一分钟”，没人来的时候账本是零。理解了这间厨房的收费逻辑，我们就能继续探讨：为什么把 AI 主厨请进来，比普通出菜要难得多。

C=N×(Preq+M×D×PGBs)\displaystyle C = N \times \left(P_{\text{req}} + M \times D \times P_{\text{GBs}}\right)
这个公式是 Lambda 的“收银台”：总费用等于“每通电话的敲门费”加上“占用灶台的分钟数 × 燃气单价”。
  1. C——总费用一段时间内为这道 AI 服务支付的总账单，单位是美元或人民币。
    C\displaystyle C
  2. N——调用次数客人总共按了多少次铃，也就是函数被触发的总次数。
    N\displaystyle N
  3. P_req——单次请求单价每按一次铃收的“敲门费”。
    Preq\displaystyle P_{\text{req}}
  4. M——内存大小分配给函数的内存，单位 GB，决定灶台火力上限。
    M\displaystyle M
  5. D——执行时长函数从开始到返回结果所消耗的总秒数。
    D\displaystyle D
  6. P_GBs——单位算力价格每 GB-秒（1GB 内存跑满 1 秒）的燃气单价。
    PGBs\displaystyle P_{\text{GBs}}

AI推理难点

深夜食堂什么菜都能做，但主厨的独家菜谱（AI 模型）厚得像砖头，甚至像整套百科全书。每次开火前，主厨都要翻出菜谱、把关键页背进脑子——在云上，这就是“把模型参数从磁盘加载进内存”的过程。

AI 推理（Inference）就是模型前向计算一次，用训练好的权重对输入做预测。它不像普通函数那样“轻装上阵”，而是要随身携带三样重装备：模型文件（几百 MB 到数 GB）、推理框架（PyTorch/TensorFlow）、以及一堆科学计算依赖（numpy 等）。把这些搬进 Lambda 的小厨房，会引发四大难题：模型体积超过部署包上限；冷启动时加载模型导致首单极慢；纯 CPU 环境下大模型推理耗时很长；依赖与框架版本管理容易“打架”。

所以，请 AI 主厨进深夜食堂的关键，是别让他每次都被窝里爬起来背菜谱。这就引出第三部分：给厨房定规矩，让“背菜谱”这件事变得可预测、可控制。

Tcold=Truntime+Tmodel+Tinput+Tinfer\displaystyle T_{\text{cold}} = T_{\text{runtime}} + T_{\text{model}} + T_{\text{input}} + T_{\text{infer}}
冷启动总耗时是一条“流水线”：容器醒来 + 背菜谱 + 洗菜切菜 + 真正下锅，四段相加。
  1. T_cold——冷启动总耗时第一单从按下铃到端出菜的总时间。
    Tcold\displaystyle T_{\text{cold}}
  2. T_runtime——运行时启动容器被创建、Python 解释器被唤醒的时间。
    Truntime\displaystyle T_{\text{runtime}}
  3. T_model——模型加载把菜谱从磁盘“背”进内存的时间，往往占总耗时大头。
    Tmodel\displaystyle T_{\text{model}}
  4. T_input——输入处理对请求做解码、缩放、归一化的时间。
    Tinput\displaystyle T_{\text{input}}
  5. T_infer——推理计算模型真正前向传播做出预测的时间。
    Tinfer\displaystyle T_{\text{infer}}

函数配置优化

深夜食堂门口挂着三块牌子：灶台火力（内存大小）、出菜时限（超时）、同时开几个灶台（并发）。定错规则，厨房就会乱成一锅粥。

Lambda 函数有四项关键配置，直接影响 AI 推理的成败。第一是内存（128MB 到 10GB），它同时线性分配 CPU 算力——内存越大，灶台火越旺，推理越快。第二是超时，单个函数最长可运行 900 秒（15 分钟），推理任务必须给“冷启动 + 推理 + 网络传输”留足余量。第三是并发控制，决定同一时刻能接多少单。第四是幂等设计：事件可能被平台重试，同一道菜做两遍，结果必须一模一样。

对 AI 推理来说，内存是首要旋钮：一个 ResNet-50 图像分类模型权重约 100MB，建议至少配 1024MB；超时应按最坏情况（冷启动 + 推理 + 网络）预留；并发则可以用一条经典定律估算。

深夜食堂的大厨站在白板前算账：客人每秒来 5 个、每道菜平均 2 秒，那就至少准备 10 个灶台。定好这些规矩，接下来就要考虑更实际的问题——厚厚的大菜谱，到底怎么带进厨房。

N=λ×T\displaystyle N = \lambda \times T
这条定律叫 Little 定律：每秒来多少客人（λ），每道菜做多久（T），相乘就是同时需要几个灶台（N）。
  1. N——所需并发数要同时开多少个灶台，客人才不用排队。
    N\displaystyle N
  2. λ——每秒请求数客人平均每秒按多少次铃。
    λ\displaystyle \lambda
  3. T——平均处理时长每道菜从接单到出菜的平均秒数。
    T\displaystyle T

部署载体策略

厚菜谱带进厨房有三条路：折成小抄塞口袋（部署包）、放在公用调料架上随取随用（Layer）、干脆开一辆移动餐车进来（容器镜像）。还有一招——把菜谱手写体整体缩小（模型量化）。

具体来说，ZIP 部署包把函数代码和依赖打包上传，适合小模型；Lambda 层（Layer）把 numpy、torch 等公共依赖做成“共享调料架”，多个函数复用，不用每个包都重复打包；容器镜像（ECR）最大支持 10GB，适合大型模型。此外，模型量化把 FP32 权重压成 FP16 甚至 INT8，体积直接减半或减到四分之一，推理也更快，代价是精度有轻微损失。

FP32 变 INT8，菜谱从 400 页缩到 100 页，主厨背起来快得多，代价是味道（预测精度）有轻微损失。选哪种携带方式，得看菜谱多厚、出菜要多快。

S′=S×b′b\displaystyle S' = S \times \frac{b'}{b}
量化公式就像“按字号缩印菜谱”：字号（位宽）从 32 号缩到 8 号，页数（体积）等比缩小。
  1. S——原始模型大小未压缩时模型的参数总量，单位 MB。
    S\displaystyle S
  2. b——原始位宽FP32 表示每个参数占 32 位。
    b\displaystyle b
  3. b'——量化后位宽INT8 表示每个参数只占 8 位。
    b′\displaystyle b'
  4. S'——量化后大小压缩之后的模型体积。
    S′\displaystyle S'

冷启动攻坚

深夜食堂最尴尬的时刻永远是第一单：主厨睡眼惺忪，穿围裙 30 秒、点灶 20 秒、背菜谱 40 秒——第一道菜总是最慢的。这在云上有个专门的名字：冷启动（Cold Start）。

冷启动的本质，是为这次调用“从零准备一个新环境”：创建容器、初始化运行时、加载依赖、加载模型。不同语言的“起床速度”差异巨大：Java 启动很慢，Python 和 Node.js 快得多；部署包越大、模型越重，起床越慢。对 AI 推理而言，模型加载往往是冷启动延迟的最大头。

攻坚手段有四招。第一是预留并发（Provisioned Concurrency）：提前让指定数量的容器“穿好围裙”候着，冷启动归零，但要按预留量付费。第二是精简依赖：剔除 Layer 里用不上的包。第三是懒加载：把模型加载推迟到函数内部首次使用时，缩短调用链路上的无效初始化。第四是选择轻运行时：Node/Python 比 Java 轻一个数量级。

预留并发相当于“凌晨也雇两个主厨穿着围裙打盹”，成本高一些，但客人的第一单不再等得心焦。优化完冷启动，就该算总账了——出菜速度与成本怎么平衡。

E[T]=Pcold×Tcold+(1−Pcold)×Twarm\displaystyle E[T] = P_{\text{cold}} \times T_{\text{cold}} + (1 - P_{\text{cold}}) \times T_{\text{warm}}
平均出菜时间 = 撞上冷启动的概率 × 冷启动耗时 + 撞上温热容器的概率 × 温热耗时。
  1. E[T]——平均出菜时间长期观察下单次调用的平均延迟，也叫数学期望。
    E[T]\displaystyle E[T]
  2. P_cold——冷启动概率这一次调用撞上新容器的概率。
    Pcold\displaystyle P_{\text{cold}}
  3. T_cold——冷启动耗时容器全新，必须走完整套初始化流程。
    Tcold\displaystyle T_{\text{cold}}
  4. T_warm——温热耗时容器被复用，醒来即可直接推理。
    Twarm\displaystyle T_{\text{warm}}

性能成本调优

深夜食堂老板发现一个反直觉的现象：灶台火力调大一倍，每道菜的烹饪时间反而大幅缩短，客人满意了，燃气费却没涨多少。在 Lambda 里，“灶台火力”就是内存配置。

Lambda 的内存从 128MB 到 10GB，CPU 与内存按比例分配（大约每 1GB 内存配 0.125 vCPU）。对 CPU 密集型的推理任务，加大内存往往让耗时非线性下降——因为火旺了，计算和内存带宽都更快。于是出现一个常见结果：内存翻 4 倍，耗时降到原来的四分之一，单次成本（内存 × 耗时）几乎不变，但延迟体验大幅提升。

调优的标准流程是：以 256MB、512MB、1GB、2GB、4GB 等档位跑压测，画“内存-延迟-成本”曲线，找到拐点；用 P95/P99 延迟分析判断瓶颈是冷启动还是推理本身；配合自动扩缩容应对流量峰谷；再用 CloudWatch 与 Lambda Power Tuning 工具自动寻优。

老板最后发现：256MB 跑 0.8 秒，和 1GB 跑 0.2 秒，单客成本一模一样（都是 0.2 GB-秒），但后者出菜快 4 倍。这就是“同样的钱，买更快的灶台”。

C1C2=M1×D1M2×D2\displaystyle \frac{C_1}{C_2} = \frac{M_1 \times D_1}{M_2 \times D_2}
两次配置的单次成本之比，等于“内存 × 耗时”之比——它告诉你，换灶台到底是省钱还是费钱。
  1. C_1——配置 1 的单次成本某一档内存下的单次调用费用。
    C1\displaystyle C_1
  2. M_1、D_1——配置 1 的内存与耗时分别以 GB 和秒为单位。
    M1, D1\displaystyle M_1,\ D_1
  3. C_2——配置 2 的单次成本另一档内存下的单次调用费用。
    M2, D2\displaystyle M_2,\ D_2

部署实践案例

所有准备就绪，深夜食堂要正式开业了：先备齐食材与餐具（环境准备），让主厨试做几道菜（代码编写与本地测试），挂上招牌接受订单（部署上线），最后紧盯每桌评价（监控告警）。

以图像识别为例：用户把图片上传到 S3，PutObject 事件就像按响的铜铃，触发 Lambda；函数读取图片、预处理成张量，加载图像分类模型进行推理，返回类别标签与置信度；结果写入 DynamoDB，可疑图片再触发 SNS 消息通知审核员。整个流程无人值守、按张计费。

部署落地有五步：先配 IAM 角色（坚持最小权限原则，厨房钥匙只给需要的厨师）；用 SAM 或 Serverless Framework 编排资源；本地用 sam local invoke 模拟触发；通过 CI/CD 流水线自动推送部署；最后用 CloudWatch 日志与 X-Ray 追踪延迟。同时必须设计“重试 + 幂等”：处理前记录 request_id，已处理过的事件直接返回，避免重复推理造成重复扣费。

假设单次成功率只有 90%，重试 3 次后最终成功率能到 99.9%——就像菜没端好可以重新做一道，保证客人最终吃上。至此，从按铃开火、背菜谱、定规矩到正式营业，一整条 Serverless AI 推理之路完整闭环。

P=1−(1−p)k\displaystyle P = 1 - (1 - p)^k
重试公式：单次成功率 p，最多重试 k 次，最终成功率 P——菜没端好可以重做，但要保证最后能端上来。
  1. p——单次尝试成功率一次推理成功返回的概率。
    p\displaystyle p
  2. k——重试次数失败后最多再尝试的次数。
    k\displaystyle k
  3. P——最终成功率尝试 k 次后至少成功一次的总概率。
    P\displaystyle P

AI 应用场景

电商图片自动审核

阶段：模型部署与在线推理

解决的问题：传统做法是租一台常驻 GPU 服务器跑图像分类，闲时烧钱、峰值排队；用 Lambda 后，用户每上传一张图片触发一次推理，按张计费，大促流量暴涨时平台自动“加灶台”，流量回落自动收摊。

具体案例：电商平台把商品图上传到 S3，PutObject 事件触发 Lambda，函数读取图片并加载一个 INT8 量化后的 60MB 图像分类模型（权重放 S3、依赖放 Layer），输出“违禁/正常”标签与置信度，写入 DynamoDB；违规商品自动触发 SNS 通知审核员介入。上线后推理成本下降约 70%。

智能客服意图识别

阶段：在线推理服务

解决的问题：客服 API 流量峰谷波动大，固定部署 10 个实例晚上大量闲置；Lambda 按请求量自动扩缩容，空闲时零成本，高峰期不打烊。

具体案例：某银行客服机器人使用 Lambda 部署一个 BERT-Tiny 量化版文本分类模型，API Gateway 接收用户消息触发推理，模型判断“转账/查询/投诉”意图并提取槽位；用预留并发 20 个实例兜底冷启动，P95 延迟从 1.2 秒降到 400 毫秒。

物联网设备异常检测

阶段：流式数据处理与推理

解决的问题：海量设备每秒上报数据，传统方式需要常驻流处理集群，成本高且运维重；Lambda 由 IoT Core 事件直接触发，每个事件做一次轻量推理，空闲时完全不收费。

具体案例：工厂传感器数据经 AWS IoT Core 转发到 Lambda，函数执行一个 5MB 的 Isolation Forest 异常检测模型，判断设备状态；异常事件写入时序数据库并触发告警，模型从 Lambda 层加载，保证 200ms 内完成响应，帮助工厂提前发现设备故障。

Python 演示

python50 行
# -*- coding: utf-8 -*-"""本地模拟 AWS Lambda 上的 AI 推理：冷启动 + 轻量文本分类"""import jsonimport time VOCAB = {"慢": -1, "贵": -1, "差": -1, "快": 1, "好": 1, "赞": 1}THRESHOLD = 0.0_is_cold = True_model_loaded = False  def load_model():    """第一次调用模拟冷启动：加载权重耗时约 0.8 秒"""    global _is_cold, _model_loaded    if not _model_loaded:        time.sleep(0.8)        _model_loaded = True        _is_cold = True    else:        _is_cold = False    return _is_cold  def predict(text):    score = sum(VOCAB.get(ch, 0.0) for ch in text)    return ("positive" if score >= THRESHOLD else "negative"), score  def lambda_handler(event, context):    """AWS Lambda 入口：处理 API Gateway 或 S3 触发的 JSON 事件"""    t0 = time.time()    cold = load_model()    label, score = predict(event.get("text", ""))    return {        "statusCode": 200,        "body": json.dumps({            "label": label,            "score": score,            "cold": cold,            "latency_ms": round((time.time() - t0) * 1000, 1)        })    }  if __name__ == "__main__":    for text in ["你好赞", "太慢了", "服务真好"]:        resp = lambda_handler({"text": text}, None)        body = json.loads(resp["body"])        print("%s -> %s cold=%s latency=%sms" %              (text, body["label"], body["cold"], body["latency_ms"]))
目的：在本地模拟 AWS Lambda 上 AI 推理的完整生命周期——首次调用经历冷启动（模型加载 0.8 秒），后续调用立即命中缓存，返回标签、置信度与耗时。
  1. def lambda_handler(event, context):Lambda 的固定入口签名，AWS 用这个函数作为“接单台”。
  2. cold = load_model()模拟冷启动：首次加载权重耗时长，容器复用后不再重复加载。
  3. score = sum(VOCAB.get(ch, 0.0) for ch in text)轻量“模型”：查情感词典逐字累加得分。
  4. "latency_ms": round((time.time() - t0) * 1000, 1)记录本次调用延迟，用于观测冷/热调用的巨大差异。
  5. if __name__ == "__main__":本地直接运行测试循环，模拟 AWS 控制台多次触发函数。

常见误区

误区以为 Serverless 意味着完全不需要服务器，代码在“云端空气”里运行，所以部署 AI 模型也无需考虑任何机器资源。

正解Serverless 的真正含义是“你不用管理服务器”，底层依然是真实的容器与虚拟机——Lambda 底层运行在一批托管的 EC2 实例上。云厂商负责供应、打补丁、扩容，你只管代码与配置。就像深夜食堂不是没有灶台，只是灶台由别人照看，按铃才点火。

为何常见：名字里的“Serverless“字面误导，加上 AWS 控制台”无需配置服务器”的宣传语，容易让人误以为物理服务器不存在。

误区以为 Lambda 函数像常驻服务一样，返回响应后进程仍在内存中运行，随时可以访问全局变量和缓存。

正解函数返回后，执行环境会被冻结甚至回收；再次调用是“恢复”一个被复用的容器，而不是继续运行你上次的进程。全局变量、进程内缓存只在容器存活期间有效，且不能保证下一次请求一定落在同一实例上——所以不要把状态放在函数内存里，要放 DynamoDB 或 ElastiCache。

为何常见：习惯了传统 Web 服务的“进程常驻”模型，容易把“容器复用”误解为“我的进程一直在跑”。

误区内存翻倍，单价就翻倍，费用一定翻倍，所以默认用最小内存档位省钱。

正解Lambda 的内存与 CPU 线性挂钩，内存增大后推理耗时往往显著下降。单次成本 = 内存(GB) × 耗时（秒） × 单价，只要耗时降幅超过内存增幅，总成本反而下降。正确的做法是测“内存-延迟-成本”曲线，找拐点。

为何常见：只盯着单价看，忽略了成本公式里“耗时”这个会同步变化的变量。

误区冷启动是 Serverless 的“原罪”，响应慢只能怪平台，没什么办法。

正解预留并发可以让指定数量的容器提前初始化好、保持温热，彻底消除这批容器的冷启动；配合精简依赖、轻量运行时、模型懒加载，P95 延迟能大幅下降。代价只是预留期间的少量费用，但换来稳定延迟，对生产级 AI 服务非常值得。

为何常见：把“默认有冷启动”当成“必然有冷启动”，不知道预留并发这个付费解法。

误区训练好的 .h5/.pt 模型文件直接打进 ZIP 部署包，上传 S3 就完事。

正解ZIP 部署包有硬限制（解压前 50MB、解压后 250MB），装不下大模型；Layer 可以共享依赖但同样有体积上限；数百 MB 以上的模型应放 S3 运行期加载，或改用容器镜像（最大 10GB）。部署前先量一量“菜谱厚度”，再决定用哪种携带方式。

为何常见：小项目成功经验惯性放大，没碰到体积上限之前，不会主动设计部署策略。

面试题

Q1. 关于 AWS Lambda 的计费方式，下面哪项描述正确？

单选题 · easy

  • A.无论是否调用都收月租
  • B.只按调用次数与时长计费← 正确答案
  • C.按服务器台数固定计费
  • D.免费额度永远花不完

答案：B。Lambda 按“调用次数 + 内存×时长（GB-秒）”计费，未调用时零成本——就像深夜食堂没订单就不开火不收钱。A、C 是传统服务器的计费方式，D 错误，因为免费额度有限。

Q2. Lambda 的“冷启动”主要发生在什么时候？

单选题 · easy

  • A.每次调用都会发生
  • B.新容器初始化之时← 正确答案
  • C.模型参数更新之时
  • D.网络连接断开之时

答案：B。冷启动发生在新容器被创建、运行时初始化、模型加载的阶段；容器创建过并被复用时就是“温热”状态。A 错误，同一容器多次调用不会冷启动；C、D 与容器生命周期无关。

Q3. 一个文本分类模型需要加载 500MB 权重，最合适的部署方式是？

单选题 · mid

  • A.全部打进ZIP部署包
  • B.使用容器镜像部署← 正确答案
  • C.忽略大小直接部署
  • D.写入系统环境变量

答案：B。ZIP 部署包解压后上限 250MB，500MB 权重会超限；容器镜像支持更大体积（最大 10GB），是大型模型的标准做法。环境变量有 4KB 大小的限制，D 完全不可行。

Q4. 估算函数所需并发数时，若 λ 表示每秒请求数、T 表示平均耗时，应使用哪个公式？

单选题 · mid

  • A.N = λ × T← 正确答案
  • B.N = λ ÷ T
  • C.N = T ÷ λ
  • D.N = λ + T

答案：A。这是 Little 定律 N = λ × T：每秒来 10 个订单、每单做 2 秒，就需要 20 个灶台（并发）同时工作才不排队。其余选项的量纲都不正确。

Q5. 以下哪些方法可以有效降低 Lambda 的冷启动延迟？

多选题 · mid

  • A.配置预留并发容量← 正确答案
  • B.改用 Java 运行时
  • C.精简依赖并懒加载模型← 正确答案
  • D.从 S3 边下载边推理

答案：AC。预留并发让容器提前初始化完毕，冷启动归零；精简依赖、懒加载缩短启动路径上的工作时长。Java 运行时启动慢，反而加剧冷启动；D 边下边加载会增加首包延迟，应预取到层或镜像中。

Q6. 某函数内存 256MB 时平均耗时 800ms，调到 1024MB 后耗时降到 200ms，单价按每 GB-秒计算，单次成本如何变化？

单选题 · hard

  • A.成本基本不变← 正确答案
  • B.成本涨为两倍
  • C.成本涨为三倍
  • D.成本涨为四倍

答案：A。原成本 = 0.25GB × 0.8s = 0.2 GB-秒；新成本 = 1GB × 0.2s = 0.2 GB-秒，二者相等。内存翻 4 倍但耗时降到四分之一，总成本不变，延迟却大幅改善——这就是“用同样的钱买更快的灶台”。

Q7. 关于 Lambda 的幂等性设计，以下说法正确的是？

多选题 · hard

  • A.相同事件可能被多次重试← 正确答案
  • B.推理结果应可重复执行← 正确答案
  • C.幂等设计只管读操作
  • D.写库前先查处理状态← 正确答案

答案：ABD。Lambda 为保证可靠投递会重试失败事件，所以带副作用的处理必须幂等：记录 request_id、写库前先查询是否已处理、重复请求直接返回。C 错误，恰恰是写操作（扣费、写库、发通知）最需要幂等保护。

Q8. Lambda 层（Layer）的主要作用是什么？

单选题 · easy

  • A.提高单次函数运行速度
  • B.在多个函数间共享依赖← 正确答案
  • C.延长函数的超时上限
  • D.省去训练模型的过程

答案：B。Layer 就像深夜食堂的共享调料架，把 numpy、torch 等公共依赖放到一层，多个函数复用，避免每个部署包重复打包。它不改变函数的运行速度、超时上限，更与模型训练无关。

Q9. 预留并发（Provisioned Concurrency）相对于按需并发的核心优势是？

单选题 · mid

  • A.彻底消除全部网络延迟
  • B.预初始化容器消除冷启动← 正确答案
  • C.完全不产生任何计费
  • D.突破十五分钟超时上限

答案：B。预留并发提前创建并初始化好指定数量的容器，请求到达时直接复用，冷启动消失。但它按预留量计费（有成本），也不改变网络延迟和 900 秒的超时上限，A、C、D 均错误。

Q10. 某图片分类服务的 P95 延迟持续超标，正确的排查与优化思路包括？

多选题 · extreme

  • A.先排查冷启动占比再优化← 正确答案
  • B.内存调到最大必然最优
  • C.测不同内存下的延迟拐点← 正确答案
  • D.延迟超标只怪模型太慢

答案：AC。P95 超标要先拆延迟构成——冷启动占比高用预留并发解决，推理耗时占比高则调内存或换更小模型；内存需实测拐点而非越大越好，B 想当然。D 是甩锅，未分析冷启动、网络与重试策略，均不可取。