本地大模型新手常见问题

Question 1

能不能跑一个模型，到底只看显存吗？

Accepted Answer

看三样：显存决定装不装得下，内存决定装不下时能不能凑合，算力决定跑得多快。显存是唯一没有替代品的。

装模型像往抽屉里放东西：权重（模型参数本身）必须先放，剩下的空间才给上下文用。显存满了，框架就把一部分层挪到内存里，这叫 offload——能跑，但内存带宽只有显存的 1/10 到 1/15，速度会断崖式下跌。

所以判断顺序是：① 权重大小 vs 可用显存 ② 剩下的显存够不够你要的上下文 ③ 卡的带宽决定每秒能出多少字。显存不够，加钱也换不到速度；带宽不够，只是慢，不是不能用。

本站容量表里写的『可用显存』不等于显卡标称容量：Windows 桌面会先吃掉 0.5–1.5GB，所以 16G 卡按 88% 即约 14.1G 算，Linux 按 95% 算。很多『别人 16G 能跑我不能跑』的差别就在这里。

Question 2

量化是什么？Q4_K_M、Q8_0、IQ3 这些名字什么意思？

Accepted Answer

量化就是把每个参数用更少的比特存下来，模型变小变快，质量按档位往下掉。Q8 几乎无损，Q4 是主流甜点位，Q3 已经能听出变笨。

模型权重原始是 16 比特（FP16/BF16）。量化到 4 比特，文件直接小 3/4，显存读取量也小 3/4，所以速度大约同比例变快——这是本地跑大模型最重要的一个免费午餐。

名字里的规律：Q4/Q5/Q6/Q8 是数字越大越接近原始质量；后缀 _K_M / _K_S 是同代的两种规模（M 稍大稍好）；IQ2/IQ3/IQ4 是新一代的『智能量化』，同样比特下质量更好但计算稍慢；MXFP4 是 OpenAI gpt-oss 的官方原生格式。

换算成显存有个粗算式：权重 GB ≈ 参数量(B) × 每参数字节数 ÷ 8。本站用的每参数字节数：Q8_0 是 8.5、Q6_K 是 6.56、Q5_K_M 是 5.6、Q4_K_M 是 4.8、IQ4_XS 是 4.25、IQ3_XXS 是 3.02。注意 Q8_0 是 8.5 而不是 8.0——多出来的是每块的缩放信息，这就是『14B 跑 Q8 要 14.9G』而不是 14G 的原因。

新手常犯的错是『显存装得下就选最大量化』。更实用的顺序是：先保证留出你要的上下文，再在剩下的空间里挑质量最高的档。

Question 3

上下文（ctx）到底是什么？8K 能装多少字？

Accepted Answer

上下文是模型一次能『看见』的总字数预算，输入和它的回答共用这个预算。8K token 大约相当于中文 4000–5500 字。

token 是模型的最小单位，不完全等于字。粗略对照：英文 1 token ≈ 4 个字母 ≈ 0.75 个词；中文 1 个汉字大约 1.2–1.8 token（不同模型的词表差别很大，中文模型通常更省）。所以 8K 上下文放中文大约 4000–5500 字，放英文大约 6000 词。

关键容易被忽略的一点：这 8K 是『你说的话 + 系统提示词 + 它已经答过的内容 + 它正在生成的内容』的总和。多轮聊天里，上下文是一路涨上去的，涨满就会截断最早的内容或者报错。这就是『明明装得下，聊到二十轮就崩』的成因。

本站表格里 8K 上下文那一列写的是『这 8192 个 token 吃多少显存』，不是『8K 能装多少字』——后者就是上面那 4000–5500 字。另外还要扣掉模板开销：聊天格式包装、系统提示词，通常 200–500 token（本站数据里这一项标了『未核实』，是估算）。

还有一点：模型本体有原生上限。Qwen3 系列是 40960（约 40K），GLM-4-9B 是 32768，Phi-4 只有 16384；Gemma 3、Llama 3.1、gpt-oss、Seed-OSS 是 128K 起。显存够 ≠ 能开那么大，把 -c 填超过原生上限属于超纲使用，质量不保证。

Question 4

KV cache 是什么？为什么上下文那么吃显存？

Accepted Answer

KV cache 是为了不重复计算而存下来的历史注意力数据，它随上下文线性增长，长对话和长文档的显存大户就是它。

模型生成每个新字都要回看前面所有字。为了避免每步都重算一遍，框架把前面各层的 Key/Value 张量存住，这就是 KV cache。它的大小 = 2 × 层数 × KV头数 × 每头维度 × 精度字节 × 上下文长度，所以是严格线性的：上下文翻倍，KV 翻倍。

精确算法和参数量关系不大，真正决定的是层数和 KV 头数。本站按 config.json 实算出来的对照：Qwen3-32B（64 层 / 8 KV 头 / 头维 128）4K 上下文正好 1.0G；Qwen3-8B 和 Qwen3-4B 都是 36 层 8 头，所以 KV 完全一样，都是 0.56G/4K；GLM-4-9B 只有 2 个 KV 头，4K 只要 0.16G；而 gpt-oss-20B 一半层用 128 token 的滑窗，4K 只要 0.10G。

反例很有教育意义：如果按参数量线性猜 KV，会把 GLM-4-9B 猜成 0.5G（高估 3.2 倍）、把 gpt-oss 猜成 0.5G（高估 5 倍）、把 Qwen3-4B 猜成 0.25G（低估 2.3 倍）。这三个错会直接把『我这张 12G 卡能开多大上下文』的结论改写成另一个故事。

省 KV 有两个开关：① KV 量化（llama.cpp 的 -ctk q8_0 / q4_0），Q8 几乎不掉质量就能省一半，Q4 省四分之三；② 选带滑窗架构的模型，比如 Gemma 3 系列 48 层里只有 8 层要全量 KV。本站容量表顶部给了 KV 精度的切换控件，切一下就能看到结论怎么变。

Question 5

tok/s 是多少才够用？我是不是需要很快？

Accepted Answer

中文阅读速度约 5–8 tok/s，所以 15 tok/s 以上就跟得上你阅读；25–40 是舒服，60 以上你反而读不过来。只有批量生成才需要追求高速。

tok/s 是解码阶段每秒吐出的 token 数，也就是『一个字一个字往外蹦』的速度。要区分两个数：首 token 延迟（TTFT，按回车到第一个字出现）由提示词处理速度决定，读长文档时它可能等你十几秒，但一旦开始吐字就正常了。

参考线：8–12 tok/s 能用于偶尔问答，你会觉得慢；15–25 日常聊天舒服；30–60 阅读跟不上但适合多轮；60+ 只在批量跑数据、生成代码文件、做离线任务时有意义。

速度主要由『每 token 需要从显存读多少字节』决定，所以带宽是主瓶颈：公式大致是 tok/s ≈ 带宽 × 效率系数 ÷ 每 token 读取字节数。本站给 5080（960GB/s）和 4060Ti（288GB/s）跑同一个 8B Q4 的估算差 3 倍多，就是这个原因，而不是前者『算力更强所以快』。

注意本站对单流解码设了经验上限（带宽 ≥800GB/s 的卡设 200 tok/s，其余 140）。因为纯带宽公式对小模型会算出 400–500 这种不可能的数——实际会被采样、反分词、层间串行拖住。这个上限是工程估值，等实测数据回填后会继续校准。

Question 6

稠密模型和 MoE 有什么区别？为什么 30B-A3B 可能比 14B 还快？

Accepted Answer

MoE 每次只激活一小部分参数，所以它『显存按总量算、速度按激活量算』。30B-A3B 每 token 只读约 3B 权重，能比 14B 稠密模型快 3 倍。

稠密（dense）模型每一层都要全部参数参与计算。MoE（混合专家）把每层的 FFN 拆成很多个『专家』，路由器每个 token 只挑几个专家算。名字里的 A3B / A22B 就是 Active 激活参数量：Qwen3-30B-A3B 总参数 30B、每 token 激活 3B；Qwen3-235B-A22B 总 235B、激活 22B。

关键差别在算速度时用哪个数：显存占用必须按总参数（所有专家都得在机器里待着），但速度按激活参数（每 token 只搬这些字节）。用总量算速度会把 235B-A22B 估成 0.7 tok/s，而真实值是 20–40 tok/s 量级——错 30 倍。本站速度引擎对 MoE 一律按激活参数折算。

MoE 还有一个独门用法：把专家权重放在内存、把注意力层放在显存。这样 16G 卡能『用上 30B 级模型』，代价是每 token 要跨 PCIe 搬数据，速度大约 25–35 tok/s（本站按内存带宽 55GB/s 的一半效率估）。稠密模型不能这么玩，因为它每个 token 都要读全部权重。

