当前位置：首页 > news >正文

本地大模型部署实战：硬件适配、量化调优与llama.cpp全流程指南

news 2026/6/18 15:23:16

1. 这不是“选模型”，而是“搭一套能干活的本地AI系统”

“目前有什么可以本地部署的大模型推荐？”——这句话我每天在技术群、论坛、私信里看到不下二十遍。但说实话，问出这个问题的人，十有八九还没想清楚：你到底要它干什么？是想让家里老旧笔记本跑个聊天助手，还是给公司内部知识库配个不联网的问答引擎？是要写小说润色文案，还是解析几百GB的PDF合同提取条款？甚至只是想搞懂Transformer到底怎么算注意力权重？

本地大模型不是App Store里点一下就装好的APP，它是一整套需要你亲手调试、裁剪、喂养、看护的AI基础设施。核心关键词——本地部署、大模型、推理、量化、硬件适配、上下文长度、显存占用——每一个词背后都连着一堆现实约束：你手头那张3060显卡只有12GB显存，却想跑70B参数模型；你用MacBook M2 Pro，没CUDA但Metal加速刚起步；你公司IT政策严禁任何数据出内网，连Hugging Face Model Hub都得镜像到内网NAS上……这些不是“小问题”，而是决定项目成败的第一道门槛。

我过去三年带过17个本地大模型落地项目，从高校实验室的4卡A100集群，到律所合伙人放在办公桌下的NUC11迷你主机，再到制造业工厂车间里连WiFi都不稳定的老式工控机。踩过的坑比模型参数还多：显存爆到蓝屏、量化后输出全乱码、中文长文本直接截断、API服务跑两天就内存泄漏……所以这篇不列“Top 10模型排行榜”，也不甩一堆GitHub链接让你自己编译。我要带你从零开始，像修一台发动机那样，把本地大模型部署这件事——拆成可测量、可替换、可验证的物理模块：硬件层（你有什么）、软件层（你要装什么）、模型层（你能跑多大）、应用层（它到底能干啥）。每一步都附真实配置、实测数据、失败截图和绕过方案。你可以直接抄作业，也可以根据自家设备改参数。毕竟，没有“通用推荐”，只有“对你管用的方案”。

2. 硬件与软件：先看清你的“地基”，再谈盖楼

2.1 显卡不是越大越好，而是“够用+省电+散热稳”才是王道

很多人一上来就问：“RTX 4090能跑Qwen2-72B吗？”——这问题本身就有陷阱。显卡性能不能只看显存大小，得看三件事：显存带宽、计算精度支持、驱动生态稳定性。

显存带宽决定数据吞吐速度。RTX 3090显存带宽936 GB/s，而同为24GB显存的RTX 4090是1008 GB/s，看似只差7%，但跑Llama3-70B时，3090平均token生成速度是12.3 token/s，4090是18.7 token/s——差的不是显存，是带宽瓶颈导致的等待时间。
计算精度支持直接影响能否启用高效量化。NVIDIA Ampere架构（30系）原生支持INT4，但实际需TensorRT-LLM深度优化；而Ada Lovelace（40系）的FP16/INT4混合计算单元更成熟，量化后掉点更少。我们实测Qwen2-7B在3060上用AWQ量化后，中文阅读理解准确率从82.4%掉到76.1%；换成4060 Ti后，同样AWQ量化，准确率保持在80.9%。
散热与功耗常被忽略。一台放在书桌上的NUC11，TDP 65W的i7-1185G7 + Iris Xe核显，跑Phi-3-mini（3.8B）时表面温度52℃，风扇静音；但强行加载Qwen2-1.5B（1.5B参数），温度瞬间冲到89℃，触发降频，生成速度暴跌40%。这不是模型不行，是散热设计没给它活路。

提示：别迷信“单卡最大参数量”宣传。我们整理了主流消费级显卡本地推理实测阈值（非训练，仅推理）：

显卡型号	显存	推荐最大模型（GGUF Q4_K_M量化）	实测平均生成速度（中文）	典型场景
RTX 3060 12G	12GB	Qwen2-7B / Llama3-8B	28 token/s	个人知识库问答、轻量写作辅助
RTX 4070 Ti 12G	12GB	Qwen2-14B / Llama3-13B	35 token/s	企业内部文档摘要、客服话术生成
RTX 4090 24G	24GB	Qwen2-72B（需8K上下文）	18 token/s	法律合同条款比对、长篇技术报告分析
MacBook M2 Max 32G	32GB统一内存	Phi-3-mini（3.8B） / TinyLlama（1.1B）	12 token/s（Metal）	移动端离线笔记、会议纪要速记

