Llama选型部署微调与RAG实战指南：从8B到405B，低成本少踩坑快速落地

我做 Llama 选型，习惯把它当成一个工具箱。工具箱里有不同年代、不同尺寸、不同许可的模型。任务、数据、预算、硬件这四件事，会决定你该拿哪一把。下面我按家族演进、硬件账本、落地建议三块聊。

1.1 Llama 1/2/3 家族演进与核心差异

我作为算法工程师，最早碰 Llama 1 是在研究项目里。7B、13B、33B、65B 几个规格，decoder-only 架构，RoPE、SwiGLU、RMSNorm 都成了后面开源模型的常客。上下文 2048，许可偏研究，商用限制多。它像一块试验田，证明了开放权重路线能跑通。

Llama 2 出来时，我正帮一个创业团队做客服机器人。7B、13B、34B、70B，上下文到 4096，Chat 版用 RLHF 做了对话对齐。34B 和 70B 引入 GQA，推理显存压力小些。许可允许商用，月活超 7 亿要单独谈。我选 Llama 2 13B Chat 做原型，看中生态成熟，量化文件多，踩坑资料也多。

Llama 3 让我感觉 Meta 换了打法。8B、70B 起步，训练 token 到 15T，词表 128K，上下文 8192。Llama 3.1 放出 405B，上下文 128K，工具调用和多语言增强。Llama 3.2 补了 1B、3B 小模型和视觉版本，Llama 3.3 把 70B 推到接近更大模型的效果。核心差异在许可、对话模板、tokenizer、上下文长度。我作为独立开发者，最喜欢小模型变强，笔记本也能跑。微调时换错模板，效果会掉得莫名其妙。

1.2 参数规模、量化版本与硬件需求

我帮朋友配机器，先问三件事：跑多大模型、量化到几 bit、上下文多长。FP16 下每 10 亿参数约 2GB，70B 要 140GB 左右。Q8 约 1GB 每 B，Q4 约 0.5 到 0.7GB 每 B。70B Q4 大概 35 到 40GB，单张 48GB 卡能塞下，双 24GB 也能玩。8B Q4 约 5 到 6GB，很多消费级显卡能跑。

量化版本分几类。GGUF 适合 llama.cpp、Ollama、LM Studio，CPU 和 Mac 统一内存都能吃。AWQ、GPTQ 适合 vLLM、TGI 这类 GPU 推理服务，吞吐高。bitsandbytes 的 NF4 适合 Transformers 加 QLoRA 微调。我的 MacBook M2 16GB 跑 8B Q4_K_M 挺顺，70B Q4 得靠 64GB 内存或 SSD 交换，速度会掉。量化不是越低越好，Q4 以下有时伤推理和代码能力。

硬件需求别只看权重。KV cache 会随上下文和并发涨，GQA 能省不少显存，Llama 3 基本都带 GQA。上下文 8K 和 128K 完全两个世界。我做长文档问答时，会把 chunk 切小，配合 RAG，别硬拉满上下文。显存不够就降量化、减并发、开 CPU offload。磁盘也要留足，70B Q4 单个文件几十 GB，多版本下载很占空间。我一般先用 Q4_K_M 试水，效果不够再上 Q5 或 Q8；显存卡在 24GB，8B Q8 加 8K 上下文比较稳，70B 高并发用 AWQ 加 vLLM 更合适。

这张表是粗略估算。实际占用看框架、上下文、批次和 KV cache 精度。

1.3 本地部署、微调与商业应用的选择建议

我作为部署运维，选型会先画一条线：数据能不能出内网。医疗、金融、法务这些场景，本地部署是硬需求。Ollama 和 llama.cpp 上手快，适合单机、小团队、隐私优先。vLLM 适合 GPU 服务器、高并发 API。Transformers 适合研究和微调。我的经验是，原型阶段用 Ollama，服务化再换 vLLM，别一上来就堆复杂架构。