MoE 的弱点：同总参数下它比稠密模型更吃内存（专家多、文件大），而且指令遵循质量有时不如同参数稠密模型。别只盯着『A3B 好快』。

Question 7

我内存大（64G/128G），是不是就能跑大模型？

Accepted Answer

能跑，但会很慢。内存带宽只有显存的 1/10 到 1/15，稠密模型 offload 之后普遍掉到 1–5 tok/s。大内存的正确用法是给 MoE 放专家。

显存带宽参考：RTX 4060 Ti 16G 是 288GB/s，5080 是 960GB/s；消费级双通道 DDR5 内存实测有效约 50–60GB/s（本站取 55）。差了 5–19 倍。所以『内存装得下』和『内存跑得动』是两件事。

稠密模型 offload 的直观后果：Llama 3.1 70B 用 IQ3_XXS 权重 26.4G，一张 24G 卡放不下，剩下的放内存，每 token 要从内存搬十几个 GB，实测口径大约 2 tok/s——一句话等 30 秒。这种状态本站标为『能跑但没实用价值』。

反过来说，大内存 + 一张 16G 卡跑 MoE 是很实在的组合：Qwen3-30B-A3B 的 30B 权重放内存、注意力放显存，能到 25–35 tok/s 的日常可用速度。这是 2025 之后本地跑大模型最划算的一条路线，前提是你有 48G 以上内存。

混合模式在 llama.cpp 里靠 --n-cpu-moe（把专家放内存）或 -ot（指定层放 CPU）实现；Ollama 会自动分配但你看不到细节，所以想要这个玩法建议用 llama.cpp 或 LM Studio 的手动模式。

Question 8

本地跑的小模型，和在线的 GPT / Claude / 通义比差在哪？值不值？

Accepted Answer

差距主要在长逻辑链、冷门知识、多轮指令遵循；优势在隐私、离线、无限量、可调参、零调用成本。把本地模型当『不会上网的熟练工』最不容易失望。

预期管理很重要：16G 显存能跑的天花板大约是 14B 稠密或 30B 级 MoE，它的水平大致相当于在线服务两三年前的旗舰，而不是今天的旗舰。写代码、总结文档、改语气、翻译、结构化抽取这些『格式活』完全够用；需要引用外部事实、超长推理链、复杂工具编排的活会明显吃亏。

本地独有价值：① 数据不出机器（病历、合同、内部代码）② 断网可用 ③ 没有次数/Token 计费，可以一晚上跑两万条数据 ④ 能改 temperature、能自己塞系统提示词、能换任意开源权重。

本地主要代价：首次下载要几十 GB 流量与硬盘；知识有截止日期且没有联网搜索；同样的任务可能要你多写提示词才稳定；出问题没人帮你，只能查故障排查。

务实建议：把本地模型用于『批量、私密、格式固定』的任务，在线大模型用于『需要判断力和知识』的任务。这个站不评判该用哪一边，只帮你算本地这一边装不装得下。

Question 9

我该配多大的显存？给一条按容量而不是按型号的阶梯

Accepted Answer

8G 只能玩 4B–8B 且上下文紧；16G 是本地第一台最省事的容量点；24G 能认真用 32B；48G 起才谈得上 70B。别买 8G 新卡。

本站刻意不做导购、不给链接，只给容量阶梯（数字都按 Windows 88% 水位、Q4_K_M、要留 8K 上下文这个前提）：

8G（可用约 7.0G）：4B/8B 的 Q4_K_M 能跑，Q8 装不下；8B Q4 权重 4.8G 加开销只剩约 1.2G 给上下文，约 8K 出头就到顶。中文 4B 是这张卡的甜点位，8B 属于『凑合能用』。二手 8G 卡便宜才买，新卡不划算。

12G（约 10.6G）：8B Q8 有肉（权重 8.5G 但只剩 1.1G ≈ 8K 内），实际甜点位是 8B 的 Q6_K 或 Q5_K_M，或 12B 的 Q4_K_M（权重 9.84G 会挤，12B 建议 Q4_XS 以下）。

16G（约 14.1G）：本站问得最多的一档，也是『第一台』的最佳容量点。8B Q8 剩 4.6G ≈ 33K 上下文（但 Qwen3 原生只到 40K，基本顶格）；14B 的甜点位是 Q6_K 而不是 Q8（Q8 只剩 0.13G ≈ 850 token，4K 必爆）；12B 同理建议 Q6_K；27B/32B 只能 Q3 系列且上下文极紧；MoE 走内存放专家则很舒服。详见 16G 容量表。

24G（约 21.1G）：32B Q4_K_M 权重 19.2G 已经装不进 24G 的水位线，得退到 IQ4_XS（17.0G）或 Q5_K_S 以下；24B 的 Q4/Q5 很舒服。这一档是『认真用 32B』的最低容量。

32G（约 28.2G）：32B Q5_K_M 权重 22.4G 加开销剩约 4.8G ≈ 19K 上下文，是 32B 最舒服的容量点。

48G（约 42.2G）：70B 的 IQ4_XS（36.4G）加开销剩 4.8G，能开约 15K，是 70B 可用的最低起点。70B Q4_K_M（42G）在 48G 卡上装不下（水位后只剩 42.2G 且还要留 KV）。

128G 及以上：属于 70B Q8、235B-A22B 的领域，通常靠多卡或大内存 offload，本站共享主机类目里有相关数据。

最后一条经验：预算有限时，显存 > 带宽 > 算力。同样是 16G，288GB/s 和 960GB/s 的速度差 3 倍，但 8G 和 16G 的差别是『能不能装下』。

Question 10

16G 显存到底能干什么？（最常被问的一档）

Accepted Answer

能舒服跑 8B Q8 / 14B Q6_K / 12B Q6_K，能勉强跑 27B–36B 的 Q3 但上下文几乎没有，用 MoE 放内存可以跑 30B 级还很流畅。

这是本站第一张容量推算表，直接给结论（Windows 88% 水位，可用约 14.1G，扣 1G 框架开销）：8B Q8_0 权重 8.5G，剩 4.6G，可开约 33K token，是 16G 上质量与上下文兼得的最佳组合；14B Q6_K 权重 11.48G，剩 1.6G ≈ 10.7K；14B Q8_0 权重 14.88G，只剩 0.13G ≈ 850 token —— 所以『14B 原则上跑 Q8』在 16G 上不成立，甜点位是 Q6_K。

12B（Gemma 3 12B）Q8_0 权重 12.75G，剩 0.33G ≈ 2.4K，同样出局；Q6_K 权重 9.84G 剩 3.3G，得益于它 48 层里只有 8 层要全量 KV，可开上下文比 14B 还多。

27B/32B/36B 这一档在 16G 上是『理论可跑、实际别跑』：27B Q4_K_M 权重 16.2G 直接超过整卡容量；IQ3_M 权重 11.6G 剩 1.5G ≈ 6K；32B IQ3_XXS 权重 12.1G 剩 1.0G ≈ 3.6K；36B IQ3_XXS 权重 13.6G 加开销已经顶到水位线，装不下。

16G 上真正的隐藏冠军是 MoE：gpt-oss-20B（21B 总/3.6B 激活，KV 4K 只要 0.097G）MXFP4 权重约 11.3G，剩 1.8G 且几乎不涨，速度快；Qwen3-30B-A3B 权重 13–18G，整卡塞不下就走内存放专家，25–35 tok/s 很流畅。

完整表格、每档 KV 精度切换、8K/16K 两列都在 16G 容量推算表里。

Question 11

『小模型跑 Q8、大模型跑 Q4、再大跑 Q3』这个说法对不对？

Accepted Answer

方向对，但要按显存档位落地。4B–9B 跑 Q8 确实合适；12B–14B 在 16G 上 Q8 会把上下文挤光，Q6_K 才是甜点；27B+ 在 16G 上 Q4 根本塞不进去。

这条经验法则的本质是『量化档应该由剩余显存决定，不是由模型大小决定』。同一个 14B，在 24G 卡上跑 Q8 很舒服，在 16G 卡上就只能 Q6_K，在 8G 卡上只能 Q3。所以把规则写成『14B 原则上跑 Q8』会在 16G 用户身上失效。

带数字的落地版：Q8_0 权重 = 参数量 × 1.0625。8B→8.5G、12B→12.75G、14B→14.88G。16G 卡水位后可用 14.1G，再扣 1G 框架开销，剩 13.1G 给『权重 + KV』。所以 14B 跑 Q8 需要 14.88G > 13.1G，权重本身就超了；12B 跑 Q8 剩 0.33G 给 KV，约 2.4K token，日常聊天两三轮就顶满。