注意：表格中“推荐最大模型”指在8K上下文长度、batch_size=1、开启FlashAttention-2条件下的稳定运行上限。若你只要4K上下文或batch_size=1，3060也能硬跑Qwen2-14B，但会频繁OOM（Out of Memory），需手动调小n_ctx参数——这不是推荐，是“能跑但不建议”。

2.2 操作系统与基础环境：Linux是默认选项，但Windows和macOS也有成熟路径

很多人以为“本地部署=必须装Ubuntu”，其实大可不必。关键看三点：CUDA/Metal支持、Python包兼容性、后台服务管理便利性。

Linux（Ubuntu 22.04 LTS）：仍是首选。原因很实在：Hugging Face Transformers、llama.cpp、Ollama等主力工具链原生支持最佳；NVIDIA驱动安装一键脚本成熟；systemd服务管理稳定，可设开机自启API服务。我们给某市图书馆部署的古籍OCR+问答系统，就是跑在树莓派5（8GB RAM）+ Ubuntu Server 22.04上，用llama.cpp加载Qwen2-1.5B-GGUF，7x24小时无重启。
Windows 11（22H2+）：不再是“次选”。WSL2已支持GPU直通（需NVIDIA Container Toolkit for WSL），llama.cpp官方提供Windows预编译二进制，Ollama也正式支持Win11。但要注意：Windows Defender实时扫描会拖慢模型加载速度（实测加载Qwen2-7B GGUF耗时增加3.2秒），需将模型目录加入排除列表。
macOS（Ventura+ / Sonoma）：Apple Silicon芯片的Metal加速已非常成熟。llama.cpp的--metal参数、Ollama的ollama run qwen2:7b命令均可直接调用GPU。但我们发现一个隐藏坑：M系列芯片的统一内存架构下，若同时开Chrome（占4GB）、VS Code（2GB）、模型（6GB），系统会疯狂swap到SSD，响应延迟飙升。解决方案是启动模型前执行sudo purge清空缓存，或用ulimit -Sv 6291456限制进程虚拟内存为6GB。

注意：所有平台都强烈建议使用Conda环境隔离。我们曾遇到客户在CentOS7上用系统Python3.6装transformers，结果因PyTorch版本冲突导致torch.compile()报错，折腾两天才发现是系统pip源混装了旧版依赖。用conda create -n llm-env python=3.10 && conda activate llm-env创建干净环境，能避开90%的依赖地狱。

2.3 关键中间件选型：为什么llama.cpp是当前最稳的“万能胶水”

市面上有Ollama、Text Generation WebUI、LM Studio、Jan等多种前端工具，但底层真正扛住高并发、低延迟、跨平台推理的，还是llama.cpp。它不是“另一个框架”，而是把大模型推理这件事，回归到最原始的C/C++层面做极致优化。

为什么它成了事实标准？三个硬核原因：

极致轻量：编译后主程序仅2MB，无Python依赖，可直接扔进Docker Alpine镜像（<15MB），适合嵌入式或边缘设备。我们给农业传感器网关做的病虫害识别提示系统，就是把llama.cpp静态编译进ARM64固件，模型参数存在SD卡，整机功耗<3W。
量化策略最全：支持GGUF格式的Q2_K、Q3_K_M、Q4_K_M、Q5_K_M、Q6_K、Q8_0共6种量化级别。不像有些工具只支持INT4，llama.cpp允许你精细调节“精度-速度-显存”三角关系。例如：Qwen2-7B在RTX 3060上，Q4_K_M量化后显存占用6.2GB，生成速度28 token/s；换Q5_K_M，显存涨到7.1GB，速度微降至26.5 token/s，但中文法律术语识别准确率提升2.3个百分点——这种权衡，只有llama.cpp给你开关。
API协议最开放：内置HTTP Server（--server参数），完全兼容OpenAI API格式（/v1/chat/completions）。这意味着你不用改一行代码，就能把本地模型接入任何支持OpenAI协议的前端：Obsidian插件、Notion AI代理、甚至微信小程序后端。我们帮一家律所做的合同审查系统，前端用React写的Web界面，后端直接调http://localhost:8080/v1/chat/completions，律师完全感知不到背后跑的是本地Qwen2-14B还是云端API。

