资讯 · 改写稿
一张显卡跑多个本地大模型：GPU 调度器解决什么问题
结论先给：本地多个模型共用一张卡，瓶颈往往不是算力，而是显存。光靠「装得下就装、闲了就卸」会互相挤崩；加一层调度器（优先级 + 显存记账 + 准入控制），比再买一张卡更划算。
本地跑 AI 的人很快会撞到同一个问题：想同时开着聊天、写代码的 agent、一个在后台啃文档的索引器，还有一个读屏的小模型。它们都想用同一张显卡。
来源描述的场景很具体：只有一张 RTX 4060 Ti，16 GB 显存。默认做法会出问题——如果每个应用各起一个 llama-server，它们彼此不知道对方存在，显存够时就平均分，一旦耗尽就有进程崩掉；而 Ollama 虽然会「装得下就加载、空闲就卸载」，却是按到达顺序服务，并不知道「聊天」比「索引」更该优先。
GridCore 的思路：只做调度，不做推理
GridCore 把自己定位成「控制平面」而不是又一个推理引擎。真正的推理仍由 llama.cpp 完成，每个模型一个 llama-server 进程；GridCore 负责启动或停止这些进程、接收 OpenAI 格式的请求，并决定此刻谁用 GPU。
- 优先级队列：interactive（交互）＞ background（后台）＞ batch（批处理）。
- 显存记账：先从 GGUF 估算，再按实测校正。
- 模型常驻策略：pinned / hot / cold，按成本决定驱逐。
- 准入控制：决定这次请求是直接派发、加载、驱逐还是排队等待。
应用侧几乎无感：接口地址照旧，配置里的别名让客户端继续发 "model": "gpt-4o"，实际后面是本地模型。要额外告诉它的，只是这次请求属于哪一类——可以放在请求头（X-GridCore-Class）、请求体的字段，或模型名后缀里。
硬件账本：4 个模型怎么塞进 16GB
来源给出的常驻组合是：gemma4-12b（hot，8.3 GB）、gemma4-e4b（cold，4.0 GB）、gemma4-e2b（cold，2.8 GB）、nomic-embed（pinned，0.4 GB）。
本站计算——把这四块加起来是 15.5 GB，占 16 GB 卡的约 96.9%，只剩约 0.5 GB 余量。也就是说，这张卡几乎没有再塞第五个模型的空间；一旦新请求需要新模型，就只能靠驱逐或排队来解决。这正解释了为什么「显存记账 + 准入控制」是这类调度器的核心，而不是可选项。
和「router 模式」的差别
来源提到，llama-server 从 2025 年 12 月起也有了 router 模式，同样是一模型一进程、也会加载卸载。区别在于它只按「最近最少使用」驱逐，不做显存记账、没有优先级，也不区分一个交互请求和一个批处理请求谁更该等。对单人多任务的本机场景，这些差别恰恰是体感最明显的部分。
如果你还在纠结「本地跑」和「买订阅」哪个划算，可以先读本站的 本地大模型 vs 订阅。
以为显存够就万事大吉——没有优先级时，后台任务会把交互请求挤到排队。
把调度器当成推理引擎——它不跑模型，真正干活的是 llama.cpp。
忽略显存记账，直接按「模型数量」限制并发，容易触发显存不足。
自检清单
常见问题
一张显卡能同时跑多个本地大模型吗？
可以，但瓶颈通常在显存而非算力。来源的例子是 4 个模型合计 15.5 GB，占满一张 16 GB 的 RTX 4060 Ti，几乎不留余量。
GridCore 是推理引擎吗？
不是。它只做调度（控制平面），推理由 llama.cpp 完成，每个模型一个 llama-server 进程，GridCore 负责启停、队列与显存分配。
优先级是怎么区分的？
来源给出三档：interactive ＞ background ＞ batch。请求可以通过请求头、请求体字段或模型名后缀声明自己属于哪一档，缺省视为 interactive。
它和 llama-server 的 router 模式有何不同？
router 模式按最近最少使用驱逐，不做显存记账、没有优先级；GridCore 增加了显存记账、优先级队列和准入控制。
来源参考
以上为外部来源；本文为 RefHub 用自己的结构重写，事实以来源页为准，价格与政策会变，请回源核对当日。
下一步：想比较本地模型和订阅的成本，读 本地大模型 vs 订阅；把模型塞进 U 盘的踩坑记录见 七个模型塞进 U 盘。