微调要看目标。想让模型懂行业术语、固定输出格式，LoRA 或 QLoRA 就够。QLoRA 能在 24GB 显存上微调 7B/8B，甚至 70B 的 4bit 版本。全参数微调吃资源，70B 全参要几百 GB 显存，一般团队没必要。我做过一个合同抽取任务，8B QLoRA 加 2000 条清洗数据，效果比直接 prompt 稳很多。数据质量比数据量重要，对话模板要和基座匹配。

商业应用要读许可。Llama 2 和 Llama 3 的社区许可允许商用，月活超 7 亿要申请。命名、分发、可接受使用政策都有要求。我建议产品负责人把许可检查放进选型清单。成本上，API 调用和自建推理要算 TCO。低并发、短周期，API 更省。高并发、数据敏感、长期跑，自建更划算。选型没有标准答案，先跑一个小 benchmark，再决定 8B、70B 还是 405B。我常跟团队说，Llama 选型像配电脑：任务决定 GPU，GPU 决定量化，量化决定体验。个人学习从 8B Q4 开始。企业知识库用 8B/70B 加 RAG。需要强推理和长上下文，再看 405B 或 Llama 3.3 70B。微调优先 QLoRA。商业落地先过合规，再谈性能。这样走，踩坑少，迭代快。 from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") resp = client.chat.completions.create(

model="llama3.1:8b",
messages=[{"role": "user", "content": "用一句话解释 Llama 3"}]

) print(resp.choices[0].message.content)

我拿 Llama 2 做过几轮微调，7B 和 13B 都试过。微调这件事，目标不同，路线差别很大。有人想让模型懂医疗术语，有人想让它按固定格式回话，还有人单纯想让它说话更像自己。我踩过的坑集中在显存和数据处理上。这一章按目标、数据、工具、配置、验证五块拆开讲，把我用过的命令和判断依据留下来。

3.1 微调目标与路线选择：全参数、LoRA、QLoRA

我动手之前会先问自己：这次微调到底要解决什么问题。如果是让 Llama 2 学会某个垂直领域的问答，比如法律条文解释，数据量不用太大，几千条高质量指令就够。要是想改变模型的整体风格，比如从通用助手变成客服口吻，那数据得覆盖各种场景。目标定了，路线才能选。我见过有人一上来就全参数微调，结果显存爆了，效果也没比 LoRA 好多少。

全参数微调我试过一次，7B 模型在 8 张 A100 上跑，显存吃得厉害。它适合数据量极大、算力充足的团队。LoRA 是我最常用的路线，在原始权重旁边挂低秩矩阵，训练参数量降到百分之一左右。单张 24G 卡能跑 7B，效果接近全参数。QLoRA 更省，把基础模型量化到 4bit，再在上面加 LoRA。我拿 QLoRA 在 3090 上微调 Llama 2 7B，显存占用不到 10G，速度也能接受。

选路线要看硬件和数据。我手头只有一张 4090，QLoRA 是首选。如果有多卡 A100，全参数可以试试。LoRA 处在中间，适合单卡 24G 以上的场景。我一般先用 QLoRA 跑通流程，看效果再决定要不要换 LoRA 或全参数。Llama 2 13B 用 QLoRA 在 24G 卡上也能跑，只是批次得调小。

3.2 数据准备：指令数据、对话模板与质量清洗

数据是微调里最花时间的部分。我收集过 Alpaca 格式的数据，instruction、input、output 三列。也用过 ShareGPT 格式，多轮对话存成 JSON。Llama 2 本身有对话模板，[INST] 用户输入 [/INST] 模型回复。微调时要让数据套上这个模板，不然模型学不会正确的对话边界。我写过一个 Python 脚本，把原始数据转成模板格式，顺便过滤掉太短或太长的样本。

