ExLlamaV2

提到本地跑大模型，多数人直接上通用框架或图形化工具。但在「多卡、长上下文、量化模型、要 OpenAI 兼容接口」这个组合下，ExLlamaV2 配 TabbyAPI 往往更省显存、启动更快。本文记录一套可用的多卡配置。 多卡启动要调哪些关键参数？ 用 TabbyAPI 起服务，核心是指定模型路径、量化档位、GPU 切分方式。多卡时指定模型，并把不同层映射到不同卡。长上下文场景重点调三个：最大序列长度按业务设，位置编码缩放配合长上下文，缓存类型选分页或低比特量化以省 KV 显存。 它凭什么比别的框架更省显存？ ExLlamaV2 的长上下文实现对 KV cache 做了量化与分页，同样的长上下文，它吃的显存常比裸跑高精度 KV 小一截。代价是吞吐略低于高端数据中心卡上的顶级框架表现——但在消费级多卡上，这点差距远不如「能装下」重要。 它和高吞吐框架怎么分工？ 经验是：对外高并发在线服务用高吞吐框架；本地开发、长文档分析、个人多卡工作站用 ExLlamaV2 加 TabbyAPI，显存优先。两套都提供 OpenAI 兼容接口，上层代码不用改，切换只换一个 base URL。 自动兜底有什么隐患？ TabbyAPI 的量化格式支持有边界，不是所有 GGUF 都能直接跑，遇到加载报错先查模型文件是否兼容。另外，多卡切分时别让某一张卡承担过多层，用显存监控观察满载分布，必要时手动调整切分比例。 什么场景别勉强用它？ 它省显存的另一面是吞吐天花板。如果你要对外同时扛几百路并发，这套本地方案会先顶不住，那是数据中心级框架的主场。它的最佳定位是：一个人或小团队，在一块到几块消费级显卡上，处理一批可以容忍几秒延迟的长文档任务。把它塞进对延迟敏感的高并发产品，等于用错了工具。另外，第一次在新卡上跑通后，记一份参数备忘——哪张卡切几层、最大上下文设多少，下次直接抄，别重新踩一遍坑。 消费级多卡到底该选哪套？ 工具没有绝对优劣，只有场景匹配。在消费级多卡上跑长上下文，ExLlamaV2 加 TabbyAPI 是被低估的一套——它不会给你最高的每秒 token 数，但常常是「唯一能把这个模型塞进显存」的那条路。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：ExLlamaV2多卡