对比其他方案：

Ollama：胜在“开箱即用”，ollama run qwen2:14b一条命令搞定，但定制化弱，无法细调attention机制，且Windows/macOS更新滞后；
Text Generation WebUI：功能最全（LoRA微调、多模型切换），但依赖Python+PyTorch，内存占用大，老旧笔记本容易卡死；
LM Studio：GUI最友好，但闭源，无法审计安全策略，企业内网部署需额外申请许可。

实操心得：别在生产环境用“一键安装包”。我们坚持从源码编译llama.cpp：git clone https://github.com/ggerganov/llama.cpp && cd llama.cpp && make clean && LLAMA_CUDA=1 make -j$(nproc)。这样能确保启用CUDA加速（LLAMA_CUDA=1），且编译器针对你CPU指令集优化（如AVX2）。实测比官网预编译版快17%。

3. 模型选择：不是参数越大越好，而是“任务匹配度”决定效果上限

3.1 中文场景三大核心需求，对应三类模型架构

很多人陷入“唯参数论”，觉得72B一定比7B强。但真实业务中，模型能力 = 架构设计 × 训练数据 × 任务匹配度。我们按国内用户最常提的三类需求，拆解最适合的模型类型：

需求1：中文日常对话、内容润色、创意写作
→ 首选Qwen2系列（通义千问）。理由很实在：阿里云在中文语料上投入极深，Qwen2-7B在CMMLU（中文多任务理解评测）上得分84.2，远超同规模Llama3-8B的76.5；且其Tokenizer对中文标点、网络用语、方言词切分更准。我们测试过同一段产品文案润色任务：Qwen2-7B输出更符合中文广告语习惯（如“丝滑触感”而非“smooth touch sensation”），而Llama3-8B常保留英文表达逻辑，需人工二次调整。
需求2：专业领域知识问答（法律、医疗、金融）
→ 首选DeepSeek-R1系列（深度求索）。它不是通用大模型，而是专为“长上下文+高精度”设计：R1-671B（671B tokens上下文）在法律条文引用准确率上达92.7%，比Qwen2-72B的85.3%高7个百分点。关键在它的RoPE外推技术——普通模型在32K上下文时注意力权重已严重衰减，而R1通过动态调整旋转位置编码，让第32000个token仍能有效关注首段内容。某证券公司用它解析证监会历年处罚决定书，成功定位“同一违规行为重复处罚”的案例，准确率91.4%。
需求3：资源受限设备（笔记本、手机、边缘盒子）
→ 首选Phi-3系列（微软）。Phi-3-mini（3.8B）在iPhone 15 Pro上用Core ML运行，响应时间<1.2秒；在NUC11上用llama.cpp Metal后端，显存占用仅2.1GB。它用“思维链蒸馏”技术，让小模型学会大模型的推理路径。我们让Phi-3-mini做小学奥数题：题目“甲乙丙三人年龄和为90，甲比乙大5岁，乙比丙大3岁，求丙年龄”，它输出完整步骤“设丙x岁→乙x+3→甲x+8→x+(x+3)+(x+8)=90→x=26.33”，虽最终答案错误（应为整数），但推理链完整，远超同尺寸TinyLlama的“直接猜26”。

注意：别盲目追新。Qwen2-72B刚发布时，我们团队第一时间拉取测试，发现其中文长文本生成存在“段落粘连”问题（前一段结尾与后一段开头语义断裂），直到v2.1.2版本才修复。而Qwen2-14B v2.0.0已非常稳定，实测1000次生成无一次粘连。生产环境永远选“已验证稳定版”，不选“最新版”。

3.2 量化不是“压缩图片”，而是“在精度悬崖边走钢丝”

量化（Quantization）是本地部署的生命线，但也是最容易翻车的环节。很多人以为“Q4_K_M就是4位整数”，其实GGUF量化是分组量化（Group-wise Quantization）+ 异常值保留（Outlier Preservation）的复合操作。

以Qwen2-7B为例，其权重矩阵中约0.3%的数值是“异常值”（绝对值>6.0），若简单四舍五入到4位，会导致整个注意力头失效。Q4_K_M方案是：每32个权重为一组，单独计算该组的scale（缩放因子），并用额外2位存储该组内最大值的索引，确保异常值不丢失。这就是为什么Q4_K_M比Q4_0快15%且更准——它不是偷懒，是更聪明的数学。

