llama.cpp 从首次跑通到多机迁移的本地推理落地指南【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cppllama.cpp 是用 C/C 写的本地大模型推理框架把 GGUF 格式的模型跑在 CPU 与 GPU 上支持 1.5 到 8 位量化离线部署与边缘设备场景常用。本文只解决三件事第一次在本机跑通模型、把模型接进服务或迁到新机器、加载报错时按关键字定位。最容易卡住的往往不是编译而是模型加载——启动日志里那几行字段决定了下一步走哪条命令先建立判断再动手。 第一次在本机跑通模型官方路径是llama cli -hf直接指定 Hugging Face 仓库拉取 GGUF 并运行省掉手动下载与格式转换两步。llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF加载阶段记下三行日志arch字段确认架构被识别、n_gpu_layers确认卸载层数、llama_print_timings里的eval time确认进入解码。跑通的标准是补全输出连贯且不报unsupported tensor typellama cli -hf ggml-org/Qwen3.5-0.8B-GGUF -p 用一句话介绍 llama.cpp -n 64 把模型接进服务llama serve起的是 OpenAI 兼容 API第三方客户端可以直接指向它不需要改请求格式。llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF --port 8080验证用/v1/models接口返回含模型名的 JSON 即服务就绪curl http://127.0.0.1:8080/v1/models客户端连不上时看启动日志中listening on一行的实际地址通常是绑定到 localhost 或端口被占用。 换机器迁移基准对比定位掉速迁移要过的不是文件拷贝而是后端一致性。llama-bench输出带backends、n_gpu_layers与t/s三列两机对照这三列就能定位掉速来源原机跑基准记下pp512与tg128的t/s拷贝.gguf与.ggufmmproj 到新机新机重跑同一条基准对照三列。llama-bench -m 模型.gguf -p 512 -n 128掉速最常见的两种二进制没编进 GPU 后端backends列只剩 CPU新机器核数少-t线程数照抄旧值。按目标后端对照 docs/build.md 里的编译选项处理。 多模态与移动端落地mmproj 是独立的 GGUF 文件必须与主模型同架构、同来源配对用 convert_hf_to_gguf.py 的--mmproj从同一仓库一次转出只换主模型留旧 mmproj加载会直接报错。llama-mtmd-cli -m 模型.gguf --mmproj mmproj.gguf --image tools/mtmd/test-1.jpeg输出里出现图中报纸标题等内容的描述多模态链路才算通。mmproj 的获取方式见 tools/mtmd/README.md。移动端是另一条路Android 示例经 CMake 交叉编译出 AAR导入工程后 Gradle 构建日志出现BUILD SUCCESSFUL且列出 CPU 后端变体即成功。 加载报错按关键字排查按关键字对号入座比从头翻日志快报错关键字可能原因修复操作unknown architecture该架构是新版才支持升级到包含该架构的二进制unsupported tensor type老量化档位新版不认用llama-quantize重新量化到Q4_K_Mmmap相关磁盘空间不足或映射受限加--no-mmap禁用映射临时绕过mmproj相关视觉编码器与主模型不配套用--mmproj从同一仓库重出connection refused服务没起或端口被占看启动日志listening on再查端口多数加载失败落在前两行量化与架构问题优先于环境问题。后续资源docs/build.md 按后端查编译选项docs/models.md 查架构与量化支持仓库 Releases 页读版本变更说明Discussion 讨论区提问。最小可运行命令从拉取到出字一步完成llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考