Question 1

text-generation-webui 到底需要多大显存？

Accepted Answer

界面本身几乎不占显存，占显存的是模型权重加上预分配的 KV cache。GGUF 的经验公式很好用：Q4_K_M 约等于参数量 ×0.6GB，Q8_0 约 ×1.06，bf16 是 ×2。所以 8B Q4_K_M 约 5GB、32B 约 20GB、70B 约 43GB。KV 那部分别忘了——文档明确写着 cache 是预分配的，--ctx-size 开多大就先扣多少，把 --cache-type 从 fp16 换成 q8_0 能直接省掉一半。照这个算完再选卡：NexGPU 上 24GB 到 141GB 一共 75 种型号，RTX 3090 $0.193、RTX 5090 32GB $0.723、A100 80GB $0.824、H200 141GB $6.660，按秒计费，选错了停掉换一张就行。

Question 2

和 vLLM、Ollama 比，什么时候该用 text-generation-webui？

Accepted Answer

分工其实很清楚。vLLM 是给高并发线上服务用的，PagedAttention、连续批处理，一个后端做到极致；Ollama 胜在傻瓜化。text-generation-webui 的独门优势是五种后端共存、不重启热切换，加上 Notebook 续写、对话分叉、参数面板全暴露、LoRA 就在同一个界面里训——它是一台单人工作台，适合选型对比和调参阶段。NexGPU 的 2,000+ 预置镜像里 PyTorch 和 vLLM 都有，你完全可以先在 textgen 里把模型和量化档位比出来，再原地换个实例上 vLLM 做压测。

Question 3

加载模型报 unknown model architecture 怎么办？

Accepted Answer

这是仓库 issue 区最常见的一类，比如有人反馈 'unknown model architecture: minimax-m3'。原因是每个 release 内置的 llama.cpp 是钉死在某个 commit 上的——v4.9 就是 e947228，新架构合并进上游之后，要等下一个 textgen 版本才会跟上。三条出路：等新 release、自己替换 llama.cpp 二进制、或者直接换 Transformers 加载器（它跟着 transformers 库走，通常最早支持新架构，但要按 bf16 或 4-bit 重新估显存）。后一条路显存需求会跳一个档，在 NexGPU 上临时换成 A100 PCIE 80GB $0.824/卡·时 顶一晚，比重装环境快得多。

Question 4

能在里面训 LoRA 吗？需要什么卡？

Accepted Answer

能，Training 标签页支持多轮对话数据集和 raw text 两种格式，走 Transformers 路径。但要注意 portable 包是带 --portable 启动的，训练功能被显式关闭了，必须改用 start_linux.sh 那套完整安装（conda + Python 3.13）。显存上，训练要同时装下权重、梯度和优化器状态，通常是纯推理的三到四倍，7B 级别的 LoRA 建议直接上 80GB 卡。NexGPU 的 H100 SXM 80GB 是 $3.582/卡·时，A100 SXM4 80GB $1.088/卡·时，跑完就停，不用为了几个小时的微调去申请配额。

Question 5

老教程里的 ExLlamaV2、AutoGPTQ 加载器怎么找不到了？

Accepted Answer

因为它们已经不在当前的加载器列表里了。v4.9 的 Model 标签页只有五个：llama.cpp、ik_llama.cpp、Transformers、ExLlamav3_HF / ExLlamav3、TensorRT-LLM。网上 2024 年那批 GPTQ 教程基本都过期了，EXL3 是 ExLlamaV3 的新格式，和 EXL2 权重不通用。如果你手里全是老量化文件，最稳的迁移路径是转去 GGUF 走 llama.cpp。这类试错在按秒计费的机器上做最合适——NexGPU Tesla T4 16GB 只要 $0.298/卡·时，够你把格式兼容性一个个验证过去。

Question 6

部署在云上，怎么安全地远程访问 Web UI 和 API？

Accepted Answer

v4.9 已经把 CORS 默认收紧到只允许 localhost，并修掉了角色名路径穿越的问题，所以最佳实践就是不要对公网开放。用 SSH 端口转发把 7860 和 5000 拉回本地，是零配置又零暴露面的做法。团队共享的话，--listen 配 --gradio-auth 用户名:密码，API 侧配 --api-key，两层都别省。NexGPU 的实例默认提供 SSH、Jupyter、网页终端和 REST API 四种入口，51 个国家和地区可以就近选节点降低延迟，遇到打不通的情况在 Telegram 上找我们，中英文都行，没有工单排队。

版本	参数量	显存	上下文	说明
llama.cpp（GGUF）	1B–70B 单卡主力	Q4_K_M ≈ 参数量 ×0.6GB：8B ≈ 5GB / 32B ≈ 20GB / 70B ≈ 43GB；Q8_0 ≈ ×1.06	--ctx-size 默认 0，自动读 GGUF 元数据里的原生窗口	v4.9 内置 commit e947228。--gpu-layers 默认 -1 自动分配，装不下会自动往内存溢；--cache-type 支持 fp16 / q8_0 / q4_0，KV 是预分配的，上下文开多大就先扣掉多少显存。
ik_llama.cpp（ik- 独立包）	大 MoE 与 CPU 混合卸载	与同名 GGUF 同量级，但 --cpu-moe / --n-cpu-moe 把专家层搬到系统内存后，显存占用可以压到权重的一小半	同 GGUF	v4.9 内置 commit 40254a5，单独打包成 textgen-portable-ik-4.9-* 资产。跑 100B+ 的稀疏 MoE 时比主线 llama.cpp 更省显存，代价是速度受内存带宽拖累。
ExLlamaV3 / ExLlamav3_HF（EXL3）	8B–70B 纯显存推理	按 bpw 直算：[email protected] ≈ 16GB，[email protected] ≈ 26GB，再加 KV	cache 支持 fp16 与 q2–q8，K/V 可分别指定位宽	v4.9 内置 ExLlamaV3 0.0.34。纯 GPU 路线，没有 CPU 卸载这条后路，装不下就是加载失败。ExLlamav3（非 _HF）版本额外支持推测解码与多模态模型。
Transformers（bf16 / bitsandbytes）	1B–13B 全精度，或 4-bit / 8-bit 量化	bf16 = 参数量 ×2GB（8B ≈ 16GB）；load_in_4bit 后 8B ≈ 6GB，配合 use_double_quant 再降一点	受 --ctx-size 与模型原生窗口双重约束	唯一能接 LoRA 训练的路线，也是模型架构覆盖最广的一条。当 llama.cpp 还没合并某个新架构时，先用 Transformers 顶上，往往是唯一可行解。
TensorRT-LLM	预编译 engine	取决于编译时选定的精度与 batch / seq 上限，编译完就固定了	在编译 engine 阶段写死	NVIDIA 专用、单卡吞吐最高，但换模型、换上下文长度都要重新编译引擎。适合参数已经定死、准备长期常驻的服务，不适合边试边调。

text-generation-webui 本地部署：五种后端、一个界面，显存到底该怎么算

五种加载器与量化格式：先搞清楚谁吃多少显存

按你要跑的模型选卡

在 NexGPU 上部署 text-generation-webui

开一台带 GPU 的实例

装 text-generation-webui

把模型丢进 user_data/models/ 并带 API 启动

用 SSH 隧道访问，别开 --share

一个月要花多少：算给你看

常见问题