『27B/32B 属于 Q4 或 Q3』也要修正：27B Q4_K_M 权重 16.2G、32B Q4_K_M 权重 19.2G，在 16G 卡上连权重都放不下，谈不上 Q4。这一档在 16G 上只有 Q3 系列，而且上下文余量 3–6K，属于演示性质。真要跑 27B+，24G 起。

『再大 16G 肯定跑不进去』这句要加一个例外：MoE。gpt-oss-20B、Qwen3-30B-A3B 这类总参数 20–30B 的 MoE 在 16G 上不但能进，还比 14B 稠密模型快。判断能不能进 16G 的正确依据是『权重大小』和『每 token 读取量』这两个独立的数，不是参数量。

Question 12

Mac（M 系列统一内存）能不能跑本地大模型？

Accepted Answer

能，靠统一内存装得下很大的模型，但带宽只有同级独显的 1/3 到 1/2，所以『能跑很大但很慢』。买 Mac 跑大模型要按带宽而不是内存大小做决定。

Apple 的统一内存让 CPU 和 GPU 共享同一条内存池，带宽对整块芯片是固定的。这意味着 64G 的 Mac 能装下 70B 的 Q4，但读权重的带宽决定了速度上限，通常同价位独显方案的 1/3 到 1/2。

本站的估算引擎按『显存带宽』建模，Mac 的映射口径和独显不同（还需要在系统设置里调 GPU 可用内存上限），所以本站不给 Mac 的容量表结论，只提示两点：① 统一内存不等于显存，速度上限是带宽给的 ② MLX 生态比 GGUF 快，同一台 Mac 上换框架能差 30–50%。

Mac 适合的场景：写作为主的长上下文（Prompt caching 复用 KV，长对话首 token 快）、离线便携、不想折腾驱动。不适合：追求 tok/s、批量跑数据、跑需要 CUDA 的周边工具链。

Question 13

站里那些『魔改卡』『共享主机』是什么？能买吗？

Accepted Answer

魔改卡是把显存/BIOS 改大的非官方卡（如 3070 改 16G、4060Ti 改 20G），风险在驱动与稳定性；共享主机是别人机房里的卡按时租。本站把它们单列，就是不混进官方型号里。

本站显卡库的品牌字段有六个：英伟达、AMD、英特尔、国产、魔改、共享主机。前四类是官方在售/官方规格；『魔改』指显存颗粒被换成更大容量或功耗墙被动过的卡，规格标的是改后容量，官方驱动更新可能失效，显存长期高温也更容易出 ECC 类问题。

之所以单列而不是合并，是因为估算口径会不一样：同一颗 3070 核心，官方 8G 版带宽 448GB/s，改 16G 后带宽不变但能装下更大的模型，速度估算一样、可用模型完全不一样。混在一起会让数据失去意义。

共享主机类目记录的是按时租用的机房卡（本站口径按本地机器处理，因为它实际提供的就是一张卡 + 一块盘）。它的价值是『让你花几小时验证 48G/128G 才划算的模型是不是真值得升级』。

本站不做导购，不给任何购买链接和店铺，也不判断某张具体卡值不值。要不要承担魔改风险，请自己权衡；我们只保证把这类卡和官方卡分开标注、不假装它们是同一种东西。

Question 14

从 0 到跑通第一个模型，具体要走几步？

Accepted Answer

五步：确认驱动 → 装一个框架 → 下载一个 GGUF → 用命令行起服务 → 打开网页界面聊天。卡住的位置 90% 在第二、三步。

第一步，确认显卡驱动够新。Windows 看 NVIDIA 控制面板的版本，或直接命令行 nvidia-smi（能看到卡名和显存总量就说明驱动装了）。llama.cpp 的 CUDA/ROCm/Vulkan 后端各有版本要求，报错 unrecognized error code 基本都是这里。

第二步，选一个框架。怕麻烦用 LM Studio（图形界面，一键下载）；想看懂原理、想精确控制显存用 llama.cpp（下载预编译压缩包，解压即用，但命令行参数要自己写）；想被生态带着走用 Ollama（一条命令拉模型，但它会替你决定量化档和放不放显存）。

第三步，下载模型文件。新手建议从 Qwen3-4B 或 Qwen3-8B 的 Q4_K_M 开始（约 2.5G / 4.8G），选 GGUF 格式。下载前先确认硬盘剩余空间和你的网络流量预算。

第四步，起服务。llama.cpp 的图形用法是 llama-server，关键两个参数是 -c（上下文长度）和 -ngl 99（把所有层放显存）。LM Studio 里对应 Chat Context Length 和 GPU Offload 滑块。

第五步，打开 http://localhost:8080（llama.cpp 自带网页界面）或者用任意聊天客户端接上 API 地址。到这里就算跑通了。

跑不通的常见原因集中在本站故障排查的『起不来』和『装不下』两个分类里，报错原文可以直接搜索。

Question 15

模型文件去哪下载？GGUF、safetensors、MLX 有什么区别？

Accepted Answer

本地跑选 GGUF（llama.cpp/Ollama/LM Studio 通用）；训练/微调选 safetensors；Mac 选 MLX。国内网络不畅用镜像站，但一定要核对文件大小和哈希。

格式和框架是绑定的：GGUF 是为 CPU/GPU 混合推理设计的单文件格式，量化档就写在文件名里（比如 xxx-Q4_K_M.gguf），是本地跑唯一需要的格式。safetensors 是分片的原始精度权重，动辄上百 GB，要自己转量化。MLX 是 Apple 的格式。

常见下载位置：Hugging Face（官方模型仓库 + 大量第三方量化版）、ModelScope 魔搭（国内访问快）、以及量化作者的个人仓库。同一个模型会有很多人做的不同量化版本，选哪个不是玄学：优先选量化说明里附了困惑度（perplexity）对比的那份。

务必核对两件事：① 文件大小是否和页面标的一致（下载被截断是『加载时报错』和『输出乱码』的常见原因）② 有条件就校验 SHA256。别从二手网盘链接拿权重，改名和篡改都发现不了。

国内镜像能提速，但要注意镜像仓库的版本可能滞后，尤其是刚更新的模型；本站数据里的架构常数全部取自 config.json，如果你下的镜像里 config 和官方不一致，模型的 KV 常数就得重新核。

Question 16

llama.cpp、Ollama、LM Studio、vLLM 我该用哪个？

Accepted Answer

想控制显存和参数用 llama.cpp；想一条命令搞定用 Ollama；想要图形界面用 LM Studio；想要高并发服务很多人用 vLLM。新手第一站推荐 LM Studio。

llama.cpp：C++ 写的推理引擎，几乎所有本地格式的底层。优点是参数完全可控（-ngl 决定放几层到显存、-ctk 决定 KV 量化、--n-cpu-moe 决定专家放内存），速度上限最高。缺点是命令行，报错信息要自己读。本站的速度估算模型就是按它的行为建的。

Ollama：包了一层 llama.cpp，加模型仓库和 API，一条 ollama run qwen3:8b 就能跑。代价是它替你选量化档、替你分配显存，出问题不容易看清。想省心和想精细是互斥的。

LM Studio：图形界面，能下载、能调滑块、能起本地服务、自带聊天窗口。适合第一次跑的人，也适合不想记参数的人。精细度低于 llama.cpp 但高于 Ollama。

vLLM：面向高并发服务，把显存全吃满做批处理，个人单轮对话不是它的场景。你只有一个人问问题时，vLLM 反而可能比 llama.cpp 慢。

本站模型页给出的命令都以 llama.cpp / Ollama / vLLM 三种为主，其中 vLLM 直接吃 Hugging Face 仓库名（数据里的 hf_repo 字段是核实过的），Ollama 标签是本站按库内命名习惯整理的，实际以 ollama pull 结果为准。

Question 17

要占多少硬盘？要不要 SSD？

Accepted Answer

模型文件本身 2–40GB 一个，装三五个就上百 GB；建议至少留 200GB 空闲并且必须是 SSD，机械盘会让加载从几秒变成几分钟。

单个 GGUF 的大小约等于权重占用（本站容量表里的『权重』列）：8B Q4_K_M 约 4.8G，14B Q6_K 约 11.5G，32B Q4_K_M 约 19.2G，70B IQ3_XXS 约 26.4G。加上下载缓存和留档对比的版本，实际占用要乘 2。

