发生了什么变化
这篇指南以前把 TabbyAPI 写成 EXL2 的服务端，现在它已经不是了。TabbyAPI 如今自称是 ExLlamaV3 的官方 API 服务端，依赖里只安装 exllamav3，README 列出的支持模型类型只有两种：EXL3（推荐）和普通的 FP16/BF16 权重。EXL2 背后的库 ExLlamaV2 本身也已归档。TabbyAPI 没有发布任何版本标签，所以本站没法给你指出一个仍能加载 EXL2 的版本。如果你手上是 EXL2 模型，可选方案在最后一节。
开始之前，以及它不适合做什么
一张 NVIDIA 显卡：TabbyAPI 安装的 ExLlamaV3 wheel 是 CUDA 版本。Python 3.10 或更新版本。还有项目自己的定位，在你基于它搭东西之前值得一读 —— README 写着它是"a hobby project made for a small amount of users"，"not meant to run on production servers"。它很适合在自己的机器上把一个 EXL3 模型放到 OpenAI 风格的 API 后面；如果是别人要依赖的服务，请用 vLLM。
git clone https://github.com/theroyallab/tabbyAPI
cd tabbyAPI
# Linux (start.bat on Windows) — sets up the environment, uses uv if installed
./start.sh下载模型并在配置里指向它
启动脚本自带下载器。EXL3 仓库把每个比特率放在单独的分支上，所以要用 --revision 指定；下面的例子取自 TabbyAPI 自己的文档。模型以目录形式放在 models/ 下。config.yml 是可选的 —— 只有想改默认值时才需要从 config_sample.yml 复制一份。真正要紧的是：model_name（启动时加载哪个目录）和 max_seq_len，它决定分配多少 KV 缓存，也就决定了模型能不能加载。network 一节默认是 127.0.0.1、端口 5000。
./start.sh download turboderp/Qwen2.5-VL-7B-Instruct-exl3 --revision 4.0bpw
cp config_sample.yml config.yml
# then in config.yml:
# model:
# model_dir: models
# model_name: Qwen2.5-VL-7B-Instruct-exl3
# max_seq_len: 8192或者用容器运行
TabbyAPI 发布了 CUDA 镜像。请保留 README 里的共享内存参数：ExLlamaV3 在张量并行和 CPU MoE 卸载时会用到 /dev/shm，Docker 默认的 64 MiB 太小，加载时会报出提到这个上限的错误。README 原本的命令会把 5000 端口发布到所有网卡上；除非你确实要对外开放，否则请绑定到 127.0.0.1。
docker run --gpus all --shm-size=8g --name tabbyapi \
-p 127.0.0.1:5000:5000 \
-v /path/to/models:/app/models \
ghcr.io/theroyallab/tabbyapi:latest确认它真的跑起来了
鉴权默认开启：首次启动时 TabbyAPI 会把生成的密钥写进 api_tokens.yml，请求需要在 x-api-key 头里带上它，或者用 Authorization: Bearer。health 接口不需要模型做任何计算就能应答；models 接口告诉你加载了什么。加载时盯着 nvidia-smi —— 一个本该装得下却加载失败的模型，几乎都是 max_seq_len 的问题。
curl http://127.0.0.1:5000/health
KEY=$(grep api_key api_tokens.yml | cut -d" " -f2)
curl http://127.0.0.1:5000/v1/models -H "x-api-key: $KEY"
nvidia-smi --query-gpu=memory.used --format=csv -l 1数字大概是什么样
本站没有实测过 EXL3，模型索引里也没有 EXL3 构建，所以这里不给速度和体积数字，也不拿 EXL2 的数字来充数。成本结构和其他服务端一样：权重大小由你下载的比特率决定，KV 缓存随 max_seq_len 增长。想知道大概的量级，可以在显存计算器里按相近每权重比特数的 GGUF 或 EXL2 档位查这个模型 —— 并把它当作近似，而不是实测。
如果你手上是 EXL2 模型
三个实在的选择。用 ExLlamaV2 自带的聊天脚本在本机运行 —— 本站的 ExLlamaV2 指南讲的就是这个，它仍然能用，只是没有仍在维护的 API 服务端。用 llama.cpp 跑同一个模型的 GGUF 版本，它有 OpenAI 兼容的服务端，并且一直在活跃开发；本索引的每个模型都提供 GGUF 构建。或者，如果发布者做了这个模型的 EXL3 版本，就换成 EXL3，然后按上面的方法用 TabbyAPI。
常见问题
TabbyAPI 还能加载 EXL2 模型吗？
当前版本不能。它的依赖只安装 exllamav3，README 列出的支持模型类型是 EXL3 和 FP16/BF16。TabbyAPI 没有发布版本标签，所以也没有一个已知仍能加载 EXL2 的版本可以固定使用。EXL2 可以用 ExLlamaV2 自带的脚本在本机运行，或者用 llama.cpp 跑这个模型的 GGUF 版本来提供服务。
TabbyAPI 适合生产环境吗？
它自己的 README 说不适合："a hobby project made for a small amount of users… not meant to run on production servers." 这是维护者的原话，值得尊重。可以用它让编辑器插件和桌面客户端在你自己的机器上调用模型；如果你要搭的是一项服务，请用 vLLM。
为什么 TabbyAPI 容器加载模型会失败？
最常见的原因是共享内存。ExLlamaV3 把张量并行和 CPU MoE 卸载的缓冲区放在 /dev/shm 里，而 Docker 默认只给容器 64 MiB —— TabbyAPI 的文档写明，这时加载会失败，并报出提到这个上限的错误。按 README 的做法用 --shm-size=8g 启动容器，或者用 --ipc=host。如果不是这个原因，就调低 max_seq_len。
这篇指南用到了什么
- 对应推荐
- 24GB 能跑的最好的本地大模型
接下来
看看 🟢 RTX 4090 还能跑哪些模型反向查询 —— 24GB、8192 上下文，按质量排序它真的跑起来了吗？
复制命令并不等于它能用，所以站内只在这里问一次。除了你的这个回答之外，不收集任何东西。