llama.cpp 容器部署实操:一条 Docker 命令拉起可调用的 LLM 推理服务
【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp
想让机器上立刻多出一个随时可调用的 LLM 推理服务,却不想自己写部署代码?一次 llama.cpp Docker 部署就够了:它是纯 C/C++ 的推理引擎,不依赖 Python 环境,容器化之后,任何装了 Docker 的机器上同一条命令都能原样跑起来,直接得到一个 HTTP 推理服务。
预检:开跑前确认三件事
动手前依次核对三点,缺一项都会在后面对不上:
- Docker:
docker --version能输出版本号、守护进程在运行即可。 - 硬件与内存:物理内存要能装下模型文件并留足余量;8GB 内存跑 Q4_K_M 量化的 7B 级模型没问题。
- 模型格式:llama.cpp 只吃 GGUF 文件。⚠️ 手上是 PyTorch 或 ONNX 权重就先转换,否则容器会直接拒载。
最小可用服务:一条命令起 CPU 推理并当场验证
用最小的servertag 镜像,宿主机 8080 端口直通容器,把本地模型目录挂进容器/models:
docker run -d --name llama-server \ -p 8080:8080 \ -v ./models:/models \ ghcr.io/ggml-org/llama.cpp:server \ -m /models/model.gguf \ --host 0.0.0.0 --port 8080命令跑完验证两步:curl http://localhost:8080/health返回{"status":"ok"}即就绪;浏览器打开http://localhost:8080/是自带的 Web 聊天页,不写一行代码就能和模型对话。
镜像选型表:CPU、CUDA、ROCm 四张 tag 对号
先选镜像再谈调优,硬件与官方 tag 的对应关系如下:
| 硬件 / 目标 | 镜像 tag | 前置条件 | 平台限制 |
|---|---|---|---|
| 无 GPU,纯 CPU 推理 | ghcr.io/ggml-org/llama.cpp:server | 无 | 无 |
| 额外要模型转换、量化工具链 | ghcr.io/ggml-org/llama.cpp:full | 无 | 无 |
| NVIDIA GPU | ghcr.io/ggml-org/llama.cpp:server-cuda | 宿主机装 nvidia-container-toolkit | 无 |
| AMD GPU | ghcr.io/ggml-org/llama.cpp:server-rocm | GPU 暴露给容器(--gpus all) | ⚠️ 仅 amd64 |
GPU 镜像都靠--gpus all生效;判断标准是启动日志出现 GPU 设备初始化,只有 CPU backend 时先查容器工具包是否缺装。更多 tag 见 Docker 文档。
提速杠杆:上下文、线程、GPU 层数与量化精度四个旋钮
四个旋钮各拧一下即可:
-c上下文长度:直接决定内存占用,建议 4096,内存紧张就往下降。-t线程数:CPU 参与计算的线程,填物理核心数;调完用top看一眼线程是否吃满。--n-gpu-layersGPU 层数:卸载到显存的层数,先试 99,显存 OOM 再逐步调低;7B Q4_K_M 在 8GB 显存基本全放得下。- 量化精度:同样影响内存与显存,内存紧张选 Q4_K_M 这一档低精度。
推理本质是连续的大规模矩阵运算,这些旋钮只决定每轮算完后怎么从概率分布里挑下一个 token。成功标准:补全请求首 token 一秒内返回。
业务接入:原生与 OpenAI 兼容接口的两条 curl
两种调法都能直接照抄:
原生补全——prompt 自己拼好,模型直接续写:
curl http://localhost:8080/completion \ -H "Content-Type: application/json" \ -d '{"prompt": "用一句话介绍 llama.cpp", "n_predict": 64, "stream": false}'OpenAI 兼容接口——现有 OpenAI SDK 的代码把base URL指到这个服务即可:
curl http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"messages": [{"role": "user", "content": "你好"}], "max_tokens": 64}'常用采样参数:
| 参数 | 含义 | 建议值 |
|---|---|---|
temperature | 采样随机性,越高越发散 | 创作 0.7 / 问答 0.1 |
top_p | 核采样阈值,只在累计概率 p 内选 token | 0.9 |
n_predict/max_tokens | 单次最多生成的 token 数 | 按需限死,别吃满上下文 |
stream | 是否逐 token 流式返回 | 前端体验选 true |
repeat_penalty | 对重复内容的惩罚 | 1.1 |
成功标准:响应体带content字段,流式请求能看到 token 逐个输出。
长期稳定运行:带健康检查与日志轮转的完整 Compose 配置
要长期跑,把命令写进 Compose,自动重启、日志轮转、健康检查一次配齐:
services: llama-server: image: ghcr.io/ggml-org/llama.cpp:server restart: unless-stopped ports: ["8080:8080"] volumes: ["./models:/models"] logging: driver: json-file options: {max-size: "10m", max-file: "3"} command: -m /models/model.gguf --host 0.0.0.0 --port 8080 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s retries: 3docker compose up -d启动后,docker compose ps显示healthy就算稳了;显式健康检查让镜像升级时行为不漂移,restart: unless-stopped保证机器重启后服务自动回来。监控方面,Prometheus 直接抓内置/metrics端点即可。
报错自查:现象-原因-动作三要素定位六类高频故障
先按下表比对,多数问题三分钟定位:
| 现象 | 原因 | 动作 |
|---|---|---|
| 容器启动即报找不到模型文件 | 容器内路径写错 | 检查-v挂载,容器内路径必须以/models/开头 |
| 日志只有 CPU backend,GPU 没生效 | 宿主机缺 nvidia-container-toolkit | 装好工具包,用docker run --gpus all <镜像> nvidia-smi验证 |
| 容器被 OOM 杀掉 | 上下文过长或 GPU 层数过多 | 调小-c,调低--n-gpu-layers,或换更低量化 |
| API 返回 401 | 服务端开了--api-key但请求没带 | 启动参数与请求头带上同一个 key |
| 其他机器连不上端口 | 只绑了 127.0.0.1 或防火墙拦截 | 改--host 0.0.0.0并在防火墙放行端口 |
| 前几分钟响应极慢 | 模型仍在加载 | 等日志出现加载完成再发请求 |
对照完,直接执行docker compose up -d重启服务,再用docker compose ps确认状态回到 healthy。
【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考