SSD 的意义在加载速度：模型启动时要从盘读全部权重进内存/显存，SATA SSD 约 0.5GB/s、NVMe 约 3–7GB/s，机械盘约 0.15GB/s。26G 的 70B 模型在 NVMe 上十几秒加载完，在机械盘上要近三分钟。跑起来之后磁盘就不参与了，所以机械盘影响的是启动而不是 tok/s。

如果内存放专家（MoE 大内存玩法），磁盘影响会更明显：系统内存吃紧时会开始用页面文件，那就是在磁盘上模拟内存，速度会崩。所以大内存玩法请配合快速磁盘和真实的足够内存。

顺带一个坑：Windows 上路径带中文或空格会让某些预编译二进制直接闪退，建议把模型统一放在纯英文路径下。

Question 18

Windows 还是 Linux？差别有多大？

Accepted Answer

同样硬件下 Linux 大约能多用 10% 显存（没有桌面合成器吃那块），驱动/权限要额外折腾。新手建议先 Windows 跑通，再决定值不值得换。

本站容量表默认按 Windows 口径：16G 可用约 14.1G（88%）。原因是 WDDM 显示模型下，桌面合成器和浏览器会长期占住 0.5–1.5GB 显存，模型拿不到。Linux 桌面大约占 5–10%，无头（不接显示器）能到 95%。

这 10% 的差别在临界点上会翻盘：14B Q6_K 在 Windows 16G 上剩 1.6G ≈ 10.7K 上下文，在 Linux 上剩 2.8G ≈ 19K。所以同一张卡、同样量化，两个系统的『能开多大上下文』结论不同。切换页面顶部的系统口径就能看到重算结果。

Linux 的额外好处：显存占用能用 nvidia-smi 看得很清楚、容器化方便、没有自动更新重启打断长任务。代价：驱动安装、权限组、ROCm 的坑、以及和 Windows 软件生态的兼容成本。

别忽略第三种：Windows + WSL2。显存 overhead 和原生 Windows 接近（不会帮你找回那 10%），但命令行体验接近 Linux，适合『想在 Windows 上用 Linux 工具链』的人。

Question 19

主要用中文，该选哪个模型？

Accepted Answer

中文优先看 Qwen3 系列和 GLM-4-9B；要看图用 Gemma 3；只要英文推理用 Phi-4。词表对中文友好程度会直接影响同样上下文能装多少汉字。

中文能力与参数量无关地与词表、训练语料相关。Qwen3 全系列中文都强，GLM-4-9B 的中文和工具调用在小尺寸里口碑很好，且它只有 2 个 KV 头，4K 上下文只要 0.16G——同样 12G 显存，它能开的上下文比 Qwen3-14B 多出一大截。

Gemma 3 中文一般但多模态和长上下文架构很聪明（滑窗让 32K 只花 2.3G），如果任务是『看长文档 + 英文为主』很合适。Phi-4 推理与数学强，但只有 16K 原生上下文且中文较弱，做中文任务容易翻车。

选完模型还要选量化档：中文任务对低比特量化更敏感（同量化下中文质量下降通常比英文明显），所以如果你必须在 Q4 和 Q3 之间为质量挣扎，优先加显存或选更小参数的模型，而不是压到 Q3 以下。

本站模型清单里每个模型的 KV 常数都取自官方 config.json 并附了链接，参数量取官方命名口径（例如 Mistral Small 3.1 24B 的文本塔实际约 22B，本站按 22B 估算，因为这样算出来的 Q4 权重和真实 GGUF 文件才对得上）。

Question 20

不花钱让本地模型变快的 5 个开关

Accepted Answer

① -ngl 拉满 ② 限制上下文 ③ KV 量化 ④ 开 flash attention ⑤ 关掉没用的多模态塔。前两个通常就够。

第一优先：确认所有层都在显存。llama.cpp 的 -ngl 99 是全放；如果它自动少放了几层（比如显存临界），每 token 就有几层要从内存搬，速度可能腰斩。判断方法是看启动日志的 offload 行数，以及 nvidia-smi 的显存占用是不是接近你给的预算。

第二：上下文不要虚高。-c 决定 KV 预留多少空间，设成 32K 而实际只用 2K 不会让模型变慢，但会让显存吃紧从而逼出 offload。按实际需求设（聊天 8K 通常够，读文档再加）。

第三：KV 量化。-ctk q8_0 -ctv q8_0 把 KV 减半，质量损失几乎听不出来；长上下文场景可以上 q4_0 再省一半。这直接换回 offload 空间或更长上下文，本站容量表有 KV 精度切换控件可以预览效果。

第四：flash attention（llama.cpp 的 -fa，Ollama 里是 FUSE 相关设置）。上下文越长收益越大，长文档场景能提 10–30%。

第五：用纯文本量化版而不是带视觉塔的完整版。多模态模型的视觉塔在纯文本任务里白占几个 GB 显存和一份带宽。

最后一个非开关的认知：如果你用的是 MoE，速度不该按总参数量预估（本站引擎已经按激活参数算了）。很多人以为『30B 就该像 30B 一样慢』，然后把自己的正常速度当成故障来排查。

Question 21

文档比显存允许的上下文还长怎么办？

Accepted Answer

三条路：换滑窗架构模型、把 KV 量化到 q4、或者分块检索只把相关段落塞进去。别指望把 -c 调到 128K 就解决了。

先看显存账。以 16G 卡（可用约 14.1G）跑 14B Q6_K（权重 11.48G）为例，剩 1.6G，能开约 10.7K token；同一张卡跑 GLM-4-9B Q8（权重 9.56G）剩 3.5G，因为只有 2 个 KV 头，能开超过 22K。想读更长的文档，先考虑换 KV 便宜的模型，这比换卡便宜。

第二个杠杆是 KV 量化。把 -ctk/-ctv 设 q4_0，KV 直接变 1/4，上面 14B Q6_K 的 1.6G 余量等效变成 6.4G 可用，能开的上下文翻 4 倍。代价是长程细节召回会有损失，重要场景请自己 A/B 测一下。

第三个杠杆是别把全文塞进去。分块检索（先按关键词/小模型筛出相关几段，只把这几段放进上下文）是工程做法，它把『上下文长度』问题变成了『检索质量』问题。多数读文档的需求，8K 精准上下文比 64K 全文效果好。

注意模型原生上限这一硬约束：Phi-4 只有 16K，GLM-4-9B 只有 32K，Qwen3 系列是 40K。显存够也不能超过它；想开超过原生上限需要额外的 rope 缩放设置，属于超纲使用，本站不给这类结论。

Question 22

为什么有的模型开长上下文特别便宜？

Accepted Answer

因为层数、KV 头数、每头维度这三个数决定 KV，和参数量不成比例。滑窗架构更把大部分层的 KV 锁死在固定窗口里。

本站核实过的四个极端对照（每 4K 上下文的 KV，FP16）：gpt-oss-20B 0.10G、GLM-4-9B 0.16G、Gemma 3 12B 0.56G、Qwen3-14B 0.63G、Phi-4 0.78G、Qwen3-32B 1.00G。注意 GLM-4-9B 参数量比 Gemma 3 4B 大，KV 却更省；而 Qwen3-4B 参数量只有 32B 的 1/8，KV 是它的 56%。

差别来自结构：KV = 2 × 层数 × KV头数 × 头维 × 精度字节 × token 数。GPT 系列的 gpt-oss 只有 24 层、8 头、头维 64，还有一半层用 128 token 滑窗，所以三个因子全都小。GLM-4-9B 40 层但只有 2 个 KV 头（MQA 风格），所以极省。

滑窗混合是另一种省法：Gemma 3 12B 有 48 层，但只有 8 层需要全量 KV，另外 40 层的 KV 永远锁在 1024 token。所以它的 KV 增长斜率只有同级稠密模型的 1/6，32K 上下文时是 2.35G，而按参数量线性猜会得到 4.5G。

实用结论：同一个显存预算下想开更长上下文，优先选『层数少、KV 头少、带滑窗』的模型，而不是无脑选参数量小的。参数量决定权重，结构决定 KV，两件事互相独立。

Question 23

站里的『实测』『推算』『声称』分别是什么意思？

Accepted Answer

实测=有来源链接且我们核过；推算=本站公式算出来的，误差可到 ±20%；声称=厂商或提交者自说自话。三类的可信度完全不同，看数字前先看标签。

这是本站最重要的一条约定，也是它和数据堆砌型站点唯一的区别。三级口径定义：① 实测（带可点开的外部链接、有人核对过内容与你的硬件一致）② 推算（本站由显存带宽/参数量/KV 公式导出，页面上会写明是估算）③ 声称（厂商宣传、用户自述、未经核实的转载）。

