模型加载与卸载策略：懒加载、预加载、热加载、模型版本管理

模型加载这事儿，看着简单，其实坑不少。我刚开始做推理系统时，觉得不就是把模型从磁盘读到内存嘛，有啥好讲的？结果第一次上线就被打脸了——几十个模型同时加载，内存直接爆掉，服务挂了半小时。

从那以后，我养成了一个习惯：把模型的生命周期管理，当成和代码架构一样重要的事情来对待。说白了，模型就是你的数据资产，怎么加载、怎么卸载、怎么切换版本，直接决定了系统的稳定性和响应速度。

一、懒加载：用到才加载，省资源

懒加载，顾名思义，就是等到真正需要推理的时候，才把模型加载到内存里。这个策略最适合那种「模型很多，但每个模型调用频率不高」的场景。

举个例子，你有个推荐系统，后台挂了 50 个模型，但用户一次请求可能只用到其中 3 个。如果全部预加载，内存占用直接起飞。懒加载就能解决这个问题。

class LazyModelLoader:
    def __init__(self):
        self._models = {}  # 模型注册表
        self._lock = threading.Lock()
    
    def get_model(self, model_name: str):
        # 先检查是否已加载
        if model_name not in self._models:
            with self._lock:
                # 双重检查，防止并发重复加载
                if model_name not in self._models:
                    self._load_model(model_name)
        return self._models[model_name]
    
    def _load_model(self, model_name):
        # 实际加载逻辑
        print(f"懒加载模型: {model_name}")
        self._models[model_name] = torch.jit.load(f"{model_name}.pt")

嗯，这里要注意一个细节：并发场景下的重复加载问题。我见过有人不加锁，结果高并发时同一个模型被加载了十几次，内存直接炸了。上面的代码用了双重检查锁，算是比较稳妥的做法。

二、预加载：提前准备好，零等待

预加载和懒加载正好相反——服务启动时就把所有模型加载好。用户请求进来，直接推理，没有任何加载延迟。

这个策略适合什么场景？说白了，就是那些对延迟极其敏感的服务。比如在线广告、实时风控，多等 100 毫秒可能就损失一笔订单。

class PreloadManager:
    def __init__(self, model_list: list):
        self.models = {}
        # 启动时一次性加载所有模型
        for model_name in model_list:
            self._load_model(model_name)
    
    def _load_model(self, model_name):
        print(f"预加载模型: {model_name}")
        self.models[model_name] = torch.jit.load(f"{model_name}.pt")
    
    def infer(self, model_name, input_data):
        model = self.models.get(model_name)
        if model is None:
            raise ValueError(f"模型 {model_name} 未预加载")
        return model(input_data)

但是，预加载也有代价。我记得有一次，项目上线前忘了评估模型总大小，结果 20 个模型加起来占了 30GB 显存，服务器直接 OOM 了。所以预加载前，一定要算清楚：你的内存/显存够不够装下所有模型？

三、热加载：不停机更新模型

热加载，也叫动态加载，指的是在不重启服务的情况下，替换或新增模型。这个能力在线上环境特别重要——你总不能每次更新模型都发版重启吧？

热加载的核心机制是版本号 + 原子替换。我一般用一个字典来维护当前活跃的模型版本，更新时直接替换字典里的引用，保证推理线程不会读到半残的模型。

class HotReloadManager:
    def __init__(self):
        self._active_models = {}  # 当前活跃模型
        self._lock = threading.RWMutex()
    
    def reload_model(self, model_name: str, new_version: str):
        # 1. 加载新版本到临时变量
        new_model = self._load_model_from_disk(model_name, new_version)
        
        # 2. 原子替换（加写锁）
        with self._lock.write_lock():
            self._active_models[model_name] = new_model
        
        print(f"热加载完成: {model_name} -> 版本 {new_version}")
    
    def infer(self, model_name, input_data):
        # 3. 推理时加读锁，保证读到的是完整模型
        with self._lock.read_lock():
            model = self._active_models.get(model_name)
        return model(input_data)

这里有个关键点：读写锁。推理线程只加读锁，可以并发执行；更新模型时加写锁，阻塞所有推理。这样既保证了性能，又保证了数据一致性。

四、模型版本管理：别让你的模型变成一团乱麻

模型版本管理，说白了就是给每个模型打上标签，知道它是什么时候训练的、用什么数据、效果如何。没有版本管理，你很快就会发现：线上跑的模型到底是哪个版本？没人说得清。

我建议用语义化版本号，比如 v1.2.3：

• 主版本号：模型架构变了（比如从 ResNet50 换成 ResNet101）
• 次版本号：训练数据或超参数变了
• 修订号：小修小补，比如重新训练了一次

除了版本号，还要记录元信息。我一般用一个 JSON 文件来管理：

{
  "model_name": "text_classifier",
  "version": "v2.1.0",
  "created_at": "2024-03-15",
  "framework": "pytorch",
  "input_shape": [1, 512],
  "accuracy": 0.967,
  "training_data": "corpus_v3",
  "checksum": "a1b2c3d4e5f6..."
}

有了这些信息，你就能快速定位问题。比如线上效果变差了，查一下版本号，发现是昨天刚更新的 v2.1.0，再对比一下元信息里的 accuracy，发现确实比 v2.0.0 低了 0.5%。那就果断回滚。

五、三种策略怎么选？一张表说清楚

策略	适用场景	优点	缺点
懒加载	模型多、调用少、内存紧张	节省内存，启动快	首次推理延迟高
预加载	延迟敏感、模型数量可控	零等待，响应快	占用大量内存/显存
热加载	需要不停机更新模型	高可用，灵活	实现复杂，需处理并发

你想想看，实际项目中往往不是只用一种策略。我做过一个系统，核心模型用预加载保证低延迟，长尾模型用懒加载节省资源，同时所有模型都支持热加载以便快速迭代。三种策略组合使用，效果最好。

好了，模型加载与卸载的策略就聊到这儿。下一章我们聊聊推理引擎的选择和调优，那个更有意思。