我最近接了个多模态推理任务一口气要同时跑五个模型一个对话用的LLM、一个图像分类的ViT、一个语音识别、一个embedding向量化外加一个RAG检索模型。手头显卡显存只有12G根本装不下逼得我借了一台128G统一内存的机器。结果发现光有内存根本不够用五个模型同时加载内存直接爆炸来回卸载几次之后上下文全丢了进程还互相打架。最后实在受不了自己写了一个模型管理器来统一调度过程中踩了整整七个坑。这篇文章就把这些坑和背后的内存管理、进程调度、上下文保持的细节全部记录成文希望后来者能少走弯路。1. 项目整体设计与思路拆解1.1 为什么需要同时管五个模型先说背景。我做的这个需求是典型的多模型协同任务用户发来一段音频我先用语音识别转成文字然后丢给LLM分析意图再从知识库里做embedding检索最后把检索结果和上下文一起交给LLM生成答案。中途还有图像识别模型介入。这五个模型如果按顺序串行跑延迟高到没法用如果全部常驻内存又会被资源限制卡死。传统方案是买一块大显存卡比如A100 80G但成本太高而且难买。统一内存的设备就不一样比如某些带128G统一内存的工作站CPU和GPU共享同一块物理内存模型权重可以直接放进内存按需加载到计算单元执行。理论上有128G五个平均7B参数的模型用FP16实数大约14G一个五个就是70G加上context和中间计算勉强够住。但如果全用FP16内存余量很小稍微开个长上下文的对话就爆。所以我当时的第一反应是不能一股脑全加载得有个东西来控制每个模型的生命周期。有人会问为什么不用现成的框架我试过大多都是加载就常驻或者手动一个个启动没有针对多模型统一内存这个场景做精细调度。有的工具能管单个模型但想跨模型做资源仲裁、上下文持久化、自动换入换出就力不从心了。于是决定自己写。1.2 管理器到底该管什么一个模型管理器表面上是启动/停止模型但真正难的是透明管理内存和状态。我拆解成四件事模型生命周期何时加载、何时卸载按需加载还是常驻。上下文持久化LLM对话历史、embedding索引等状态不能因为卸载就丢失。内存水位监控实时统计每个模型占了多少内存总内存剩余多少接近阈值时自动驱逐低优先级模型。进程间通信管理器向模型发指令模型返回结果必须异步、带超时不能因为模型推理慢就卡死整个系统。整个架构我用了一个Python守护进程作为中心调度器每个模型跑在独立的子进程里调度器和每个模型进程之间通过HTTP端点通信。选择子进程而不是线程是为了隔离内存某个模型崩溃了不会牵连其他模型。通信用HTTP是因为简单直观每个模型内置一个轻量服务接收加载、推理、卸载的指令。1.3 为什么统一内存下更需要主动管理统一内存的好处是弹性但坏处也是弹性。你一旦多个进程同时申请内存系统不会替你安排先后优先级只会OOM内存溢出或者频繁swap。管理器的核心就是做资源仲裁本质上和操作系统的内存管理是一样的逻辑只不过粒度从页面变成了模型。我用八个字概括设计原则按需加载优先级换出。高优先级的LLM常驻因为它每轮对话都要用到embedding模型虽然用得多但可以接受毫秒级唤醒所以用惰性加载语音识别和图像识别是低频任务用完立刻卸载。这样把内存占用峰值压下来五个模型才能在一台128G机器上平稳共存。2. 统一内存与模型加载的核心细节2.1 统一内存和传统显存到底差在哪很多人对统一内存的认知还停留在内存大就是好其实忽略了带宽和分配策略的差别。传统显卡是独立显存容量小但带宽极高比如RTX 4090有24G显存带宽超过1TB/s。统一内存是把一部分物理内存共享给CPU和GPU带宽取决于内存类型通常低于独立显存但容量大得多。这意味着在统一内存上跑模型模型权重是放在内存里的计算时按需搬到计算单元。如果内存总带宽是800GB/s一个7B模型即使只有4G量化大小也要花十几毫秒才能完整搬到GPU核心里。更关键的是如果五个模型同时读取权重带宽会互相抢导致每个模型都变慢。所以我当时给自己定了个规矩同一时间只有一个大模型在做推理其他模型只保持权重在内存里不参与计算。这样至少保证推理峰值带宽够用。管理器里我加了一个计算锁——整个系统同一时刻只允许一个GPU绑定的模型执行多出来的请求排队。实测下来这个机制最有效既保住了响应速度又避免带宽竞争。2.2 内存分配策略常驻、惰性加载与换出光有锁还不够还得设计什么时候加载、卸载。我参考操作系统的页面换出算法做了一套简化版高优先级常驻LLM主模型。它占最大内存而且频繁推理不能卸载。我干脆在启动管理器时预加载把权重锁在内存里。中优先级惰性加载embedding模型。它轻量只有几百MB但调用频繁。第一次调用时加载之后常驻。低优先级用完即走语音识别、图像分类、RAG检索模型。这些是任务触发式使用每次推理完直接卸载释放给系统。但这个策略有个坑我一会儿会细说卸载模型后会丢掉上下文所以我在卸载前必须把模型内部状态序列化到磁盘。当时我为了实现这一步给每个模型写了一个save_state和load_state接口在卸载时调用加载时再恢复算是整个管理器最核心的代码。2.3 隐藏的内存杀手context长度和推理引擎开销权重占用只是冰山一角。推理过程中真正吃内存的是KV cache也就是LLM的注意力缓存。一个7B模型即使权重只有4G如果context长到32KKV cache可以轻松多占好几G。五个模型如果各自开了很长的context内存总占用会远超权重总和。我建议每个模型在管理器里都有一个独立的上下文预算。LLM只给8K context给到32K就是灾难。embedding模型没有这个负担可以随意。语音和图像模型推理时临时分配推理完释放。管理器在启动时读一个配置文件限制每个模型的max_context_length算好内存上限超过就拒绝请求而不是让系统去OOM。3. 管理器实操实现过程3.1 整体架构的落地细节我用的技术栈很简单Python 3.11 psutil FastAPI。psutil负责监控每个进程的内存和CPUFastAPI给每个模型起一个HTTP服务。调度器本身也是一个FastAPI服务对外暴露统一接口比如/run/llm、/run/embedding。每个模型进程启动时传入PID和一个端口号调度器把端口号登记在内存表里。进程内部实现一个标准接口/health、/infer、/load_state、/save_state。调度器和模型之间所有请求都加超时超时就标记为不可用自动重启。这样一个简单的架构就是一个小型模型管理平台只是没有UI全用API。我自己主要用命令行来调试。3.2 核心代码模型进程控制下面是一段简化版的关键代码展示如何启动和停止一个子进程import psutil import subprocess class ModelRunner: def __init__(self, model_name, command, port): self.model_name model_name self.command command self.port port self.proc None def start(self): self.proc subprocess.Popen( self.command f --port {self.port}, shellTrue, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL, ) self.wait_ready() def stop(self): if self.proc and self.proc.poll() is None: self.proc.terminate() try: self.proc.wait(timeout5) except subprocess.TimeoutExpired: self.proc.kill() def memory_usage_mb(self): if self.proc: return psutil.Process(self.proc.pid).memory_info().rss / 1024 / 1024 return 0这里有个小技巧terminate发SIGTERMkill发SIGKILL。正常情况下先发SIGTERM让模型有机会保存状态5秒内没退出再强制杀。如果不这样模型进程会留下僵尸进程内存不释放。3.3 调度器怎么排优先级调度器维护一个优先级队列。每当收到推理请求先查对应模型是否在内存里如果在就直接转发如果不在看内存剩余量够不够不够就释放低优先级模型腾出空间再启动。这个逻辑用伪代码表示是def ensure_loaded(model_executor): while can_launch(model_executor) False: victim find_lowest_priority_loaded_model() if victim is None: raise OOM unload(victim) model_executor.start()这里can_launch会估算模型需要的内存清单里每个模型都标注了max_memory_estimate。这个估算值必须比实际略大否则一次加载就爆。我最后是根据实测数据填的而不是只看权重大小。3.4 基准内存测试结果我把五个模型跑了一遍记录实际占用情况模型参数规模量化版本内存峰值LLM主模型7Bint8量化约7.4GBembedding0.4BFP16约1.1GB语音识别1.5Bint8约2.8GB图像分类0.3BFP16约1.2GBRAG检索0.6BFP16约1.6GB总计常驻权重约14.1GB加上每个模型的运行开销峰值时总占用拉到40GB左右还有很大余量。这说明五个模型同时常驻是行得通的但前提是正确管理KV cache和临时buffer。如果不做预算开满context全都可能爆。4. 七个坑的完整实录4.1 坑一模型加载后内存直接爆掉现象一开始我用FP16权重直接加载加了两个模型就提示内存不足整个系统卡死连终端都敲不动。原因两个层面。一是权重本身就大7B的FP16有14GB五个加起来70GB看起来128G够但系统还要留内存给文件缓存和进程开销实际可用可能只有110G二是模型加载时加载工具会先把权重从磁盘复制到内存同时为推理临时开辟buffer瞬时峰值可能翻倍。解决全部改成int8或4bit量化权重直接减半或减到四分之一。我自己是LLM用int8语音用int8其他小模型保持FP16。更重要的是加载模型前先算当前进程的总内存和模型估算值如果加在一起超过物理内存的90%直接拒绝加载宁可返回错误也不拖垮系统。提示任何模型管理器都必须有内存预算这个机制否则再大的内存都白搭。4.2 坑二上下文被清空对话续不上现象LLM跑得好好的为了加载embedding模型我把它卸载了等LLM再启动之前的对话历史全丢了。原因LLM的上下文都保存在进程内存里卸载进程就意味着内存释放。我当时压根没做状态保存以为模型权重在磁盘重新加载回来自然就恢复显然太天真。解决给每个模型写一个save_state接口在卸载前把对话历史、kv cache可选序列化到磁盘。加载时读回。KV cache恢复不能一概而论因为不同模型的cache结构不同所以我做了两个版本一个序列化对话历史重开后重新传输history缺点是慢另一个直接序列化cache快但只对同一模型同一量化版本有效。我最后选了历史重新计算方式因为更通用。4.3 坑三进程间通信卡死现象调度器发一个推理请求给模型半天没响应然后整个系统的其他请求也全部排队像死锁了一样。原因模型推理本身可能耗时几十秒甚至几分钟调度器的HTTP请求是同步等待的模型进程处理请求时本身是单线程新请求没法处理两边互相等待调度器也就卡住了。解决所有通信改成异步。用FastAPI自身支持异步接口加上asyncio.timeout实现超时控制。超时后立即标记模型为busy把请求返回给用户而不是一直等。后来我还给每个模型加了独立的请求队列队列满就直接丢弃并返回错误。4.4 坑四内存碎片和swap频繁现象明明内存总量还剩不少但系统变得特别慢跑模型像是开了虚拟机一样。原因反复加载卸载模型内存是一块块申请的容易产生碎片。更重要的是内存碎片导致系统频繁把不活跃页面换到磁盘做swap统一内存机器的swap操作非常慢每次都几GB的来回性能彻底崩掉。解决两个措施。一是管理器维护固定的临时卸载区同一时间最多卸载一个模型减少碎片二是监控swap用量一旦连续几秒swap量超过阈值调度器主动清理低优先级模型而非等内存不够才动作。实测下来swappiness参数也可以调低比如写到/proc/sys/vm/swappiness但这不是我主推的做法。4.5 坑五模型格式生态不兼容现象不同模型用了不同推理引擎。LLM用的是llama.cpp生成的GGUF格式embedding模型用PyTorch原生权重语音识别用的另一种格式。调度器必须适配多种加载逻辑代码瞬间膨胀而且某个引擎如果升级了格式整个管理器就要跟着改。原因工业界没有一个统一模型文件格式每个框架都有自己的保存方式。解决我写了一个模型抽象层把所有格式的加载、推理、保存封装成统一接口。接口后面是具体实现比如GGUF模型走LlamaAdapterPyTorch模型走Transformers。管理器只跟抽象层打交道。这个开销不小但值得后续加新模型都不用改调度逻辑。4.6 坑六CPU和GPU调度互相拖累现象把LLM绑在GPU上跑同时把语音识别丢到CPU结果两边都变慢GPU利用率上不去CPU利用率也低。原因统一内存下CPU和GPU共享同一个内存带宽。CPU密集访问内存时会抢占带宽GPU推理也在抢带宽互相干扰。再加上进程绑核没设置好模型在核心间乱跳缓存不命中性能进一步恶化。解决我给每个模型都定义了device字段和CPU亲和性。指定GPU的模型用CUDA_VISIBLE_DEVICES锁定GPU指定CPU的模型用taskset绑定到特定核心数。最重要的是把计算锁机制做严同一时间只能有一个重模型在推理其他模型即使常驻也在等待状态。这样带宽冲突被大幅缓解。4.7 坑七管理器崩溃后留下满地的僵尸进程现象有一次调度器自己因为一个异常崩溃了等我重新启动时发现之前启动的几个模型进程还活着占着几百GB内存又得一个个手动kill。原因管理器用subprocess.Popen启动子进程如果父进程突然退出子进程不会自动退出会变成孤儿进程继续存在。解决最简单的办法是在启动管理器时先清理旧进程。我在调度器启动入口加了一个进程清扫函数读取一个记录PID的文件逐个检查是否存活是就杀掉。同时每个模型进程启动时都保存PID到文件卸载时删除。进一步我还加了文件锁防止两个调度器同时管理同一批进程。5. 避坑工具箱与经验总结5.1 实用工具清单如果你也要做类似的多模型管理我建议这几个工具先备好psutilPython库监控内存、CPU、进程状态比直接解析/proc好用多了。nvidia-smisysctl检查GPU使用率和内存情况。在统一内存机器上我主要是看free -g和vmstat。taskset绑定进程到特定CPU核心减少调度抖动。uvloop如果你用Python写异步通信把事件循环换成uvloop性能提升不少。vector 模型推理超时每个模型都要设置自己的超时时间LLM给60秒embedding给5秒语音给30秒不能一刀切。5.2 初始化配置参考我的配置文件长这样可以抄作业models: llm: command: python run_llm.py port: 8001 max_context_length: 4096 estimated_memory_bytes: 8GB priority: high device: gpu embedding: command: python run_embedding.py port: 8002 estimated_memory_bytes: 1.5GB priority: medium device: cpu asr: command: python run_asr.py port: 8003 estimated_memory_bytes: 3GB priority: low device: cpu这里的estimated_memory_bytes要和基准测试对齐宁高勿低。我一开始按权重大小填结果吃过大亏后来改成实测值加20%缓冲。5.3 个人体会踩完这七个坑我的感觉是统一内存机器给了你装得下的信心但真正难点在于管得住。128G听着大但多个模型加上上下文、临时buffer分分钟可以把它吃干净。一个负责任的模型管理器一定要有内存预算、状态持久化、异步通信、进程清理这四板斧缺一个都会出大事。如果只是偶尔跑两个模型用现成的工具确实方便。但只要模型数量上到三个以上或者你有跨模型协同的需求手写一个调度器是值得的。我这套管理器大概写了五百行代码不算多但它能让我对每一个进程的生死都有办法再也不用担心半夜模型挂了还占着内存。最后再分享一个小技巧调试的时候记得给每个模型进程写详细的日志文件包括每次加载、推理、卸载的耗时和内存变化。很多坑都是靠日志才定位到的尤其是内存碎片和swap问题没有日志你根本猜不到原因。