很多人本地跑模型第一步就卡住：从模型站下了个权重，扔进 llama.cpp 直接报错，或者能加载但输出乱码、速度慢得离谱。问题多半不在 llama.cpp，而在格式对不对、量化档位和你的硬件配不配。这篇不重复部署步骤，只讲清楚它支持什么、不支持什么，以及怎么在下模型之前就把能不能跑判断出来。
很多人本地跑模型第一步就卡住：从模型站下了个权重，扔进 llama.cpp 直接报错，或者能加载但输出乱码、速度慢得离谱。问题多半不在 llama.cpp 本身，而在格式对不对、量化档位和你的硬件配不配。这篇不重复部署步骤，只讲清楚它支持什么、不支持什么，以及怎么在下模型之前就把能不能跑判断出来。
判断思路其实很简单：先看文件能不能被加载器认出来，再看你的机器能不能扛住这份权重。下面按「格式边界 → 主流模型系族 → 下载前核对 → 出错排查 → 清单失效场景」的顺序走一遍，每一步都给你能直接动手的动作。
先分清：llama.cpp 支持的是格式，不只是模型名
llama.cpp 的核心加载格式是 GGUF，这是它自己的容器格式。你在模型站看到的 safetensors、PyTorch 原始权重、或者一堆 .bin 分片，通常不能直接塞进去，得先走「转换 → 量化 → 再加载」这条链路。所以第一步永远不是问「这个模型支持吗」，而是问「这个文件是什么格式」。
| 文件类型 | 能否直接加载 | 正确处理方式 |
|---|---|---|
| GGUF | 可以直接加载 | 确认量化档位与后端兼容 |
| safetensors | 一般不能 | 先转成 GGUF 再量化 |
| PyTorch 原始权重 | 一般不能 | 先转成 GGUF 再量化 |
| 仅含图像/音频分支的权重 | 不能 | 纯文本加载器吃不下多模态分支 |
- GGUF 是容器格式，同一个模型可以有多个量化档位，文件名里通常带量化标记，档位不同体积和效果都不同
- 看文件后缀和元信息，比看模型名字靠谱得多；名字一样但格式不对，照样加载失败
- 遇到非 GGUF 权重，正确路径是先转换再量化，不是改后缀硬塞进加载器
- 转换脚本和量化工具本身也可能对架构有要求，老工具处理不了新架构是常态
主流模型清单：按架构系族来看，别逐个记名字
与其背几百个模型名，不如按架构系族理解。通用指令和对话类开源系族基本都有社区转换版本，常见的 Llama 系、Qwen（千问）系、Mistral 系、Gemma 系、Phi 系都属于这一类。名字会变，架构思路相近，支持情况也往往是成批出现的。
代码向和中文向模型通常发布后不久就有 GGUF 版本，但转换节奏取决于社区而不是官方，所以「官方发了」和「llama.cpp 能跑」之间有时间差。至于多模态、语音、生图这几类，要单独确认，纯文本加载器处理不了图像或音频分支。
- 通用指令/对话系族
- 社区转换最积极的一类，GGUF 版本基本不愁找不到
- 代码与中文向模型
- 发布后往往很快有 GGUF，但取决于社区，别默认一定有
- 多模态/语音/生图
- 要单独确认，纯文本路径通常无法直接使用
- 新架构首发
- 容易缺支持，遇到报错先怀疑版本太新，而不是模型本身有问题
下载前的三步核对清单
把判断提前到下载之前，能省掉大量重复下载。按下面四步走，每一步都有明确的验证动作，任何一步对不上就先停手，不要抱着「下完再说」的心态。
- 第一步：查格式确认文件后缀与量化标记，别把训练权重当推理权重下。看到 safetensors 就先准备好转换工具链。
- 第二步：查支持列表到 AI 模型库（/models） 核对当前收录与标注的可用信息，确认这个系族是否已被覆盖。
- 第三步：查硬件按参数量与量化档位估显存和内存，到 部署测算（/models/deploy） 与 几张卡够用（/compute/sizing） 对一遍，把具体数字以站内当时显示为准。
- 第四步：查许可证能不能商用跟能不能跑是两件事，授权范围要单独看，别把「能加载」当成「能上线」。
- 任何一步对不上，先停下来换文件或换档位，别先下载几个 G 再说
- 硬件测算的结果和实际会有偏差，留出余量比算得刚好更稳
- 许可证条款按你实际使用场景判断，个人试用和企业部署不是一回事
跑不起来时的排查顺序
报错信息往往不直接告诉你原因，按固定顺序排查能少走弯路。先从最外层、最容易改的开始，逐层往里收，不要一上来就去改量化参数。
- 先看版本：llama.cpp 迭代快，老版本对新架构支持常缺失，先升级再判断
- 再看量化档位：低比特量化在某些硬件后端上可能不被支持，换个档位测试
- 然后看内存/显存：加载成功但推理中断，通常是内存不够而不是模型不支持
- 最后看样例：先用小参数量模型验证链路通了，再换大的，别一上来就啃最大的
需要说明的是，这份排查顺序有不适用的场景：如果你要的是高并发、批量吞吐，本地单机推理框架本身就不是合适选择，这时候该去看专用服务框架，而不是继续在 llama.cpp 上折腾。
什么时候这份清单不够用
列表和清单都有保质期。模型迭代频繁时，任何静态清单都会过期，所以真正该养成的习惯是查站内模型库和榜单，而不是把某一篇结论背下来。下面几种情况，格式支持只是入门门槛，判断逻辑要往上抬一层。
| 你的需求 | 格式支持够不够 | 该看什么 |
|---|---|---|
| 单机试跑、个人验证 | 够 | 格式 + 硬件测算 |
| 长上下文、超大参数量 | 不够 | 内存与显存上限会先暴露 |
| 持续在线服务 | 不够 | 服务框架与并发能力 |
| 模型频繁更换 | 不够 | 动态来源，而非固定清单 |
另外，判断支持与否时也别只看「能不能加载」。能加载不等于跑得动，跑得动不等于跑得舒服。参数量、上下文长度、后端类型都会影响最终体验，这些去站内对应页面按当时的标注核对更靠谱。
下一步把你手上那个模型名和后缀拿出来，去模型库核对当时收录的格式与部署标注，确认能跑再下载。→常见问题
llama.cpp 只能跑 GGUF 吗？
日常使用基本是围绕 GGUF 展开的，加载器认的就是这个容器格式。如果你手上是 safetensors 之类的原始权重，正常做法是先转成 GGUF 并按硬件选量化档位，再喂给它。直接扔原始权重通常不是报错就是加载失败，别在这条路上耗时间。
为什么同一个模型有人能跑、我这边加载就报错？
最常见三个原因：一是版本差异，新架构需要较新的构建；二是量化档位和你的硬件后端不匹配，换个档位往往就好了；三是内存或显存不够，表现成加载中断。按这两条顺序排查：先升级版本、再换量化档位、最后核对硬件余量。
怎么知道某个新出的模型能不能跑？
别信口头说法，按动作来：先看有没有对应的 GGUF 转换版本，再到站内 AI 模型库（/models） 核对收录与标注信息，然后用小参数量版本做一次链路验证。新架构发布初期支持常常滞后，隔一段时间再看会比立刻硬啃省事。