我们实测不同量化级别对中文任务的影响（Qwen2-7B，RTX 3060）：

量化级别	显存占用	加载时间	中文阅读理解（CMMLU）	生成速度	适用场景
FP16（原版）	13.8GB	8.2s	86.4%	14.1 token/s	实验室研究、精度验证
Q5_K_M	7.1GB	3.5s	84.7%	26.5 token/s	企业知识库、高精度问答
Q4_K_M	6.2GB	2.8s	82.9%	28.0 token/s	日常办公、个人助理
Q3_K_M	4.9GB	2.1s	78.3%	31.2 token/s	老旧笔记本、低功耗设备

看到没？Q3_K_M速度最快，但准确率掉近5个百分点——如果你只是让模型帮你写周报标题，没问题；但若用于医疗报告摘要，可能漏掉关键症状词。量化选择本质是业务风险评估：你愿为1秒快0.3秒，承担多少信息失真？

实操技巧：用llama.cpp自带的quantize工具做渐进式测试。不要直接量化72B模型，先拿Qwen2-1.5B练手：./quantize ./models/qwen2-1.5b.Q5_K_M.gguf ./models/qwen2-1.5b.Q4_K_M.gguf Q4_K_M。观察日志里avg error（平均误差）是否<0.015，再批量处理大模型。我们曾因跳过这步，导致Qwen2-14B Q4_K_M量化后avg error=0.023，上线后发现所有数字类回答全错。

3.3 上下文长度不是“越大越好”，而是“够用+不浪费”才是真本事

上下文长度（Context Length）常被当作营销参数，但实际部署中，它直接决定显存占用平方级增长。llama.cpp中，KV Cache（键值缓存）显存占用公式为：
KV_Cache ≈ 2 × n_layers × n_kv_heads × head_dim × n_ctx × sizeof(dtype)

以Qwen2-7B为例：n_layers=32, n_kv_heads=8, head_dim=128, n_ctx=32768（32K）, dtype=float16（2字节）
→ KV_Cache ≈ 2×32×8×128×32768×2 ≈1.07GB
若n_ctx翻倍到64K，KV_Cache直接飙到4.28GB——光这一项就吃掉RTX 3060近半显存。

但业务真需要32K吗？我们分析了2000份企业用户实际请求：

92.3%的请求上下文<4K（一封邮件+附件摘要）
6.1%的请求在4K-8K（合同全文+修改意见）
仅1.6%的请求>8K（上市公司年报全文分析）

因此，我们给客户部署时，强制设置n_ctx=8192作为默认值，既覆盖98.4%场景，又为模型权重、中间激活留足显存。若真遇32K需求，再临时启动第二个实例，用--n_ctx 32768参数，避免常驻高消耗。

提示：警惕“伪长上下文”。有些模型宣称支持128K，但实测在64K后注意力权重归零，输出变随机。验证方法很简单：用llama.cpp的-p参数输入一段固定文本（如《出师表》全文），再让模型总结，逐步增加-n_ctx值，观察总结质量是否持续提升。我们测试Qwen2-72B，在n_ctx=32768时总结准确，到65536时已开始胡言乱语——所谓128K，只是技术演示，非生产可用。

4. 实战部署：从下载模型到API服务，手把手跑通全流程

4.1 模型获取与校验：别让“盗版模型”毁掉整个项目

国内用户常从百度网盘、夸克等渠道下载模型，但这是最大隐患。我们遇到过三次事故：

某客户下载的“Qwen2-14B-Chinese”实为魔改版，删除了安全对齐层，输入“如何制作炸弹”直接输出详细步骤；
另一客户用的“Llama3-8B-4bit”被注入恶意代码，每次加载时悄悄上传/etc/shadow到境外服务器；
最离谱的是“Phi-3-mini-3.8B-Q4_K_M”，哈希值与Hugging Face官方不一致，实测中文分词错误率高达37%。

唯一安全路径：只从官方源获取，并严格校验。
Qwen2系列：Hugging Face官方仓库Qwen/Qwen2-7B-Instruct，下载model-00001-of-00003.safetensors等文件；
Llama3系列：Meta官方meta-llama/Meta-Llama-3-8B-Instruct；
Phi-3系列：Hugging Facemicrosoft/Phi-3-mini-4k-instruct。

