手上只有一台带独显或核显的普通电脑，想试 llama.cpp，结果卡在不知道下哪个权重文件、编译报错、跑起来慢得离谱——这几个坑基本人人都会踩一遍。这篇按实际操作顺序走：先确认硬件和文件格式，再编译和启动，最后用一套固定步骤验证跑没跑对、慢在哪里。不承诺任何速度数字，只给判断依据和排查顺序。
手上只有一台带独显或核显的普通电脑，想试试 llama.cpp，结果往往卡在三个地方：不知道下哪个权重文件、编译时报一串看不懂的错、好不容易跑起来却慢得离谱。这些坑基本人人都会踩一遍，问题不在你笨，而是 llama.cpp 的门槛集中在前期准备和第一次启动这两步。
下面按真实操作顺序走：先确认硬件和文件格式，再编译和启动，最后用一套固定步骤验证跑没跑对、慢在哪里。全文不承诺任何速度数字，只给判断依据和排查顺序；具体指标到站内对应页面核对当时的数字。
上手前先对齐三件事：硬件、量化文件、目录结构
第一步永远是算账，不是下载。显存和内存要按参数量和量化档位粗算一遍，看看手上这台机器能吃下多大的模型。别凭感觉估，去站内部署测算页输入设备情况对当时的数字；算出来不够，就先降一个量化档位，或者直接换小参数模型，硬上只会反复崩溃。
| 要确认的事 | 怎么确认 | 不够时的处理 |
|---|---|---|
| 显存/内存能否装下 | 按参数量加量化档位粗算，去 /models/deploy 核对 | 降量化档位或换小参数模型 |
| 文件是否为 GGUF | 看文件名和仓库说明，认准带量化标记的单文件 | 换仓库或重新下载对应文件 |
| 分片文件是否齐全 | 对照仓库文件清单逐个比对 | 缺片会导致加载失败，全部下齐 |
| 运行环境和依赖 | 确认驱动、编译工具链版本可用 | 先补齐环境再编译 |
权重格式这点最容易翻车。同名仓库里常挂着好几种文件，有的是训练用格式、有的是转换脚本产物、有的才是能直接喂给 llama.cpp 的 GGUF。认准单文件加量化标记，分片的要把所有分片下齐，少一片就会在加载阶段报错。哪种量化档位在质量、显存、速度之间怎么取舍，可以到 /tools 里的换算和检测工具对照，硬件名词不清楚就去 /ai-dict/category/hardware 查。
- 建一个固定目录，模型放 models 子目录，编译产物放 build 子目录，日志单独存
- 模型文件名保持原样，别改成看不懂的缩写，后面排错要靠它对照
- 启动脚本也放进目录，参数一改就存一版，方便回退
- 磁盘预留足够空间，分片模型加上编译缓存占的地方不小
编译与首次启动：把参数压到最少
- 优先用预编译包先看官方 README 有没有现成包，能直接用就别自己编，省掉一半排错时间。
- 自编译选对后端CPU 指令集和 GPU 后端（CUDA、Metal、Vulkan）都要对上，后端选错会表现成装好了但只用 CPU 在跑。
- 首次启动只给必需参数模型路径、上下文长度、GPU 卸载层数三项就够，其余先不碰，跑通再逐项加。
- 卸载层数从保守值起边加边看显存占用，崩了就往回退，记下稳定与崩溃之间的那个拐点。
- 先本机监听起服务模式时地址先设成本机，确认能用再考虑开给局域网，暴露出去的注意事项见 /ai-dict/category/infra。
第一次启动的目标不是跑得快，而是跑得起来。参数给得越少，出问题时变量越少。建议把第一次启动的命令原样记下来，后面每次加参数都在这个基础上加一项，出问题回退一步就能定位。
# 示意，具体参数名以你使用的版本说明为准
./llama-server -m ./models/your-model.gguf -c 4096 -ngl 20 --host 127.0.0.1跑通之后：怎么判断跑得对、慢在哪
能出字不代表跑对了。先做一致性检查：同一个提示词跑两次，看回答风格和长度是否稳定。输出乱码、突然截断、答非所问，多半是量化文件损坏，或者上下文长度设超了模型能处理的范围。这一步花几分钟，能省掉后面大量瞎调参数的时间。
确认输出正常后再找瓶颈。慢通常是三件事之一：显存不够导致大量层被丢给 CPU、上下文给太长、线程数没配好。三者调法完全不同，先判断属于哪种再动手，别一股脑全改。
- 一致性检查
- 同提示词跑两次看输出是否稳定，判断模型文件有没有问题
- 卸载比例
- 看日志里有多少层真正跑在 GPU 上，比例低说明瓶颈在显存
- 上下文长度
- 超长上下文会明显拖慢并吃显存，先降到常用值再测
- 线程数
- CPU 侧线程给太多会互相抢资源，通常设成物理核数附近再微调
速度只和自己在同一台机器上的基线比。先在 /tools/speed-test 建一个本机延迟基线，以后换模型、改参数都拿它对照，别拿别人的数字对标，机器不一样没有可比性。长期使用建议固定一套启动参数脚本，换模型时只改路径，避免每次都从头试参数。
出问题按这个顺序查，别乱试
排错最怕同时改三样东西。下面这个顺序是从最外层往内层查，每一步都有明确的停止条件：停在哪一步，就说明问题出在哪一层，别跳到后面去折腾。
- 一看模型文件：路径、完整性、是否 GGUF，报错含格式关键字就停下
- 二看后端：日志里有没有加载到 GPU，没加载上是编译选项或驱动问题
- 三看资源：显存、内存、交换分区，被别的程序占着也会表现成模型崩
- 四再看参数：上下文长度、批大小、线程数，一次只改一个并记录
这个顺序的不适用场景也要说清：如果你是从别人那拷来的整套配置、机器也一样，那先整体复现再逐项改；如果你在共享服务器上跑，资源被占用的概率高，可以先跳到第三步看资源。
下一步先算出你的设备能装下哪个档位的模型，再动手下载和编译，能省掉大半返工。→常见问题
llama.cpp 和 Ollama 到底什么关系，我该用哪个？
Ollama 底层就用到 llama.cpp 这一类推理能力，只是把模型下载、参数管理包好了，适合不想折腾的人。llama.cpp 给你的是更细的控制权和更少的中间层，代价是编译、参数、排错都得自己来。只想快速聊天就用前者，想调卸载层数、换量化档位、接进自己的程序就用后者。两者分工和差异站内有专门文章对比，这里不重复。
没有独立显卡，纯 CPU 能跑吗？
能跑，但要接受速度上的落差，且只适合小参数量或较低量化档位的模型，同时内存要留足。这种情况下优先控制上下文长度并减少并发，否则体验会很差。如果任务本身对延迟敏感，这条路不适用，不如按用量调 API。
跑起来后回答质量明显变差，是模型不行吗？
先排除三件事：量化档位是不是压得太狠、上下文是不是被截断、提示词模板有没有按模型要求正确拼接。前两个会直接伤质量，模板拼错会让模型答得莫名其妙。这三项都正常再去怀疑模型本身，换档位对比一次就能看出来。