质量清洗我做得比较细。去重是第一步，用 MinHash 或者简单的文本哈希。低质量样本我按规则筛，比如回复里全是重复词、包含乱码、长度超过 2048 token 的直接扔掉。我还用模型打分，拿一个小的奖励模型或者 GPT-4 给样本打分，保留高分数据。有一次我偷懒没清洗，微调完模型开始胡说八道，后来重新洗了一遍数据才正常。

对话模板对齐容易被忽略。Llama 2 chat 模型训练时用了特定的 system prompt 和对话格式。我微调时会把 system prompt 拼在每条数据前面，比如“You are a helpful assistant.”。多轮对话要保留角色标记，用户和助手轮流出现。我手动构造过一批客服对话数据，每轮都套上 [INST] 和 [/INST]，训练完模型能记住上下文。数据里不要混入其他模型的模板，不然会干扰。

3.3 工具链实践：Transformers、PEFT、LLaMA-Factory

我最早用 Transformers 加 PEFT 手写训练脚本。加载 Llama 2 模型用 AutoModelForCausalLM，配 device_map 和 torch_dtype。PEFT 的 LoraConfig 设 r=8、lora_alpha=32、target_modules 选 q_proj 和 v_proj。训练循环用 Trainer，数据用 DataCollatorForLanguageModeling。这套流程灵活，想改什么改什么，适合研究性质的任务。缺点是代码量大，容易在细节上出错。

LLaMA-Factory 是我后来常用的工具。它把微调流程封装成配置文件和命令行。我写一个 YAML，指定模型路径、数据路径、LoRA 参数、训练超参，然后一行命令启动。它支持 QLoRA、全参数、多种模型结构。界面上还能看 loss 曲线。我用它跑过 Llama 2 7B 的指令微调，从数据准备到导出模型，半天搞定。适合快速实验和不太熟悉训练代码的人。

两个工具我换着用。Transformers 适合调试和自定义损失函数，LLaMA-Factory 适合批量实验。我有个习惯，先用 LLaMA-Factory 跑一个基线，再用 Transformers 复现，对比结果。有一次 LLaMA-Factory 的默认学习率偏高，模型过拟合了，我在 Transformers 里调低后才正常。工具链没有绝对好坏，看场景。

3.4 训练配置：学习率、批次、梯度累积与显存控制

学习率我一般设 2e-4 或 1e-4。LoRA 可以用大一点，QLoRA 要小一点，因为量化本身有噪声。我试过 5e-4，loss 震荡得厉害，后来降到 1e-4 就稳了。批次大小受显存限制，Llama 2 7B 用 QLoRA 时 batch_size 设 1 或 2。13B 只能设 1。梯度累积用来模拟大批次，我常设 gradient_accumulation_steps=8，这样等效 batch size 是 8。

显存控制有几个开关。gradient_checkpointing 能省不少显存，代价是训练慢一点。bf16 比 fp16 更稳，我优先用 bf16。QLoRA 用 4bit 量化加载模型，bitsandbytes 的 load_in_4bit=True。优化器用 paged_adamw_8bit，避免优化器状态占太多显存。我一边训练一边开 nvidia-smi -l 1 看占用，如果接近上限就减批次或加累积。

训练轮数我一般设 3 到 5 个 epoch。数据少的时候多跑几轮，数据多的时候 2 轮就够。我监控验证集 loss，如果连续上升就早停。有一次我跑了 10 个 epoch，模型把训练数据背下来了，测试集上表现反而差。后来我加了早停回调，验证 loss 不降就停。学习率调度用 cosine，warmup 设 0.03 左右。

3.5 评估、合并导出与本地推理验证

评估微调效果不能只看 loss。我准备一个测试集，包含各种问题，让微调后的模型和原始模型分别回答。人工对比哪个更符合预期。也可以用 GPT-4 打分，或者算 BLEU、ROUGE。我试过用 Llama 2 自己评估自己，结果不太可靠。最好找几个人盲评，或者用领域内的标准测试集。

