过去一年，开源大模型生态的成熟速度远超预期。Llama 3、Qwen2.5、DeepSeek、Mistral 等模型在通用能力上已逼近闭源 API 的中档水平，而 7B 到 14B 参数量级的模型在消费级显卡甚至统一内存架构的设备上就能跑起来。对开发者而言，这意味着两件事：一是敏感数据不必再出内网，二是可以用自己的领域数据把通用模型“拧”成专用模型。但真正动手时会发现，从“能跑”到“好用”之间隔着一整套工程细节。本文按部署、推理优化、微调、评估上线的顺序，梳理一条可复用的实践路径。

一、选型：先明确约束，再谈模型

本地部署的第一道坎不是技术，而是约束条件。需要先回答三个问题：显存预算多少、延迟要求多高、任务类型是什么。

按显存粗略划分：8GB 显存适合跑 4B 以下模型的 4bit 量化版本；16GB 可承载 7B～8B 的 4bit 量化；24GB（如 RTX 4090）能跑 14B 的 4bit 或 7B 的 8bit；若要全精度运行 70B 级别模型，则需要 80GB 以上的专业卡或多卡并行。统一内存架构的设备（如 Apple Silicon）可以借助内存容量跑更大模型，但带宽决定了 token 生成速度会明显低于同价位独显。

任务类型同样关键。纯文本生成与对话，7B～14B 的指令微调模型通常够用；需要长上下文检索增强，应优先选择原生支持 32K 以上上下文且做过长文本训练的模型；代码补全类任务则要关注模型在 HumanEval、MBPP 等基准上的表现，而非通用榜单排名。

一个常被忽略的点是许可证。部分开源模型对商用有附加条款（如月活用户数限制），选型阶段就应确认，避免后期返工。

二、部署：三条路线与各自适用场景

当前主流的本地部署方案可以归为三类，选择取决于你对控制粒度的需求。

路线一：Ollama，最快出结果。 Ollama 把模型下载、量化格式转换、推理服务封装成一条命令，ollama run qwen2.5:7b 即可启动一个兼容 OpenAI 风格的本地接口。它内置了 Modelfile 机制，可以用类似 Dockerfile 的语法定制系统提示词、温度、上下文长度等参数。适合原型验证和内部工具快速搭建。缺点是底层推理引擎的调优空间有限，高并发场景下吞吐表现一般。

路线二：llama.cpp，控制力最强。 作为 GGUF 量化格式的参考实现，llama.cpp 支持 CPU、CUDA、Metal、Vulkan 等多种后端，能在几乎任何硬件上运行。它的 llama-server 子命令提供 HTTP 服务，支持连续批处理（continuous batching）和投机解码（speculative decoding）。适合需要在异构硬件上部署、或对量化精度有精细要求的场景。代价是需要自己编译、调参，学习曲线较陡。

路线三：vLLM / SGLang，面向吞吐。 这两者采用 PagedAttention 等显存管理技术，在批量推理场景下吞吐可达 llama.cpp 的数倍。它们对 GPU 显存要求更高，且主要面向 NVIDIA 生态。如果目标是给团队提供一个多人共用的推理服务，这是更合理的选择。

一个务实的组合是：开发阶段用 Ollama 快速迭代提示词与流程，生产环境切换到 vLLM 或 llama.cpp server，通过统一的 OpenAI 兼容接口降低切换成本。下面是一个最小化的 llama.cpp 服务启动示例，启用了 4bit KV cache 量化以节省显存：

./llama-server -m ./models/qwen2.5-7b-instruct-q4_k_m.gguf \
  --host 0.0.0.0 --port 8080 \
  -c 8192 -ngl 99 \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --parallel 4

其中 -ngl 99 表示尽可能多地把层卸载到 GPU，--parallel 4 开启 4 路并发槽位，配合连续批处理可以显著提升小请求的吞吐。

三、推理优化：几个性价比最高的手段