推算的已知误差范围：权重误差主要来自量化块的附加开销，约 ±5%；速度误差更大，因为真实运行还受 CPU、内存时序、驱动、框架版本影响，本站对单流速度还额外设了经验上限，综合看 ±20% 是乐观值，offload 场景可能偏差更多。

本站目前的实测数据量是 14 条，都在排行榜 /rank/ 里那一块：11 条是「本站实测」——本机跑出来的，每条带日志路径可以逐格核对，卡只有 1 张（NVIDIA Tesla V100 32G（数据卡））；3 条是「站长口报」——站长当面给的真机数，无日志无外链，标 claimed 档、未本站复现。另有第三方他测 102 条、官方跑分 99 条（官方分数不是本地速度，另算）；另有 42 条本站自跑的条目以 benchmarks 档留在 V100 卡页的「他测汇总」表里（同样带日志路径，徽章是「本站实测」），不并进上面这 14 条。覆盖仍然很窄：只有 2 张卡有本站自己的数（NVIDIA Tesla V100 32G（数据卡）、NVIDIA RTX 5060 Ti 16G），其余所有卡的速度数字仍然属于『推算』。我们宁可把这一点写明白，也不想用一堆看起来很专业但没有来源的数字撑场面。

架构常数这一层是核实过的：66 个收录模型里有 54 个已按对应 Hugging Face 仓库的 config.json 建了架构常数（层数/KV 头数/头维/滑窗/原生上下文上限），数据文件里每条都带仓库名和抓取日期，你可以自己点开对。剩下 12 个是 MLA 多潜注意力、压缩稀疏注意力这类套不进「层数×KV头×头维」六字段的架构，本站不硬填（硬填就是编数字），KV 走保守兜底并在摘要里写明依据。参数量取官方命名口径，不完全等于文件实际参数量。

Question 24

为什么你的数字和别人测的不一样？

Accepted Answer

四个常见原因：系统水位不同、KV 精度不同、有没有留够上下文、以及 MoE 按总量还是按激活量算。本站把前三个都做成了可切换控件。

第一个最常碰到的：可用显存口径。按整卡 16G 算，和按 Windows 88%（14.1G）算，『14B 能开多大上下文』的结论会从约 21K 变成约 10.7K，差一倍。本站默认按 88%，因为这是 Windows 桌面的真实情况，但页面上可以切到满容量对比。

第二个：KV 精度。默认按 FP16 算，如果你实际用了 -ctk q8_0，同一份权重能开的上下文接近翻倍；用 q4_0 翻四倍。本站容量表顶部有 KV 精度切换，切一下所有结论重算。

第三个：算的是权重还是权重加上下文。很多『我这卡能跑 32B』的说法只验证了权重装得下，没说还能开多少上下文——19.2G 的 32B Q4 塞进 24G 卡之后只剩约 1G，4K 都勉强。本站容量表把『8K』『16K』分成两列单独判定，就是为了不让这种含糊混过去。

第四个：MoE 的速度基准。按 30B 总量算 Qwen3-30B-A3B 会得到个位数的 tok/s，按 3B 激活算会得到上限被钳住的几十。两种算法都『没错』，但描述的完全不是一件事。本站一律按激活参数，并标明是否把专家放内存。

如果你发现本站某个数字和公认数据差距很大，那不是『你测错了』，很可能是本站口径写错了或者常数取错了。这种情况请在反馈里告诉我们是哪一页哪一行，我们改，并保留修订记录。

Question 25

我能怎么帮这个站补数据？

Accepted Answer

最有效的一件事：把你的一次真实运行结果按固定格式发过来（显卡、模型、量化、上下文、框架、tok/s、出处链接）。一条顶十条。

本站现在缺的不是想法而是实测样本。排行榜已有 14 条（11 条本站自测带日志 + 3 条站长口报），但只落在 2 张卡上（NVIDIA Tesla V100 32G（数据卡）、NVIDIA RTX 5060 Ti 16G），66 个模型里也只有一小部分有速度实测；容量表绝大部分还是公式推出来的。任何一条真实数据都能立刻校准一个速度区间，价值远高于新增一个模型条目。

一条有用的记录需要七个字段：显卡完整型号（含显存容量，魔改卡请注明）、模型与量化档、实际上下文长度、框架和版本、实测 tok/s（建议跑 3 次取中位而不是最好看的一次）、是否全部在显存里（以及 offload 了几层）、以及来源链接（帖子/截图/仓库 issue 都算）。缺来源链接的只能标成『声称』级，可信度会自动降一档。

提交入口在排行榜页的『上传实测』。本站是纯静态站点，没有服务器接收表单，所以目前的流程是：填完表单复制结构化内容，通过页面上写的联系方式发给站长，由站长核对来源链接后入库。这个流程笨，但保证了每条数据都有人核对。

另一个更省事的贡献方式：把你看到的带数字的外部测试贴链接发给我们，我们按引用类条目整理进故障排查与排行榜，并保留原链接和作者信息。本站不搬运他人文章全文，只引用事实与数据。

Question 26

开了投机解码能快多少？为什么别人 40 tok/s，我只有 18？

Accepted Answer

投机解码不是稳赚：小模型先猜几个 token，大模型一次性验证，猜中才快。提升完全取决于接受率，常见是一到三成，接受率低时反而更慢——别把别人的倍数当成你的。

正常解码是一个 token 一个 token 往外吐，每吐一个就要把全部权重读一遍，所以瓶颈在带宽而不是算力。投机解码的思路是：拿一个小草稿模型连着猜后面几个 token，再让大模型一次并行把这批都验一遍。验对了就等于一次读权重出了好几个字，自然就快。

关键变量是接受率（draft acceptance rate）：草稿猜的 token 里有多少被大模型采纳。代码、模板化改写、固定套路的翻译，重复度高，接受率能到六七成，快三成很常见；开放创作、多语言混杂、推理链长且发散的文本，接受率可能只有两三成，这时大模型要不断推翻重猜，不仅不涨还可能变慢。所以『我开了投机快一倍』这句话，如果没报接受率和任务类型，等于没说。

成本也别忘了：草稿模型自己要占显存和内存带宽，两个模型之间还要来回传数据。小显存卡上，这一份开销可能就是压垮 8K 上下文的最后一根稻草；多轮长对话里 KV 已经很大，验证批次的成本也会抬高。

本站的容量表和单卡专辑里的速度一律是『未开投机』的单流口径，这样才能横向比较。你手上如果真有同一张卡、同一模型、开与不开各跑几次的数字，那就是本站最缺的东西：按排行榜页那个带七个字段的格式发过来，我们把它标成实测并且注明接受率。

Question 27

评测里的 tok/s 是单流还是并发？为什么同一张 4090 有人报 30、有人报 400？

Accepted Answer

单流是你一个人对话时每秒出几个字；并发是同时服务很多人时每秒总共出几个字。后者能高一个数量级，两种数字放在一起比一定是误导。

单流（一个请求、batch=1）是个人本地使用的真实体感，它几乎只由『带宽 ÷ 每 token 要读的字节』决定，因为每出一个字都得把权重完整扫一遍，中间大量时间在等内存而不是等计算。

并发（batch=N）是把 N 个人的请求搭成一批同时算。权重读一次可以服务整批人，所以总吞吐能接近线性地往上叠——一张报 30 tok/s 单流的卡，开 32 路并发报到 400 tok/s 总吞吐完全正常。但每一路分到手只有 12 tok/s，体感反而更慢：单个人看到的第一个字要等更久，出字也更卡。

这就是网上速度数字最容易混的地方。评测视频和厂商页很少标明自己是哪一种，有些还会在标题写『每秒 400 token』而实际是服务多人的总吞吐。看到 tok/s 先反问三件事：几个人在用、一次报的是总吞吐还是你的体感、报没报首 token 延迟（prefill）。

本站容量表与单卡专辑里的数字全部是单流口径，他测汇总表永远把单流与并发分开列（并强制标注批大小），就是因为把并发吞吐写进单流榜里，得出的排名一定是假的。

Question 28

都是 27B 的 Qwen3.8-27B、Terminal-RSI、AREX-2，我该下哪个？

Accepted Answer

三个是同一个底座的不同微调，显存档位完全一样，差别只在训练方向：要通用对话选底座 Qwen3.8-27B，要终端 Agent / 递归自改进选 Terminal-RSI，要深度研究 / 工具调用选 AREX-2。

