Llama 生产落地案例

生产落地案例

案例一：企业知识库问答的本地化替换

业务背景：一家做工业设备维保的公司，内部有大量设备手册与工单记录，客服团队用文档检索后人工回复，效率低。最初方案是调用云端 API 做大模型问答，但手册里含客户产线参数，安全审计不通过。

怎么用：改成「本地 Llama + 向量检索」的 RAG 架构。基座选中等尺寸的 Llama 指令微调版本，用 vLLM 起服务；检索侧用 embedding 模型做向量召回，把召回的文档片段塞进 prompt；上层业务代码原本基于 OpenAI SDK 写的，只改了 base_url 和模型名就完成切换。为了让回复格式统一（要求先给结论再给依据），用 LoRA 在历史工单上做了一轮轻量微调，产出适配器由 vLLM 动态加载。

关键配置：--max-model-len 按「系统提示 + 召回片段 + 用户问题」的最长组合设定，不盲目拉满；--gpu-memory-utilization 留出余量给并发 KV cache；采样参数把 temperature 压到很低以保证回答稳定；--served-model-name 固定成业务代码里写死的名字，避免模型替换时改代码。

效果指标：这类改造要盯的指标是「首 token 延迟」「每请求平均 token 吞吐」「回答格式合规率」「人工抽检准确率」。具体数值因硬件与数据而异，这里不给数字。可复现的验收方式是：固定一批历史工单作为评测集，固定 seed，改造前后跑同一套脚本对比格式合规率与抽检准确率。

踩过的坑：一是 chat template 不一致——训练脚本自己拼的 prompt 和推理时的模板差了结束符，导致模型停不下来，输出里混进下一轮的角色标记，最后统一从 tokenizer_config.json 取模板才对齐。二是 KV cache 打爆显存——上线前只按单请求估算显存，实际并发 8 路时 OOM，解决办法是限制 --max-model-len 并给并发数设上限。三是 微调后通用能力下降——训练数据全是要点式短答，模型丢失了正常对话的流畅度，最终把训练集里掺入一部分通用对话样本才缓解。

案例二：产线边缘设备的离线质检助手

业务背景：工厂车间网络不稳定，质检员需要现场查询标准作业流程与常见缺陷处置办法，要求完全离线、单机运行、响应快。

怎么用：选小尺寸的 Llama 模型，量化到 GGUF 的中等档位，用 llama.cpp 的 llama-server 起在本地的边缘盒子上，前端是一层很薄的 Web 界面。因为是纯 CPU 或低端 GPU 环境，llama.cpp 的量化控制能力是关键优势——先用 llama-bench 对比不同量化档位与线程数下的实际生成速度，再选一个速度可接受、质量不掉太多的档位。

关键配置：-c 根据问答最长上下文设定，不做无谓放大；--parallel 设为 1 到 2（边缘设备没有高并发需求，多槽位只会摊薄显存）；-ngl 按盒子是否有 GPU 决定；线程数通过 -t 调成物理核心数。知识内容通过系统提示与检索片段注入，不做在线微调。

效果指标：关注「生成速度（tokens/s）」「首次可用响应时间」「答案与作业指导书的一致率」。同样以抽检与固定评测集为准。

踩过的坑：模型版本与量化档位组合没有做系统性对比，一开始凭感觉选了最低档，结果长问答里频繁答非所问，换成更高一档后问题消失；边缘盒子内存不足导致加载失败，原因是把原始权重文件和量化文件同时留在同一个分区，清理缓存目录后解决；断电重启后服务不自动拉起，用系统服务托管并加了健康检查才稳定。