llama.cpp 多模型

本地同时跑两三个模型，常见卡点是显存被吃满、端口互相顶、客户端不知道该连哪个地址。这篇按「服务怎么起、显存怎么排、调用怎么分」三步给出可照抄的清单，并说明单卡和多卡下哪些做法不适用。

本地想同时挂两三个模型，最常见的三个坑：显存被吃满、新服务起不来而旧进程还在、客户端不知道连哪个地址。这三件事其实不是同一个问题，得拆开处理——服务怎么摆、显存怎么排、调用怎么分。

先把预期放正：llama.cpp 的 llama-server 一个进程就加载一份权重，所谓多模型，本质是多个进程各占一个端口，或者同一个进程反复换载。它没有那种「配置里写个列表就自动路由」的机制。下面的清单按「起服务、排显存、分调用」三步走，最后给一个排查顺序，照着对就行。

先想清楚：为什么一个进程管不住多个模型

一个 llama-server 实例在启动时就把权重读进显存，生命周期内不会再换模型。想多模型并行，要么同时开多个实例，要么用完一个停掉再起另一个。换载不是零成本：旧模型的显存不释放，新模型就可能起不来，或者悄悄退到 CPU 上跑，速度掉一个量级你还以为是机器不行。

• 量化档位不同的模型，显存占用差别挺大，混跑前先按站内部署测算核对你手里这几个的余量
• 模型越多，空闲显存越紧，并发一上来先崩的往往不是最忙的那个
• 什么情况下不适用：如果你一天就切换一两次模型，手动换载比常驻省资源，没必要养多个进程

服务怎么摆：端口、常驻还是按需

最省心的做法是「一个模型一个端口」，每个 llama-server 用不同的 --port 起，客户端靠 base URL 区分。别指望同一个端口自动认出你要哪个模型，它不会。启动脚本里把端口、权重路径、上下文长度写清楚，跟下面这行差不多就行。

llama-server -m /models/a.gguf --port 8081 -ngl 99 &\nllama-server -m /models/b.gguf --port 8082 -ngl 99 &

1. 先定常驻名单把调用最频繁的一两个模型设成常驻，其余按需启动；常驻数量以启动后显存还剩一截为准，不留余量后面一定出事
2. 起服务前先停旧的按需模型用脚本管理，启动前先确认旧进程真的退出了（看进程表，不只看日志），再起新的，避免两份权重同时占卡
3. 多卡时显式分卡用设备指定参数把模型分到不同卡上；同一张卡塞两个大模型基本直接失败，别在这上面浪费时间

调用侧怎么分：路由表与客户端配置

模型多了以后，麻烦会从服务端转到客户端：每个脚本各填一个地址，换端口就得全改一遍。解决办法是维护一张路由表，把模型名映射到端口和用途，客户端和脚本都按表查，不靠记忆。再往前一步，对外只暴露一个统一入口，用网关或简单反向代理按模型名转发，换模型时只改一处。

• 接口层加上超时和重试，模型正在加载时返回排队提示，别让请求干等几分钟最后超时
• 网关不是必须的：单机、单用户、调几个脚本的场景，一张表加固定端口就够了
• 判断口径：调用量和延迟要求说不清的时候，先去站内测速页量出基线，再决定要不要上网关

出问题时的排查顺序

多模型跑出问题，别一上来就怀疑模型文件。按下面这个顺序走，多数情况在前两步就能定位。

1. 先查显存看上一个进程是不是真的退出了，显存有没有被占着；进程还在但日志没报错，是最常见的假象
2. 再查端口确认端口没冲突，服务确实监听在你以为的地址上，别出现起了 8082 客户端连 8081 的情况
3. 查路由表客户端发来的模型名是否落在表里，大小写、路径前缀都算，网关规则写错也会表现成连不上
4. 最后怀疑权重同一模型单独跑得起来、多开跑不起来，八成还是显存或端口；权重格式问题通常单独跑也报错

多模型部署的稳定性，八成取决于起服务前那一眼显存余量，而不是模型本身。