先说清一个前提：这三个不是三个平行的模型，是同一个底座的不同微调。站内 Qwen3.8-27B（2026-09）是底座，Terminal-RSI-27B（2026-10-21 建库，HF 标签 terminal-agent / reinforcement-learning / 递归自改进）和 AREX-2（2026-09-29 建库，HF 标签显式写了 base_model:finetune:Qwen/Qwen3.8-27B）都是在它上面训出来的。『同底座』这个判断是本站按官方 config.json 的常数完全一致（64 层 / 16 层全注意力 / 4 KV 头 / head_dim 256 / 262144 上下文）加上 HF 的 base_model 标签推出来的——是强推断、不是 100% 官方背书，所以三条模型页的 summary 里都如实写了。

因为底座一样，显存的账完全一样，这也是选它俩最容易误会的地方：Q4 权重都约 16G，KV 每 4K 都 0.25G（48 层线性注意力不存 KV），原生上下文都 262K，24G 卡装 Q4 之后能开几十 K。所以『选哪个』从来不是显存问题，是任务问题——显存上它俩和底座一模一样，没有谁更省。

按任务分：要一个什么都能聊、中文强、最稳的通用底座，下 Qwen3.8-27B；要写终端脚本、做递归自改进类的 Agent，下 Terminal-RSI-27B（HF 定位就是 terminal-agent + 强化学习）；要做深度研究、大量工具调用，下 AREX-2（HF 定位是 deep-research / Agent）。三个都带视觉塔（多模态），用 llama.cpp 跑要另外配 mmproj 视觉文件。

一句诚实话：这三条站内目前都没有本站或他测的本地速度，速度一律按容量表推算 ±30%，别把任何一条的『快』当实测。到底哪个在你的任务上更快，要等本站跑分或社区的同一硬件对比日志才能定，现在谁都说不了。

Question 29

站里说『显存不够硬盘来凑』，那个 n-gram 表 / Engram 表到底是什么？能真省显存吗？

Accepted Answer

那是模型里一整块哈希查表（n-gram / Engram 记忆），不是普通权重——查表不是矩阵乘法，可以整块卸到内存甚至 SSD，显存只装骨干。代价是查表走 PCIe 比显存慢，能跑但更慢，本站没测这套的速度。

先把两种 offload 分清，别混。站内讲的第一种是 MoE 专家 offload（见『内存大能不能跑大模型』那条）：把不用的专家放内存，llama.cpp 里靠 --n-cpu-moe。本文讲的是另一种——模型里有一整块『哈希查表』（n-gram 记忆 / Engram 记忆），它查的是 n-gram 片段对应的一行参数，是查表不是矩阵乘法，所以可以整块卸到内存甚至 SSD，显存只留骨干。这是 2026 这一代新模型（Flash-Next、DeepSeek-V4.1-Flash）能比上代更省显存的关键。

站内有两条带这种表，数字都是从官方 config.json 核到的、不是估的：Qwen3.8-Flash-Next 带 51B 的 n-gram PLE 表（config：20M 词 × 2560 维 = 51.2B，恰好对上官方说的『125B 骨干 + 51B 表』）；DeepSeek-V4.1-Flash 带 196.6B 的 Engram 表（config：2 张 384M × 256 维，恰好对上官方『552B 骨干 + 196.6B Engram』）。表是单独一块，和骨干分开装。

怎么省、代价是什么：Flash-Next 的 125B 骨干 Q4 还要约 75G，得是多卡；但那 51B 的表整块卸到内存/SSD 之后，显存压力降一大截——社区有 IQ2_XS 整包压到 68G、一张 3060 12G 配 16G 内存跑通 decode 22 tok/s 的记录（单源、本站未复现）。DeepSeek 那 196B Engram 同理可以 host offload，官方 vLLM recipe 就是 CPU 卸 Engram + routed experts 来跑，但它的 552B 骨干本身单卡装不下，是多机/共享主机门槛，不是一张卡的事。

『显存不够硬盘来凑』准确的意思是：把不必须常驻显存的那块表卸出去，能装下；但查表每一步都要走 PCIe/内存，比全在显存里慢——它是『装得下』的解，不是『跑得快』的解。本站目前没有这套 offload 的实测 tok/s，上面所有速度数字都是社区或官方自述口径，别当本站实测。

Question 30

站里的数据多久更新一次？价格是什么时候的？

Accepted Answer

价格是带日期的快照不是现价；架构常数随官方 config 核过就算准。页面上每个数都能点到出处和日期。

先说最容易被误读的一条：站里的价格是**快照**，不是今天的价。站内价格表现在有 74 条快照，每条都带来源、发布日期和抓取日期，页面上以「全新/二手 + 快照日期」并排显示——同一天不同口径（挂牌价、成交价、在售中位价）会并列存在，本站不合并、不取中位数、不预测。

价格波动有多大，看同一张卡的几条快照就明白：RTX 3090 二手 2026-09-15 是 4200–4800 元（广东水神），2026-11-03 记「5300 起」，2026-11-12 的闲鱼在售中位价又是 9288 元（报价区 8488–10000）——三个口径差着近一倍，本站并列不合并。RTX 4090 二手 2026-03-14 还是 9000–10000，2026-11-10 已经记到 21694。所以「某卡现在值多少钱」这种问题，本站只能给带日期的快照，给不了现价。

架构常数是另一类时效：66 个收录模型里有 54 个已按官方 config.json 核过层数 / KV 头数 / 头维 / 滑窗 / 原生上下文上限，数据文件里每条都带仓库名和抓取日期（2026-11-02 到 2026-11-12 不等）。只有官方改架构才会失效，所以它比价格稳定得多。

实测数据只增不改：本站自测 11 条（每条带本机日志路径，可逐格核对）、他测 102 条、官方跑分 99 条（2026-11-07 的榜面快照，数值照抄、不复现）。价格类标快照日期，官方跑分标榜面日期，架构常数标抓取日期——三种日期含义不同，别混着用。

想自己核：每条数据都带链接或日志路径，点开就能对。发现哪条过期或错了，告诉本站是哪页哪一行，改了会留修订记录。

Question 31

站里的数据可信度怎么分级？我该信哪一档？

Accepted Answer

编辑口径分三级：A 多源交叉一致或本站复测、B 多源方向一致、C 单一来源待复核。页面上每个数字旁边的徽章就是这一档。

编辑口径三级：A 级 = 多源交叉一致，或本站复测验证过；B 级 = 多源方向一致但数值有差异；C 级 = 只有一个来源，必须标「单源，待复核」。两条来源打架时并列保留、注明各自出处，本站不取平均强行统一。

读者在页面上看到的标签是同一件事的另一套叫法：排行榜里「本站实测」= 本机跑出来的、有日志路径可逐格核对；「站长口报」= 站长当面给的真机数，无日志无外链，标 claimed 档、未本站复现；卡页他测表里五种徽章——本站实测 / 本站已复现 / 他测·本站未复现 / 口径不全·不进对比 / 无链接·不进对比——缺口径的行只展示，不进对比、不进中位数。

举个具体的例子：NVIDIA Tesla V100 32G（数据卡） 是全站唯一有本站自测的卡——11 条自测记录（全部落在这张卡上）加 42 条带日志的上下文扫描条目；同卡的他测数字只作参考。而卡规格本身（显存 / 带宽）以官方规格页为准，规格与档位来自本站调研汇总，卡页标的是「C 级单源，待复核」。

怎么用：先看标签再看数字；没有标签的推算速度（±20%）只当区间；单源数字（C 级）当线索不当结论；「本站实测」那几行带日志路径，可以要求逐格核对。

为什么不把这些揉成一个总评分：把不同口径的数字揉成一个分数，等于把来源问题藏起来。本站宁可给你一堆带标签的数，也不给一个看起来权威的排名。

Question 32

官方跑分（比如 AA 指数）为什么不等于本地速度？

Accepted Answer

两码事：官方跑分测的是模型在 API 上的智力水平，本站实测测的是你这张卡每秒吐多少 token。别拿分数换算速度。

站内有三类容易混的数字：① 官方跑分 99 条（Artificial Analysis Intelligence Index 等，2026-11-07 的榜面快照，数值照抄、未复现）；② 他测 102 条（别人真机跑的 tok/s，带卡 / 量化 / 上下文 / 框架 / 单流或并发）；③ 本站自测 11 条（本机跑、带日志）。前两类都不是「你在这张卡上」的速度。

官方跑分回答的是「这个模型答得好不好」，本地 tok/s 回答的是「这张卡每秒能吐几个字」。中间的桥梁只有参数量、量化、显存与带宽——官方跑分里没有一张卡、没有一个 tok/s，所以换算不了。

举个容易误解的例子：Inkling 2 Small 在 AA 指数上是 31 分（2026-11-07 榜面），那是 API 口径；站内 Inkling Small 的 AA 指数是 13 分。这两个分数都不能换算成「你 24G 卡能跑多少 tok/s」——跑得快慢取决于 KV 与带宽，跟智力分数不是一回事。

