FastAPI DI在AI服务中没那么神，分层架构才是关键

确实，DI在模型生命周期管理上确实有优势，但我自己也是被嵌套依赖坑过，调试的时候一层层追Depends()真的头大。现在我也更倾向于分层架构，把依赖注入当成胶水而不是骨架，控制层只做路由转发，业务逻辑交给service层，这样变更起来清爽很多。不过想问下，你们在分层里怎么处理模型预热和多卡负载的？我试过把模型加载放在service初始化里，但显存回收还是有点蛋疼。

这帖子说到点子上了。FastAPI的DI在AI场景里确实容易走火入魔，尤其是AsyncGenerator管理模型生命周期这点，很多人只看到了Depends的糖衣，没注意到底层GC和显存回收的坑。我去年有个OCR服务就是纯DI堆出来的，结果模型加载依赖里套了个预处理依赖，预处理又依赖配置中心，调试请求链路时pdb进去直接懵了，层层嵌套的生成器栈帧根本理不清。

分层架构这块我深有同感，不过我想补充一个实际落地时的痛点：在AI服务里，Controller-Service-Repository这种传统三层架构，其实很难直接套用。因为AI推理往往需要跨层共享上下文，比如一个batch里同时做特征提取和结果后处理，如果严格按照分层，Service层调用Repository层拿模型权重时，还得把tokenizer、预处理参数一起传下去，接口会变得非常臃肿。我现在的做法是引入一个InferenceContext对象，用contextvars在请求链路里透传，分层只做职责划分，不强制隔离数据流。

另外想问下，你在生产项目里是怎么处理DI和分层之间的边界模糊的？比如模型预热这种全局状态，是放到Service层的单例里，还是通过DI的lifespan事件来管理？我试过两种方案，前者在横向扩展时容易出竞态，后者又会让DI层变得太重，目前还没找到特别优雅的解法。

这个观察挺到位的，特别是“注入地狱”那段，我在几个中大型推理服务里也遇到过。FastAPI的DI在简单场景下确实清爽，但一旦依赖链超过三层，光靠Depends()去维护DAG式的初始化顺序，调试时真的要命——尤其是AI服务里常有模型加载、tokenizer初始化、缓存预热这些带副作用的依赖，稍不注意就会在启动时静默失败，或者出现隐式的单例冲突。

你提到的AsyncGenerator管理模型生命周期这个点，其实很多吹DI的人都没意识到这才是真正的价值所在。FastAPI的lifespan配合yield出来的依赖，能做到按需加载和清理，这对GPU显存这种不可压缩资源来说比什么解耦都重要。但分层架构确实能把这种技术细节和对业务逻辑的侵入隔离开，Controller只负责HTTP语义，Service层处理编排，Repository或者叫Model层去管那些重量级对象的生命周期，这样就算哪天把FastAPI换成别的框架，核心的模型管理和推理逻辑还能复用。

我自己的经验是，在AI服务里，DI更适合用在那些轻量、无状态的组件上，比如配置读取、日志注入、简单的数据校验。真正跟模型、显存、批处理策略打交道的部分，还是得用明确的工厂模式或者注册表模式来做，测试起来也更可控。顺便问一下，你那个分层架构里，Service层和Repository层之间的边界是怎么划的？是让Repository只做模型推理的纯调用，还是也承担了部分预处理/后处理的职责？这块我总觉得不同项目里的划分标准差挺大的。

确实，DI用过头了真容易变成注入地狱，特别是模型加载这种重量级操作，嵌套个五六层依赖，查个报错都得从头捋到尾。分层架构好在边界清晰，Service层管业务逻辑，Repository层管数据交互，DI只做轻量级的胶水粘合，这样压力测试和性能调优时定位问题快得多。

话说你那分层架构里，模型生命周期管理是放在哪一层？我试过放到Service层做懒加载，但多线程下偶尔会出状态混乱，有没有什么经验分享下？

说实话，你点到的“注入地狱”这块我太有同感了。之前我们团队在搞多模态服务时，依赖链一深，一个请求的DI解析时间甚至比模型推理时间还长，最后不得不靠分层架构把业务逻辑和资源管理拆开，才把调试成本降下来。另外想问下，你那边在分层时，对于GPU显存的池化管理是放在Service层还是单独抽了个ResourceManager？