合并导出是把 LoRA 权重合到基础模型上。PEFT 有 merge_and_unload 方法，一行代码搞定。合并后的模型和原始模型结构一样，可以直接用 Transformers 加载。QLoRA 合并前要先把 4bit 模型转回 fp16，不然会报错。我导出过 safetensors 格式，文件大小和原始模型差不多。合并后我还会用 llama.cpp 转成 GGUF，方便本地推理。

本地推理验证是最后一步。我用 Transformers 加载合并后的模型，跑几个测试问题。看输出是否流畅、是否符合微调目标。再用 llama.cpp 的 llama-cli 跑量化版，对比速度和质量。有一次合并后模型输出重复，查了半天发现是 LoRA 的 target_modules 少配了一个。后来加上 o_proj 和 gate_proj 就正常了。验证通过后，我会把模型和推理脚本打包，方便下次直接用。

上一章讲完微调，模型算是能按我的想法说话了。把它丢进真实业务里跑，又是另一回事。我做过一个内部问答机器人，微调完的 Llama 2 答起业务问题来头头是道，用户问“上个月新出的那款产品保修几年”，它张嘴就编。模型的知识封在训练数据里，企业文档、实时数据、私有系统，它一概不知。这一章聊的是模型之外的那圈东西——怎么接知识库、怎么调工具、怎么管住它、怎么算清楚账。

4.1 检索增强生成（RAG）与知识库问答

RAG 是我在业务场景里用得最多的方案。思路不复杂：用户提问时先去知识库里捞相关段落，拼进 prompt，让 Llama 基于这些材料回答。我做过一个几百份 PDF 加 Confluence 页面的内部知识库，对比下来，RAG 版本的幻觉比裸模型少了一大截。关键是检索到的内容得准。我踩过的坑集中在切块上。最早按固定 500 token 切，一句话被拦腰截断，模型读得云里雾里。后来改成按段落和标题切，留 50 到 100 token 重叠，效果稳多了。

嵌入模型和向量库我换过好几轮。中文场景下 BGE 系列比 OpenAI 的 ada 表现好，尤其是短查询匹配长文档的时候。向量库小规模用 Chroma 省事，数据上到十万条级别换 Qdrant，检索延迟明显下降。还有个细节是元数据过滤。我给每个片段打上来源、部门、更新时间标签，用户问财务相关的问题时只检索财务目录，减少干扰。

检索质量决定天花板。我遇到过一个典型情况：用户问“退货流程”，捞回来的是“换货政策”和“退款说明”，字面像，答非所问。加了一层 bge-reranker 重排序之后准确率上来了。混合检索也管用，向量检索加关键词检索各跑一遍再合并，专有名词多的场景特别有效。片段数量我控制在 top 3 到 top 5，每个不超过 500 token。塞太多反而稀释注意力，模型开始抓不住重点。Prompt 模板我固定成三段：系统指令、检索上下文、用户问题，明确告诉模型只用上下文回答，不知道就说不知道。

4.2 Agent、函数调用与工作流编排

Agent 是我觉得最有意思也最容易翻车的方向。Llama 3 的函数调用能力比 Llama 2 强不少。我把可用函数写成 JSON Schema 塞进 system prompt，模型自己判断什么时候调哪个函数、传什么参数。天气查询、数据库读取、邮件发送这些小任务，70B 版本基本能稳定完成，8B 偶尔会编出不存在的函数名。参数格式也时有出错，我在函数入口加了一层校验兜底。

工作流编排我用 LangGraph 搭过一条客服链路。用户进来先分意图，售前走推荐，售后先查订单号，查不到就追问，查到再判断退款还是换货。每个节点可以是函数调用，也可以是一个 Llama 实例。条件边处理分支流转。状态管理是这套东西里最烦的部分，节点之间传参稍不注意就串了。我用 TypedDict 定义状态结构，每个节点只读写自己需要的字段，出错的概率小很多。