想知道「这个模型在我这张卡上多快」，只有两条路：查本站的实测表（他测 + 本站实测），或者用本站公式推算（页面标「推算」，误差 ±20%）。官方分数高不代表它省显存，也不代表它跑得快——有的高分工单跑时每 token 要读很多 KV。

也要小心反向误读：官方跑分是榜面快照，会过期；版本口径有疑问时本站两条并存并注明出处——比如 Inkling 2 官方博客写的是 256K + compaction，官方跑分榜写的是 1M，本站不替官方选一个。

Question 33

AMD 的 RX 卡能跑本地大模型吗？比 N 卡差在哪？

Accepted Answer

能跑，但生态窄一截：量化格式与框架支持比 CUDA 少，AMD 走 ROCm，部分 vLLM 路径与新量化直接没有。显存优先选 AMD，生态优先选 N 卡。

结论先行：AMD 卡在本站库里有 54 张，显存档从 4G 到 48G 都有，本地跑模型完全可用。真正的短板不是速度而是生态——CUDA 独占的东西（NVFP4 / MXFP4 硬件量化、FlashAttention-3、vLLM 多数量化路径与新模型适配）AMD 上没有，ROCm 的覆盖要慢一拍。

站内他测里的 AMD 实测目前 3 条：AMD RX 7900 XTX 24G 跑 Qwen3-30B-A3B Q4_K_M 报 303.1 tok/s——但那是 6 路并发的聚合口径，不能当单流；AMD RX 9070 XT 16G 跑 Qwen3.8-27B UD-IQ4_XS 单流 30.8 tok/s（上下文 48K、TTFT 28.9 秒）；AMD RX 6700 XT 12G 跑 Swift-1.5 IQ3_XXS 单流 28.6 tok/s。三条都是第三方单源（C 级），只作参考。

对照 N 卡的同口径数字：NVIDIA RTX 3090 24G 单卡 TP=1 Q4_K_M 是 46.9 tok/s（ctx 32K）；NVIDIA RTX 4090 24G 上 Mimo-9B 在 1K 上下文是 145.2 tok/s。AMD 与 N 卡的差距更多来自型号代际和量化格式，不是「AMD 天生慢一半」。

怎么选：① 预算优先看显存——24G 档 AMD 有 AMD RX 7900 XTX 24G（站内 2026-11-05 二手快照 5500 元），同价位 N 卡 24G 是 NVIDIA RTX 3090 24G（二手 2026-11-03 起 5300 元）；② 想用 vLLM 跑新模型、或者要用 NVFP4 / MXFP4 这类新硬件量化，选 N 卡；③ 只用 llama.cpp + GGUF 老老实实跑 Q4 / Q8，AMD 完全够用。

一条硬提醒：AMD 上踩坑最多的不是模型，是驱动和后端——ROCm 版本要跟框架匹配，CUDA-only 的工具（某些量化脚本、预编译 attention 内核）在 AMD 上没有对应物。跑之前先在本站 /tools/ 里确认工具支不支持你的卡。

Question 34

笔记本能外接显卡跑大模型吗？值得买显卡坞吗？

Accepted Answer

能跑，瓶颈在接口不在显存：TB3 外接 12G 卡实测 25 tok/s（单源）。适合已有大显存的旧卡 + 轻薄本；想要速度和 24G 以上，外接坞给不了。

结论先行：外接坞的瓶颈在 PCIe 通道与坞本身，显存还是那张卡的显存。常见外接卡是 12G–16G 档（3060 12G、4060 Ti 16G、3080 10G），跟桌面同卡容量完全一样；速度会被接口带宽压住。

站内唯一一条 eGPU 实测（第三方单源，C 级）：一台 i5-7260U + 8GB 内存的笔记本，经雷电 3 外接 NVIDIA RTX 3060 12G，Ollama 跑 Q4_K_M 全层上卡，单流 25 tok/s（6 类 prompt 各 200 token，范围 23.5-27.1），显存峰值 7843MB（占 12G 的 64%），首字延迟热态中位 2.5 秒、冷启动 35.2 秒。原文自己标注了「TB3 外接，PCIe 通道降宽可能压低绝对值」。

跟桌面同卡对照：站内同一基准库里 NVIDIA RTX 3090 24G 单卡 Q4_K_M 是 46.9 tok/s（ctx 32K），而 3060 的卡带宽 360GB/s 对 936GB/s——外接那台的绝对值低，主要来自 PCIe 通道宽度和宿主内存（8GB），不是模型本身。

价格账：站内 2026-09-15 那条快照里有一份现成的「迷你主机 + 显卡坞」方案——二手零刻 SER6 Pro 不到 1500 元 + 天钡 EG02 显卡坞一千出头 + 二手 3090 四千到五千，落在 7000–8000 元。外接坞的溢价主要买的是「不占桌面、能换卡」，不是性能。

什么情况值得买：① 已经有 3060 / 3080 / 4070 这类卡，别让它吃灰；② 轻薄本需要偶尔跑个 7B–14B；③ 临时验证一个模型要不要上这台机器。什么情况别买：想要 24G 以上显存（外接坞里几乎没有 24G 的卡）、想要 30+ tok/s 的日常体验、或者机器内存小于 16GB（权重放内存那套玩法直接卡死）。

Question 35

二手卡还是全新卡？本地跑大模型怎么选？

Accepted Answer

二手显存卡性价比明显更高（3090 二手 2026-11-03 起 5300、4090 二手 2026-11-10 21694），代价是无保修与成色不明；预算够就全新，预算卡死就二手 + 验卡。

结论先行：跑本地大模型买的是显存和带宽，不是型号新旧，所以二手是性价比最高的路——前提是你能接受无保修和成色不确定。

站内快照（带日期，别当现价）：NVIDIA RTX 3090 24G 二手 2026-11-03 记「5300 起」、2026-11-05 参考价 5499；2026-11-12 的闲鱼在售中位价是 9288 元（报价区 8488–10000）——同一个月不同口径差着近一倍，本站并列不合并。NVIDIA RTX 4090 24G 二手 2026-11-10 是 21694，而 2026-03-14 的快照还是 9000–10000。数据卡便宜得多：NVIDIA Tesla V100 32G（数据卡） 2026-11-12 在售中位 4900 元（报价区 4690–5000），NVIDIA Tesla P40 24G（数据卡） 2026-11-03 整机拆分单卡 1150 元。

二手的三个坑：① 矿卡与长期高负载卡的老化；② 无保修，坏了只能换；③ 显存颗粒被换、矿卡改固件是真实存在的风险，只能靠验卡软件（GPU-Z 看显存颗粒与 BIOS、烤机看显存报错）自己筛，本站不替卖家背书。

全新也不是稳赚：价格会波动——NVIDIA RTX 5090 32G 2026-10 的渠道快照是 35000–54000 元，2026-11-11 华强北现货口径 48500 元。高溢价档位买的是「现在能买到」，不是「更划算」。

怎么决策（按显存档）：16G 档二手几乎是唯一解；24G 档里 NVIDIA RTX 3090 24G 二手 5300 起、NVIDIA RTX 4090 24G 二手 21694、AMD RX 7900 XTX 24G 二手 5500（2026-11-05），若只跑 27B Q4，NVIDIA RTX 3090 24G 二手最划算；若要 30B 以上或长上下文，优先大显存卡——魔改卡另有专属风险条目，先读那条再买。

Question 36

多卡到底怎么拆层？加第二张卡值不值？

Accepted Answer

两种拆法：llama.cpp 拆层（默认，层分给不同卡，带宽可相加）与 vLLM 张量并行（切矩阵，通信吃 PCIe）。加卡最稳的收益是「装得下更大的模型」，速度翻倍要看互联。

先分清两种多卡：① **拆层（layer split）**——llama.cpp 的默认行为，`--split-mode layer` 把不同的层放到不同卡上，权重读取带宽可以相加；用 `--tensor-split` 指定比例。② **张量并行（tensor parallel）**——vLLM 的 `--tensor-parallel-size N`，把一个矩阵切开分到多卡，每层都要通信，互联不够快就白搭。

速度不会翻倍，站内实测给了几组对照：① NVIDIA RTX 3090 24G 单卡 TP=1 Q4_K_M 46.9 tok/s（ctx 32K），同一基准库目录横切的 TP2 / TP4 单流是 76.4 / 78.7——加卡从 1 张到 2 张涨一截，从 2 张到 4 张几乎不再涨。② 2×3090 NVLink 跑 MiniCPM-V-4.7-35B int4，TP2 plain 单流 172.2 tok/s；同样两张 3090 但走 PCIe 互联，Qwen3.8-27B AWQ 32K 只有 45 tok/s。③ 2×P100 16G（无 NVLink、无 P2P，第二张卡挂在芯片组后走 PCIe 3.0 x4）跑 Qwen3.8-27B UD-Q6_K，plain decode 31.1 tok/s，开 MTP 后 54 tok/s。

