在 Linux 服务器上跑本地大模型：systemd 托管、GPU 实测，和 vLLM 与 llama.cpp 的分岔口

2026-10-23 约 34 分钟阅读

上周在 SSH 里跑得好好的模型，重启之后没了进程；或者服务还在，但每个回答慢得像在等拨号，也没人说得清权重到底在显存里还是一半躺在内存里。

💡 你将学到

上周在 SSH 里跑得好好的模型，重启之后没了进程；或者服务还在，但每个回答慢得像在等拨号，也没人说得清权重到底在显存里还是一半躺在内存里。

📜 目录

先确认卡是活的，再装任何东西
装完先读它生成的 systemd 单元
几个默认值藏着坑
用 API 数字判断，不靠手感
什么时候该换成 vLLM
判断标准
站内相关

上周二问它一个九百 token 的问题，两秒就答完；这周二同一个问题要等十一秒，风扇不响，nvidia-smi 显示显卡占用只有 3%。日志里没有任何报错。这就是大部分「Linux 上跑本地大模型」问题的真实形态：不是崩溃，而是悄悄从 GPU 降级到更差的地方，外面套着一个没人认真配过的服务。

先确认卡是活的，再装任何东西

顺序错了，就会花一小时怀疑模型，其实问题是驱动。nvidia-smi 能报出型号和显存总量，才谈得上后面的事；容器里还要多一层 nvidia-container-toolkit。把显存总量记下来，后面所有容量决策都是从它往下扣，不是从包装盒上的宣传数字扣。

装完先读它生成的 systemd 单元

官方安装脚本会注册 ollama.service，以专用 ollama 用户运行，模型默认落在 /usr/share/ollama/.ollama/models。云主机系统盘常常只有四十来 G，几个 8B 模型就能塞满，表现是下载到一半报磁盘错误，而不是提示空间不足。先把模型目录挪到数据盘，再把新路径写进 systemd 的 drop-in 覆盖文件，别直接改厂商的单元文件——升级会覆盖。

几个默认值藏着坑

下面这些默认值来自 Ollama 官方 FAQ 文档，值得抄进覆盖文件里重新定：OLLAMA_NUM_PARALLEL 默认 1，一个人用完才轮到下一个；OLLAMA_MAX_LOADED_MODELS 默认是显卡数乘 3；OLLAMA_MAX_QUEUE 默认 512，把过载藏成排队；OLLAMA_KEEP_ALIVE 默认 5 分钟，喝杯咖啡回来就要重新冷加载；OLLAMA_KV_CACHE_TYPE 默认 f16，改 q8_0 大约省一半 KV 显存；OLLAMA_HOST 不设就不对外暴露。

最容易踩的是并发与上下文的乘法：4K 上下文开 4 路并发，占的是 16K 的 KV 缓存，显存翻倍但模型没变，这就是「昨天还好好的」最常见的原因。

用 API 数字判断，不靠手感

ollama ps 的 PROCESSOR 列会写清楚是 100% GPU 还是 60/40 CPU/GPU 混合——混合就是慢的原因。真正的性能要读生成接口返回的计数：eval_count 除以 eval_duration 是生成速度，prompt_eval_count 除以 prompt_eval_duration 是预填充速度，load_duration 大说明每次都在重新加载模型。四个数字对应四种病因，跑两遍就能区分是磁盘慢还是显存不够。

什么时候该换成 vLLM

单流速度和真实并发是两件事。二十个人共用一个端点、每个人都要等一整个回答生成完才轮到下一个时，瓶颈在调度不在显卡，这时候上 vLLM（PyPI 0.32.0，Apache-2.0）才有意义：连续批处理加 PagedAttention，接口兼容 OpenAI 协议。三个参数要留意：--gpu-memory-utilization 是允许占用的显存比例，拉太满这台机器就干不了别的；--max-model-len 超过训练长度会产出质量下降的结果而不是报错；--tensor-parallel-size 必须等于真实卡数。

判断标准

卡小、显存是硬约束，或者目标根本不是服务器，用 llama.cpp；十来个用户、一两个模型，Ollama 一个下午就能上线；有产品在调端点、队列开始排长队，才轮到 vLLM。迁移的信号是可测量的：当队列深度或 p95 延迟涨得比请求量快，引擎才是问题。在那之前换引擎，是用一周时间修一个还没遇到的瓶颈。

最后补一张重启清单：systemctl enable、模型放数据盘、端口前加防火墙和鉴权、日志设上限、模型标签写死、留一个两 token 的健康检查、把第一次测得的那四个数字连日期一起记下来——下次有人说「变慢了」，这就是基线。