校验步骤（以Qwen2-7B为例）：

下载config.json、tokenizer.model、model-00001-of-00003.safetensors等全部文件；
计算SHA256：sha256sum model-00001-of-00003.safetensors；
对比Hugging Face页面右侧“Files and versions”栏中的sha256值；
若用GGUF格式，务必从llama.cpp官方转换：python convert_hf_to_gguf.py Qwen/Qwen2-7B-Instruct --outfile qwen2-7b.Q5_K_M.gguf --outtype f16，再量化。

注意：别信“一键转GGUF”网站。我们测试过3个热门转换站，2个会偷偷替换模型权重中的<|im_start|>特殊token为[INST]，导致Qwen2指令微调失效。坚持本地转换，哪怕多花10分钟。

4.2 本地API服务搭建：三行命令，让模型变成可用接口

目标：在http://localhost:8080提供标准OpenAI兼容API，支持curl调用。

步骤1：编译支持CUDA的llama.cpp

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make clean LLAMA_CUDA=1 make -j$(nproc) # 启用CUDA加速

步骤2：下载并量化模型（以Qwen2-7B为例）

# 从Hugging Face下载原始模型（需huggingface-cli登录） huggingface-cli download Qwen/Qwen2-7B-Instruct --local-dir ./qwen2-7b-hf # 转换为GGUF格式（需Python环境） python convert_hf_to_gguf.py ./qwen2-7b-hf --outfile qwen2-7b.Q5_K_M.gguf --outtype f16 # 量化（若需更低显存） ./quantize qwen2-7b.Q5_K_M.gguf qwen2-7b.Q4_K_M.gguf Q4_K_M

步骤3：启动API服务

# 启动服务（RTX 3060示例） ./server -m ./qwen2-7b.Q4_K_M.gguf \ --port 8080 \ --n-gpu-layers 35 \ # 将35层权重卸载到GPU，剩余在CPU --ctx-size 8192 \ # 限制上下文为8K，省显存 --threads 8 \ # CPU线程数，匹配你的CPU核心数 --no-mmap \ # 禁用内存映射，避免大模型加载失败 --verbose-prompt # 输出详细日志，方便调试

启动后，终端会显示：

llama server listening on http://localhost:8080 Loaded model in 2.8s (context size: 8192)

步骤4：测试API（标准OpenAI格式）

curl -X POST "http://localhost:8080/v1/chat/completions" \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2-7b", "messages": [ {"role": "system", "content": "你是一名资深中文编辑，请用简洁语言润色以下文案"}, {"role": "user", "content": "这个产品很好用，速度很快，大家都喜欢"} ], "temperature": 0.7 }'

返回结果：

{ "choices": [{ "message": { "content": "该产品体验出色，运行流畅，广受用户好评。" } }] }

实操心得：首次启动必加--verbose-prompt，观察日志中offloading（卸载）层数是否合理。若n-gpu-layers设太高（如3060设40层），会报CUDA out of memory；设太低（如只设20层），则CPU成为瓶颈，速度骤降。我们的经验是：显存/模型参数比≈1.5时最稳（如12GB显存跑7B模型，设35层）。

4.3 前端集成：让非技术人员也能用上你的本地大模型

模型跑起来只是第一步，让业务人员真正用上，才是价值所在。我们提供三种零代码集成方案：

Obsidian插件（知识工作者首选）
安装Text Generator插件，设置API端点为http://localhost:8080/v1，模型名填qwen2-7b。写笔记时选中一段文字，右键“Send to AI”，自动润色/扩写/翻译。某高校教授用它处理学生论文摘要，效率提升3倍。
Notion AI代理（企业协作场景）
Notion不支持直连本地API，但可用n8n（开源自动化工具）做中转：n8n监听Notion数据库新增记录，触发curl调用本地llama.cpp，再把结果写回Notion。我们帮某咨询公司搭建此流程，项目经理在Notion里新建“客户访谈纪要”页面，填入原始录音稿，5秒后自动生成结构化洞察。
微信小程序后端（ToC场景）
小程序前端调用云开发云函数，云函数内axios请求http://your-server-ip:8080/v1/chat/completions（需服务器配置反向代理，如Nginx转发/api/llm到localhost:8080）。某中医馆用此方案，患者扫码进入小程序，输入症状，本地Qwen2-1.5B即时给出调理建议（数据不出内网）。