上下文越长，多卡的差距越难看：同一条 2×3090 PCIe 的曲线，32K 是 45 tok/s，524K 掉到 6 tok/s，作者标「稳定」。KV 是每层每 token 都摊的，加卡不改变这个斜率。

加卡最实在的收益是容量：站内 2×NVIDIA RTX 5070 Ti 16G TP2 跑 Qwen3.8-27B NVFP4，64K 上下文单流 64 tok/s，每卡显存明细是权重 11.3 GiB + KV 1.51 GiB + CUDA graphs 0.14 + 激活 1.43，合计 14.4/15.47 GiB——这是「消费级 24G 总显存跑新代际 27B」的代表配置。另一头，4×3090 TP4 跑 Ling-3.0-flash INT4 单流 100.43 tok/s，16 并发聚合 295.94 tok/s（折合每请求 18.5 tok/s）——单流和聚合不是一回事，别混用。

怎么配（按目的）：① 只是想装下更大的模型 → 拆层最省事，两张同卡容量直接相加；② 想更快 → 看互联有没有 NVLink，没有 NVLink 的 PCIe 多卡通常不如换一张大卡；③ 笔记本别指望外接多卡提速，通道更窄；④ 上手顺序：先用一张卡把模型跑通，再加第二张，先试 llama.cpp 的 `--split-mode layer --tensor-split 1,1`，再考虑 vLLM 的 TP。

Question 37

首次部署要不要上 Docker？

Accepted Answer

不要。先在宿主机裸跑通一个模型（llama.cpp 单文件二进制），再容器化。容器解决的是环境隔离与可复现，不会让模型跑得更快。

结论先行：首次部署先裸机。Docker 的收益是「环境隔离、可复现、多人访问同一个服务」，不是速度；新手在容器里排错（CUDA 看不到卡、版本对不上、挂载路径错）的时间成本远大于收益。

容器确实是主流部署方式，本站他测条目里就有不少跑在容器里：Unraid + Docker（驱动 580 / CUDA 12）、Docker CUDA-devel 容器、DGX Spark 上的 vLLM 容器镜像（spark-vllm-docker）——共 7 条条目的系统口径写着 Docker。也就是说它没问题，只是不该是你的第一步。

上容器要准备的东西：① NVIDIA Container Toolkit（容器内才有 GPU）；② 镜像与驱动要匹配（容器里的 CUDA runtime 不必跟宿主完全一致，但驱动得够新）；③ 模型文件用挂载（-v）而不是打进镜像；④ Windows 上是 Docker Desktop + WSL2 的 GPU 直通路径，和 Linux 原生不是一回事。

什么时候容器是对的：同一台机器要跑多套互不干扰的版本（不同 CUDA、不同 PyTorch）、要把推理服务标准化部署给多个人用、要可复现地重装一次环境。

排查顺序建议：先在宿主机用官方预编译包跑通（llama.cpp 的单文件二进制最省事），确认卡、驱动、模型文件都正常，再搬进容器；容器里出的问题优先怀疑版本与挂载，而不是模型。

Question 38

驱动和 CUDA 版本怎么选？要自己装 CUDA 吗？

Accepted Answer

不用自己装 CUDA。驱动装新一点，框架用官方预编译包；CUDA 版本只有自编扩展时才需要管。站内他测最常见的口径是驱动 580 + CUDA 12。

结论先行：普通用户只要三样——最新稳定版驱动、框架官方预编译包、模型文件。CUDA Toolkit 本身不用装（驱动里已经有 runtime），PyTorch 的 pip 包也自带 CUDA runtime。

什么时候才需要关心 CUDA 版本：自己编译带 CUDA 扩展的项目、需要和特定框架版本对齐（老项目锁 cu118 / cu121）、或在报 CUDA 版本的错配错误。站内他测条目里最常见的系统口径是「驱动 580 / CUDA 12」（8 条条目这么写），但那是作者环境，不是要求你跟。

驱动版本的原则：越新越好，但有两个例外——一是老卡（如 Pascal 架构的 P100 / P40）在新驱动上可能被砍支持，这时要回退到仍支持该架构的版本；二是生产环境别追最新，等一个版本跑稳了再升。

典型症状对照：装完 nvidia-smi 正常但框架报找不到 CUDA → 版本错配或容器缺 toolkit；nvidia-smi 直接报错 → 驱动没装好或没重启；跑起来特别慢且显存占用异常 → 先看是不是走了 CPU offload（看启动日志的 offload 行数）。

遇到「起不来」的报错，去本站故障排查按报错原文搜（驱动不匹配、框架版本混装、环境变量把卡藏起来了各有各的症状）；把 nvidia-smi 输出、框架版本、启动命令贴出来，比描述「跑不起来」有用得多。

Question 39

温度、top-p、重复惩罚这些参数到底怎么调？

Accepted Answer

温度管随机性（0 = 贪心、最稳）、top-p 管候选范围、重复惩罚管复读。它们只影响输出分布，不影响显存占用和速度——换参数不会让模型跑得更快。

结论先行：这三个参数只改输出分布，不改显存、不改速度。先把量化档和上下文定下来，再调采样。

温度（temperature）：0 是贪心解码，每步选概率最高的词，同一输入同一输出、可复现；越高越随机。日常聊天 0.7–0.9，代码补全与结构化抽取 0–0.3，做基准测试固定 0——站内那组 NVIDIA RTX 4090 24G 的 ExLlamaV3 实测就是 temperature 0，六档 needle 全部 PASS。

top-p（核采样）：只从累计概率前 p 的候选里挑，p=1 是全放开；和温度一起用，一般 top-p 0.9 配温度 0.7–0.9。小模型通常把 top-p 收到 0.9 以下更稳。

重复惩罚（repeat penalty）与频率 / 存在惩罚：抑制复读。调过头会伤数学与代码——数字、公式、变量名本来就该重复出现，惩罚太狠会改写答案。经验值是 1.05–1.1，别往 1.3 以上调。

thinking / 推理模式另说：开了之后模型会先写一长串思考过程，这部分 token 照样算进上下文预算、照样占 KV，还会让首字延迟变长。本站的排查条目里专门有一条「thinking 吃掉 token 预算」。

Question 40

为什么刚开始聊得挺快，聊久了就变慢？

Accepted Answer

因为每生成一个 token 都要把历史 KV 重读一遍，KV 随上下文线性增长。同一台 4090 实测：1K 上下文 145.2 tok/s，64K 掉到 111.3 tok/s。

结论先行：变慢不是「机器老了」，是 KV 越存越多——每生成一个新 token，模型要把全部历史 KV 重读一遍，注意力的工作量随上下文线性增长。

站内有一组同配置实测（第三方单源，C 级）把这条曲线量了出来：NVIDIA RTX 4090 24G + ExLlamaV3 跑 Mimo-9B，单流 decode，1K 上下文 145.2 tok/s，4K 144.1，8K 140.5，16K 137.3，32K 127.2，64K 111.3 tok/s（KV FP16、无投机解码、无 CPU offload，每档都跑了 needle 正确性校验）。

本站自测的 NVIDIA Tesla V100 32G（数据卡） 上下文扫描同向：Qwen3.8-27B Q4_K_M 从 512 token 的 16.47 tok/s 一路掉到 256K 的 4.8 tok/s；Ornith-1.5-35B-A3B Q4_K_M 从 93.4 掉到 22.99。上下文越长，每 token 越贵——这是结构决定的，不是调参能解决的。

三个能立刻做的动作：① 长对话开新会话，别让历史无限累积；② KV 量化（llama.cpp 的 -ctk q8_0 -ctv q8_0 减半、q4_0 减到四分之一）；③ 换 KV 便宜的架构（层数少、KV 头少、带滑窗的模型）。注意 KV 量化会略微增加注意力开销，收益主要在「装得下」而不是「跑更快」。

区分两种慢：一种是「越聊越慢」（KV 越来越重，本条讲的），另一种是「越用越慢」（显存碎片、温度墙、后台任务，属于故障排查里的另一条）。别把两者混为一谈。

常见问题

起步概念

选卡与预算

装与跑

用法与提速

数据口径

读完了，下一步

先看你的显存是几档

跑起来但出问题了

这些数字凭什么可信