部署跑通之后，多数人遇到的第一个问题是“慢”和“吃显存”。以下手段按投入产出比排序。

量化。 GGUF 的 Q4_K_M 在 7B 模型上通常只损失 1～2 个百分点的基准分数，显存占用却降到 FP16 的四分之一左右，是最划算的一步。若对精度敏感，可尝试 Q5_K_M 或 Q6_K。AWQ 和 GPTQ 是另一条量化路线，在 vLLM 生态中支持较好，适合 GPU 部署。

KV cache 量化。 长上下文场景下，KV cache 的显存占用会随序列长度线性增长，常常比模型权重本身还大。把 K/V cache 量化到 8bit 或 4bit，能在几乎不损失质量的前提下把可支持的上下文长度翻倍。

投机解码。 用一个小的草稿模型（draft model）先快速生成若干 token，再由大模型一次性验证。在代码生成、格式化输出等可预测性强的任务上，实测能带来 1.5～2 倍加速。llama.cpp 和 vLLM 都已支持，配置成本不高。

前缀缓存。 如果应用有固定的系统提示词或长文档前缀，开启 prompt caching 可以跳过重复的 prefill 计算，首 token 延迟能降低一个数量级。这对 RAG 场景尤其重要。

四、微调：LoRA 是默认答案，但要选对数据

当通用模型在垂直领域表现不佳时，微调是常规手段。当前实践中的默认选择是 LoRA（低秩适配），它只训练少量附加参数，7B 模型在单张 24GB 显卡上即可完成，产物是几十到几百 MB 的适配器文件，便于分发和热切换。

工具链方面，Hugging Face 的 PEFT + TRL 组合最为通用，支持 SFT、DPO 等训练方式；LLaMA-Factory 提供了配置化界面，适合快速实验；Unsloth 通过内核优化把训练速度和显存占用进一步压低，在单卡场景下优势明显。

微调成败的关键往往不在超参数，而在数据。几条经验：

  • 质量优先于数量。 几百到几千条高质量样本，通常胜过数万条噪声数据。指令微调阶段，样本的“指令—输入—输出”三元组结构要清晰，输出风格要一致。
  • 覆盖真实分布。 训练集应尽量贴近线上实际输入，包括用户的口语化表达、错别字、多轮上下文。只在干净数据上微调，模型一上线就会被真实输入打回原形。
  • 保留通用能力。 纯领域数据训练容易导致灾难性遗忘，建议混入 10%～20% 的通用指令数据。也可以采用 LoRA 而非全参数微调，本身就能缓解遗忘。
  • 注意模板一致性。 训练时使用的 chat template 必须与推理时完全一致，这是最常见的“训练完效果不对”的原因。

一个典型的 LoRA 训练配置片段（基于 PEFT）大致如下：

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16, lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)
model = get_peft_model(base_model, config)

秩 r 取 8～32 是常见区间，任务越复杂、数据越多样，可以适当调大。target_modules 至少覆盖注意力层的四个投影矩阵，若显存允许，加上 MLP 层通常能提升效果。

五、评估与上线：别跳过这一步

微调完成后，最危险的做法是只凭几个样例的主观感受就上线。建议建立一个小型但固定的评估集：从真实业务数据中抽取 100～200 条，覆盖典型场景与边界情况，每次训练后统一跑一遍，对比基线与新模型的输出。

评估维度至少包括：任务准确率（可用规则匹配或更强的模型做裁判）、格式合规率、幻觉率（对事实性任务）、以及响应长度分布。对于生成类任务，人工抽检仍然不可替代。

上线阶段需要关注的是服务化细节：并发控制、超时与降级、输出内容过滤、以及模型版本管理。建议把模型权重、适配器、推理配置（量化方式、上下文长度、采样参数）作为一个整体版本化，记录每次变更对应的评估结果，便于回滚。

六、几个好玩的源码方向

对喜欢读源码的开发者，这条链路里有不少值得深挖的点。

llama.cpp 的 GGUF 加载与张量分配逻辑是理解量化格式