多 Agent 协作我试过 AutoGen，让几个 Llama 分别扮演产品、开发、测试互相讨论。想法很酷，实际跑起来几个 Agent 容易陷入“好的我明白了”的循环。加了最大轮次和终止条件才勉强能用。生产环境里我更倾向单 Agent 配清晰工具定义。安全这块得单独说。模型调用函数时传的参数不可控，prompt 注入可能诱导它调不该调的函数。我的做法是函数层做权限白名单，敏感操作比如删除、转账加二次确认。见过有人没做限制，模型生成了一个删表调用。

4.3 多模态扩展、安全对齐与合规许可

多模态我是从 Llama 3.2 vision 版本开始试的。把产品图丢进去问它是什么、有什么特征，回答基本靠谱。主要用在两个场景：文档图片解析和商品图分类。做法是把图片编码成向量，和文本 token 拼在一起送进模型。开源的多模态方案里 LLaVA 系列比较成熟，我基于它做过一轮实验，识别表格和截图里的文字效果还行，复杂图表就容易看错。

安全对齐是企业项目里绕不过去的一关。Llama 自带一些安全训练，直接拿去用还是能问出不该问的东西。我加过 Llama Guard 做输入输出双向过滤，它本身是 Llama 微调出来的内容审核模型，判断违规比较准。输入侧过滤用户提问，输出侧过滤模型回复，再加一层敏感词库兜底。这套组合下来违规漏出率降了很多。业务侧还得设定边界，比如客服机器人不该回答医疗建议、法律意见这类问题，我在 system prompt 里明确写了拒答范围。

合规许可要认真读。Llama 3 用的社区许可证允许商用，月活超过 7 亿的公司需要单独申请，产品里要标注“Built with Llama”。用 Llama 生成的数据去训练其他模型，条款里有额外限制。我帮一个客户做合规梳理时把这些逐条列给法务确认过。Llama 2 和 Llama 3 的条款有差异，升级版本时得重新看。数据隐私在 RAG 和 Agent 场景里尤其敏感，知识库文档可能带客户信息，Agent 调的 API 可能触及内部系统。我的习惯是 embedding 模型和向量库都本地部署，数据不出内网，调外部 API 前做脱敏，日志里不留原始敏感数据。

4.4 性能基准、成本优化与持续迭代

性能我从两个维度看。榜单分数用来做初筛，MMLU、HumanEval 这些能大致判断模型水平。真正上线前我会用业务测试集跑一遍，比如 200 条真实用户问题，人工标注期望答案，看模型答对多少。见过榜单高分模型在垂直领域翻车的例子，业务测试才是准的。延迟也得测，Llama 3 8B 量化版在 4090 上首 token 大概几百毫秒，输出速度每秒几十个 token，够对话场景用。

成本我算得比较细。本地部署一张 4090 跑 8B 量化版，电费加硬件折旧摊下来，每千次调用成本很低。高频场景调云 API 按 token 计费反而贵。批量推理我用 vLLM，吞吐量比 Transformers 高好几倍，PagedAttention 对显存利用很友好。缓存也是一招，相同或相似问题直接返回缓存结果。量化等级的选择要看场景，Q4 够用的就别上 Q8，省下来的显存能提高并发数。

持续迭代靠反馈闭环。我在产品里埋了点赞点踩按钮，用户不满意的回答进队列。每周把 bad case 捞出来分类：检索问题调切块和重排序，prompt 问题改模板，模型能力问题考虑补数据微调。这个循环跑起来系统会慢慢变好。监控不能少，我记录每次调用的延迟、token 数、检索命中率、用户反馈。延迟突然升高可能是有长文档进来了，检索命中率下降可能是知识库更新后向量没重建。遇到过一次性事故，文档删了但向量库里还留着，模型答的是已下线的旧政策。后来加了同步检查，文档变更触发向量重建。系统跑起来只是开始，维护是长期的事。