先搞清问题启动 vs 运行时咱们得先分清两个阶段这就像餐厅开业冷启动应用启动相当于餐厅第一天开业。你不能让客人在门口等厨师把所有菜都做一遍尝过才开门。我们的目标是越快开门越好。热路径请求处理客人点单后后厨开始炒菜。这时候追求的是单道菜的出菜速度和质量。很多兄弟包括当初的我会把加载模型这种备菜工作直接扔在全局变量里在应用启动时执行。结果就是开业仪式巨长无比。你可能会问那我不用的时候不加载用的时候再加载不就行了Bingo这就是懒加载Lazy Loading的核心思想把耗时初始化推迟到第一次真正需要它的时候。但在Web服务里怎么优雅地实现它并且管理它的生命周期呢这就轮到lifespan出场了。 核心武器Lifespan 事件管理器在FastAPI实际上是背后的Starlette中lifespan是一个上下文管理器它让你能精确控制应用启动前和关闭后该做什么。官方文档可能讲得有点抽象我打个比方它就像是你服务的私人管家。服务上线前startup管家帮你预热游泳池、打开花园灯服务下线时shutdown管家帮你关灯、放掉泳池水收拾得干干净净。重点来了这个管家出现的时间点比你所有接口的dependencies都要早这意味着你可以在lifespan里准备好一些工厂或者连接池但不一定非要立刻加载所有重型资源。from contextlib import asynccontextmanager from fastapi import FastAPI import asyncio # 这是一个假的重型模型 class HeavyModel: def __init__(self): self.loaded False async def load(self): print(开始加载模型...这可能需要很久) await asyncio.sleep(5) # 模拟加载耗时 self.loaded True print(模型加载完毕) async def predict(self, text: str): if not self.loaded: await self.load() # 懒加载发生在这里 return f预测结果 for: {text} asynccontextmanager async def lifespan(app: FastAPI): # Startup: 这里我们只初始化模型容器但不加载模型本身 print(应用启动中...) model_container {model: HeavyModel()} app.state.model model_container[model] yield model_container # 这里的model_container会注入到请求的app.state中 # Shutdown: 清理工作比如关闭模型、释放GPU内存等 print(应用关闭中执行清理...) app.state.model None app FastAPI(lifespanlifespan) app.get(/generate) async def generate(prompt: str): # 首次请求时才会真正触发模型加载 result await app.state.model.predict(prompt) return {result: result}看上面代码HeavyModel在lifespan的启动阶段只是被实例化了并没有调用耗时的load()方法。真正的加载发生在第一个请求调用predict时。这样做的好处是什么1️⃣启动速度飞起你的服务几乎可以秒级就绪通过健康检查。2️⃣资源按需使用如果某个Pod一直没收到相关请求模型就永远不会加载节省了宝贵的GPU内存。3️⃣生命周期可控你依然在lifespan的掌控之中可以在关闭时优雅地释放资源。⚠️ 但是小心这个天坑懒加载虽好但直接用在生产环境可能会让第一个用户成为大冤种。想象一下用户第一次请求要白屏等待模型加载的几十秒体验极差而且这个请求很可能超时。所以更优的生产级实践是懒加载 异步预热。我们可以在lifespan启动完成后悄悄地、异步地开始加载模型而不是阻塞启动过程。asynccontextmanager async def lifespan(app: FastAPI): # Startup print(应用启动中...) model HeavyModel() app.state.model model # **关键技巧创建一个后台任务异步预热** async def _warm_up(): try: await model.load() print(模型预热完成) except Exception as e: print(f模型预热失败: {e}) # 不await让它后台运行 asyncio.create_task(_warm_up()) yield # Shutdown print(应用关闭中...)这样服务能立刻启动并响应健康检查。模型在后台默默加载加载完成后才真正提供预测服务。对于加载期间的请求你可以根据业务决定是返回一个服务预热中的友好提示还是用队列让其等待。 更工程化的封装与注意事项在实际项目中我们不会把逻辑全写lifespan主函数里。我的习惯是封装一个ModelManager单例类来统一管理加载状态、重试和并发安全。再说几个容易翻车的点并发请求时的重复加载如果第一个请求A触发加载没完请求B又来了要确保不会初始化两个模型实例把内存撑爆。记得用锁asyncio.Lock或者检查状态变量。健康检查的设计你的/health端点应该反映服务的真实状态。可以设计成{status: warming_up}{status: ready}。这样K8s的readinessProbe可以在模型就绪后才导入流量。关闭时的优雅终止如果模型正在推理直接关闭可能会导致GPU内存泄漏或数据错误。在lifespan的shutdown阶段最好设置一个标志位让正在处理的请求完成并拒绝新请求。