注意：所有前端调用必须加--host 0.0.0.0参数启动server，否则仅localhost可访问。若需外网访问，务必加Nginx反向代理+Basic Auth认证，我们曾见客户直接暴露8080端口，3天内被扫出27次恶意请求。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “显存不足”不是报错，而是你没看懂llama.cpp的内存分配逻辑

报错信息：CUDA error: out of memory或failed to allocate GPU memory
新手第一反应：换显卡。但90%的情况，是参数没调对。

llama.cpp内存分三块：

模型权重：量化后固定占用（Q4_K_M约6.2GB）；
KV Cache：随n_ctx和batch_size增长，公式见前文；
中间激活：Transformer层计算时的临时张量，与n_threads强相关。

排查步骤：

先确认n_ctx是否过大：./server -m model.gguf --ctx-size 4096，若成功，则原8192超标；
检查n-gpu-layers：RTX 3060最多支持35层，设40必炸；
降低--threads：--threads 4比--threads 8省30% CPU内存，间接缓解GPU压力；
终极方案：加--no-mmap参数，强制从磁盘流式加载，牺牲1秒加载时间，换显存空间。

我们的真实案例：客户用RTX 4070 Ti跑Qwen2-14B，反复OOM。最后发现是--threads 16（CPU有16核），但--n-gpu-layers 45过高。调至--threads 8 --n-gpu-layers 38后，稳定运行。

5.2 “输出乱码/重复/无意义”——大概率是Tokenizer不匹配

现象：模型输出全是<|im_end|><|im_start|>user循环，或中文变乱码（如“你好”输出“浣犲ソ”）
根因：模型使用的Tokenizer与llama.cpp加载的tokenizer.model文件不一致。

Qwen2系列必须用tokenizer.model（SentencePiece格式），而Llama3用tokenizer.json（Hugging Face格式）。若把Llama3的tokenizer.json硬塞给Qwen2模型，必然乱码。

验证方法：

# 查看模型GGUF文件的tokenizer信息 ./llama-cli -m model.gguf -p "test" --verbose-prompt 2>&1 | grep "tokenizer"

输出含tokenizer: qwen2即正确；若显示tokenizer: llama，说明tokenizer文件错了。

解决方案：

Qwen2模型：必须用convert_hf_to_gguf.py从原始HF仓库转换，它会自动打包正确tokenizer；
别用第三方GGUF，除非明确标注tokenizer: qwen2。

血泪教训：我们曾为客户部署Qwen2-7B，用网上下载的GGUF，输出全是<|im_start|>。重装后发现，那个GGUF的tokenizer是Llama2的，导致所有指令模板失效。重做转换耗时2小时，但避免了后续所有业务逻辑重构。

5.3 “API响应慢/超时”——检查你的网络栈，不是模型问题

现象：curl本地调用快（<1秒），但前端网页调用超时（>30秒）
常见原因有三：

浏览器同源策略：前端JS直接调http://localhost:8080，Chrome会拦截（CORS错误）。解决方案：前端用fetch时加mode: 'no-cors'（仅限调试），生产环境必须用Nginx反向代理，将/api/llm代理到localhost:8080；
Nginx超时设置：默认proxy_read_timeout 60s，但长文本生成可能超时。在Nginx配置中加proxy_read_timeout 300;；
Windows Defender干扰：Windows防火墙有时会拦截localhost回环流量。临时关闭防火墙测试，若恢复则需在防火墙高级设置中放行llama-server.exe。

实操技巧：用curl -w "@curl-format.txt"测试真实耗时，curl-format.txt内容：

time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_pretransfer: %{time_pretransfer}\n time_redirect: %{time_redirect}\n time_starttransfer: %{time_starttransfer}\n ----------\n time_total: %{time_total}\n

若time_starttransfer长（DNS/连接耗时），是网络问题；若time_total - time_starttransfer长，才是模型生成慢。

5.4 “服务崩溃/内存泄漏”——别怪模型，先看你的Linux系统设置

现象：服务运行2天后，top显示llama-server进程RSS内存从1.2GB涨到8.5GB，最终OOM被kill
根因：Linux内核的vm.swappiness设置过高，导致llama.cpp的内存池被频繁swap。

解决方案（永久生效）：

# 编辑sysctl配置 echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 同时限制进程内存（防止失控） sudo prlimit --as=12G --pid $(pgrep -f "llama-server")