简介这份资源面向希望上手开源大模型应用开发的开发者与学习者聚焦环境配置、私有化部署、LoRA微调与LangChain集成四大环节覆盖从模型下载、推理服务到微调训练与接口封装的完整链路。压缩包共79个文件约23.88MB以45个Python脚本和12个Jupyter Notebook为核心辅以JSON配置、bin权重、sqlite3向量库及少量md说明与sh脚本便于直接运行与二次修改。内容围绕InternLM、DeepSeek、Yi、Qwen、Baichuan、ChatGLM、MiniCPM等主流开源模型展开包含模型下载、LoRA微调、量化训练、FastAPI服务、LangChain调用与Gradio交互等模块并配有向量数据库与embedding模型相关文件可帮助读者理解私有化部署与微调落地的关键流程。目前已有858人学习下载适合具备一定Python基础、希望系统实践大模型应用的中高级开发者参考。1. 开源大模型私有化部署与 LoRA 微调从环境配置到 LangChain 接入的完整路径很多团队第一次做企业大模型私有化部署时都会经历一个相似的翻车现场模型权重下载完了推理服务也跑起来了但业务方丢过来一份内部工单数据要求“让模型学会我们的术语”这时候才发现环境配置、微调脚本、推理接口和上层应用之间全是断点。开源大模型真正的落地门槛不在“能不能跑起来”而在“跑起来之后能不能改、能不能接、能不能稳定复现”。这篇笔记围绕环境配置、私有化部署、LoRA 微调和 LangChain 接入四个环节把一条从裸机到业务可用的路径拆开讲清楚。适合手里有 GPU 资源、需要把 Qwen 或同类开源模型落到内网、并且希望用 LangChain 把模型能力接到实际工作流里的工程师。下面所有步骤都按可复现的方式写参数给到能直接抄的程度坑也按我踩过的顺序标出来。2. 环境配置与私有化部署先把推理服务跑稳再谈微调2.1 显卡驱动、CUDA 与 PyTorch 的版本对齐环境配置翻车十有八九出在版本错配上。常见做法是先确定 PyTorch 版本再反推 CUDA最后确认驱动而不是反过来。以当前主流的 CUDA 12.1 为例PyTorch 选 2.1.x 或 2.2.x 都比较稳驱动版本需要满足nvidia-smi右上角显示的 CUDA Version 不低于 12.1。# 查看驱动与最高支持的 CUDA 版本 nvidia-smi # 确认 CUDA 编译器版本 nvcc -V # 安装与 CUDA 12.1 匹配的 PyTorch pip install torch2.2.1 torchvision0.17.1 torchaudio2.2.1 \ --index-url https://download.pytorch.org/whl/cu121逻辑说明nvidia-smi显示的是驱动支持的最高 CUDA 版本不是当前安装的 CUDA 版本nvcc -V才是实际编译器版本。两者不一致时PyTorch 会优先按自身编译时链接的 CUDA 运行但自定义算子编译会出问题。参数上cu121对应 CUDA 12.1如果驱动只支持到 11.8就换成cu118并同步降 PyTorch 到 2.1.x。提示不要用 conda 默认源装 PyTorch版本滞后且容易和系统 CUDA 冲突直接用官方 wheel 源。2.2 用 vLLM 或 TGI 起一个可用的推理服务私有化部署阶段推理框架选型比模型选型更影响吞吐。常见做法是 vLLM 做在线推理TGI 做标准化服务。vLLM 的 PagedAttention 对长上下文更友好启动命令如下# 启动 vLLM OpenAI 兼容服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2-7B-Instruct \ --served-model-name qwen2-7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.90 \ --max-model-len 8192 \ --port 8000逻辑说明--tensor-parallel-size是张量并行数单卡写 1多卡按 GPU 数写--gpu-memory-utilization控制显存占用比例0.90 是常用值留 10% 给系统--max-model-len要和模型本身支持的长度匹配Qwen2 系列常见 8192 或 32768。启动后用curl http://localhost:8000/v1/models验证服务是否就绪。参数调整上如果显存不够优先降--max-model-len和--gpu-memory-utilization而不是盲目换更小的模型。很多业务场景 4096 长度已经够用降到 4096 能省下大量 KV Cache 显存。2.3 模型权重下载与目录规范权重下载建议统一放在/data/models/下按模型名-参数量-版本命名避免后期微调产物和原始权重混在一起。常见做法是用huggingface-cli或modelscope下载内网环境提前配好镜像。# 使用 huggingface-cli 下载到指定目录 huggingface-cli download Qwen/Qwen2-7B-Instruct \ --local-dir /data/models/Qwen2-7B-Instruct \ --local-dir-use-symlinks False逻辑说明--local-dir-use-symlinks False会把真实文件复制到目标目录而不是软链接到缓存方便后续打包迁移到内网。如果内网完全隔离就在有网机器上下载后整体拷贝注意校验config.json、tokenizer.json和*.safetensors是否齐全。3. LoRA 微调实战用 Qwen 跑通一份内部数据3.1 LoRA 到底在改什么为什么适合私有化场景LoRA 微调的意思是在原模型权重旁挂一对低秩矩阵训练时只更新这对小矩阵推理时再合并回原权重。对企业私有化部署来说它的价值在于显存占用低、产物小、可以按业务线分别训练多个适配器。全量微调 7B 模型通常要 8 张 A100LoRA 在单张 24G 卡上就能跑起来产物只有几十到几百 MB。选型上Qwen2 系列对中文支持好社区工具链成熟是当前 LoRA 微调实战教程里出现频率最高的基座之一。常见做法是用 LLaMA-Factory 或 PEFT 直接训练前者封装度高后者更灵活。3.2 数据格式与训练配置数据准备是微调里最容易被低估的一步。指令微调常用 Alpaca 格式每条样本包含instruction、input、output三个字段。下面是一份最小可用的 JSON 数据示例[ { instruction: 根据工单描述判断故障等级, input: 用户反馈登录后页面白屏刷新无效, output: 故障等级P2建议排查前端资源加载与接口超时 } ]逻辑说明instruction是任务描述input是具体输入output是期望输出。训练时模板会把三者拼成一条完整对话。参数上数据量少于 1000 条时LoRA rank 设 8 或 16 就够过多容易过拟合。训练配置用 LLaMA-Factory 的 YAML 写法model_name_or_path: /data/models/Qwen2-7B-Instruct stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_target: all dataset: internal_ticket template: qwen cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 1.0e-4 num_train_epochs: 3.0 output_dir: /data/output/qwen2-lora-ticket逻辑说明lora_target: all表示对所有线性层挂 LoRA效果通常比只挂 q/k/v 更好但显存略高cutoff_len是截断长度要和推理时的max-model-len对齐gradient_accumulation_steps用来在显存不足时模拟更大 batch。学习率 1e-4 是 LoRA 常用起点全量微调则要降到 1e-5 量级。3.3 启动训练与合并权重# 启动 LoRA 训练 llamafactory-cli train /data/config/qwen2_lora_sft.yaml # 训练完成后合并 LoRA 权重到基座 llamafactory-cli export \ --model_name_or_path /data/models/Qwen2-7B-Instruct \ --adapter_name_or_path /data/output/qwen2-lora-ticket \ --template qwen \ --finetuning_type lora \ --export_dir /data/models/Qwen2-7B-Ticket \ --export_size 2逻辑说明export会把 LoRA 增量合并进基座产出一个独立模型目录方便直接用 vLLM 加载。--export_size 2表示按 2GB 分片保存。合并后建议用同一批验证样本对比合并前后的输出确认微调确实生效而不是只记住了格式。4. LangChain 接入把微调后的模型接进业务流4.1 用 OpenAI 兼容接口对接 vLLMLangChain 接入私有化模型最省事的方式是走 OpenAI 兼容协议。vLLM 和 TGI 都提供/v1/chat/completionsLangChain 的ChatOpenAI可以直接指过去。from langchain_openai import ChatOpenAI llm ChatOpenAI( modelqwen2-7b-ticket, openai_api_keyEMPTY, openai_api_basehttp://localhost:8000/v1, temperature0.2, max_tokens1024, ) resp llm.invoke(用户反馈登录后白屏请判断故障等级) print(resp.content)逻辑说明openai_api_key在私有化服务里通常不校验填EMPTY即可openai_api_base指向本地推理服务temperature在工单分类这类任务上建议 0.1 到 0.3太高会导致输出不稳定。max_tokens要和服务的max-model-len留出余量避免请求被截断。4.2 用 Prompt 模板和输出解析器固定结果格式业务系统需要结构化输出LangChain 的 Prompt 模板加输出解析器能把模型输出约束成 JSON。from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser parser JsonOutputParser() prompt ChatPromptTemplate.from_messages([ (system, 你是工单分级助手只输出 JSON字段为 level 和 suggestion。), (human, {ticket}), ]) chain prompt | llm | parser result chain.invoke({ticket: 登录后页面白屏刷新无效}) print(result)逻辑说明JsonOutputParser会尝试把模型输出解析成字典解析失败会抛异常生产环境要加兜底。prompt | llm | parser是 LangChain 表达式语言管道顺序就是数据流向。参数上system 消息里明确“只输出 JSON”能显著降低解析失败率但仍建议在解析器外层包一层重试。4.3 检索增强与多适配器路由私有化场景里模型微调解决的是“说话方式”知识更新还得靠 RAG。常见做法是用 LangChain 的Retriever接向量库把检索结果拼进 Prompt。如果同时训练了多个 LoRA 适配器可以在 vLLM 启动时用--lora-modules注册多个LangChain 侧按model字段路由到不同适配器。# 启动时注册多个 LoRA 适配器 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2-7B-Instruct \ --lora-modules ticket/data/models/Qwen2-7B-Ticket \ --port 8000逻辑说明--lora-modules的格式是名称路径注册后请求里model填ticket就会走对应适配器。这样一套基座可以服务多条业务线显存只多占适配器本身的开销。5. 避坑与排查那些让部署和微调集体翻车的地方5.1 显存够但启动就 OOM现象nvidia-smi显示显存充足vLLM 启动仍报 OOM。原因通常是--gpu-memory-utilization设得过高或者--max-model-len超出实际需求导致 KV Cache 预分配过大。解决先把--max-model-len降到 4096--gpu-memory-utilization降到 0.85启动成功后再逐步上调。5.2 LoRA 训练 loss 下降但推理没变化现象训练日志 loss 正常下降合并后模型输出和基座几乎一样。原因多半是lora_target配错或者数据模板和推理模板不一致。解决确认template字段和基座匹配检查lora_target是否覆盖了实际参与计算的层合并后用训练集里的样本做一次过拟合验证。5.3 LangChain 请求超时或返回空现象llm.invoke长时间无响应或返回空字符串。原因通常是max_tokens设得比服务端max-model-len还大或者openai_api_base少了/v1。解决把max_tokens控制在服务端长度以内确认 base 地址以/v1结尾并用curl直接打服务端接口排除 LangChain 层问题。5.4 微调后模型开始胡说现象微调后模型在通用问题上表现明显下降。原因LoRA rank 过高、训练轮数过多、数据里混入了低质量样本。解决把lora_rank从 64 降到 16num_train_epochs从 5 降到 3清洗数据里格式不一致的样本。血泪经验是数据质量比数据量重要得多500 条干净样本往往胜过 5000 条脏数据。5.5 多卡推理吞吐不升反降现象加了卡但吞吐没提升。原因--tensor-parallel-size和张量并行通信开销不匹配或者模型本身太小不值得多卡。解决7B 模型单卡通常够用多卡更适合 32B 以上确认卡间是 NVLink 还是 PCIePCIe 下张量并行收益有限可以改用数据并行起多个实例。6. 进阶技巧用适配器热切换和量化把成本压下来走到这一步环境、部署、微调、接入都通了剩下的是怎么把资源成本压到业务能接受的程度。我一般会从两个方向下手适配器热切换和量化。适配器热切换的前提是 vLLM 启动时注册了多个 LoRALangChain 侧只需要在请求里改model字段。下面是一个按业务线路由的最小封装from langchain_openai import ChatOpenAI def get_llm(biz: str) - ChatOpenAI: # biz 对应启动时注册的 lora 名称 return ChatOpenAI( modelbiz, openai_api_keyEMPTY, openai_api_basehttp://localhost:8000/v1, temperature0.2, ) ticket_llm get_llm(ticket)逻辑说明model字段直接填适配器名称vLLM 会自动切换到对应 LoRA。这样新增业务线只需要训练新适配器并重启服务不用复制整个基座。参数上适配器数量多时注意显存增量每个 LoRA 大约占几十到几百 MB。量化方面常见做法是用 GPTQ 或 AWQ 把基座压到 4bit显存占用能降到原来的三分之一左右代价是少量精度损失。验证方法很直接准备 50 到 100 条业务样本对比量化前后和微调前后的输出一致率。如果一致率低于 90%就要考虑换量化方案或保留关键层不量化。方案显存占用精度损失适用场景FP16 基座 LoRA高无对精度敏感的核心业务4bit 量化 LoRA低少量多业务线并行、资源紧张4bit 量化 多适配器最低少量适配器热切换场景最后说一个我自己的习惯每次微调产出新适配器先不急着替换线上而是用同一批验证样本跑一遍对比确认没有回归再切。模型这东西没有后悔药线上翻车一次业务方对私有化部署的信任就要打很久的折扣。希望帮到你。本文还有配套的精品资源点击获取