1. 课题组私有AI的整体设计思路1.1 先想清楚从直接调用API到本地私有化的转变先描述一个我见过无数次的场景课题组里几个博士生和老师一起做项目最初都是直接调用通用大模型的API写写摘要、改改邮件、做点初稿润色确实很快。但用了三个月后问题就暴露了——通用模型不熟悉课题组的专业术语。举个例子同样是压裂曲线通用模型可能理解成材料疲劳但课题组要的是非常明确的工程语义。更麻烦的是文献数据不能总是放到公有云API里很多项目合同和研究数据有保密要求你总不能把未发表的实验数据发给外部服务。所以课题组私有AI这个说法本质上是两件事一是让模型真正懂你这个领域二是让模型运行在你自己的可控环境里。从技术路径上看实现私有AI有几种做法直接用现成的开源模型跑推理这是最简单但效果最有限的只做RAG知识库增强不改模型权重适合快速落地做领域微调改变模型行为习惯让它更贴合任务再把两者结合微调RAG这是课题组落地最常见、效果也最稳的组合。我见过不少团队一上来就想全参数微调一个几十B的模型结果显卡不够、数据不够最后项目烂尾。正确思路应该是先用小步快跑的方式验证先用RAG解决知识不足再用LoRA解决能力不对齐最后再考虑蒸馏和量化。1.2 技术选型的整体考量开源模型、算力、数据三要素课题组私有AI的选型我习惯用一个三要素框架来看模型基座、算力预算、数据资产。模型基座决定了效果上限算力预算决定了你能跑多大的模型数据资产决定了你能把下限拉高多少。三者的关系很像做饭模型是锅算力是火数据是食材。锅再好火不够食材平平做不出硬菜食材再好锅太差也发挥不出来。先说算力预算这是先决条件。一张单卡显存24G的RTX 3090/4090大概能跑7B-14B模型的量化版本两张卡可以跑32B级别的量化如果你们实验室有A100或H100那直接考虑训练和部署更大规模。对于大多数课题组的预算我建议把首选目标放在7B-14B这个档位。别小看这一档经过领域微调和RAG加持它在专业任务上完全可以超过一个更大参数的通用模型。再说数据资产。一个课题组真正拥有的是论文、实验记录、仿真数据、历史项目文档、专利和学位论文。这些材料里可能有几十万token也可能有几百万token。数据质量比数量重要得多尤其是微调场景几千条精心构造的指令数据效果可能比几万条粗糙爬来的数据更好。所以设计私有AI的第一步永远不是选模型而是先盘点你手里到底有什么数据。最后回到模型基座。目前国产开源模型已经非常成熟Qwen系列、DeepSeek、ChatGLM系列都是可选的。选型的时候不能只看榜单分数还要看中文能力、长文本表现、生态工具链以及社区里有没有人踩过坑。这块我在下一节详细展开。1.3 一条可落地的路线微调、知识库、量化、推理四步走我强烈建议课题组按照下面这条路径推进而不是并行乱试第一步先搭一个基线环境直接把选定的开源模型跑起来用几个典型任务比如从实验记录中抽取参数、回答问题测试效果。第二步构建领域知识库用RAG解决模型不知道的问题这一步见效最快通常一两周就能看出明显提升。第三步用LoRA或QLoRA做领域微调解决模型会但做得不规范的问题比如让它学会你课题组的写作风格、格式要求。第四步做量化压缩和推理部署把模型体积和显存占用降下来用vLLM支撑多人同时访问。这套路径的核心逻辑是先用轻量手段解决最大的痛点再逐步深入。如果一开始就埋头微调很可能微调完了发现效果还没RAG好因为你的数据量不够或者指令设计不合理。反过来如果只做RAG模型对领域表达方式的适配能力始终有限。两者结合才是正路。2. 开源模型选型与领域语料构建2.1 国产开源模型怎么挑Qwen、DeepSeek、ChatGLM的选择逻辑现在说到选型我的建议比较明确大部分课题组可以直接从Qwen系列入手。Qwen2.5和Qwen3系列的中文能力、代码能力、指令跟随能力都比较均衡而且社区生态特别好从Hugging Face到ModelScope都有完善的权重和示例。尤其是Qwen3MoE架构和密集架构都有参数档位覆盖从0.6B到235B绝大多数课题组都能找到合适的尺寸。对于需要高效推理的团队Qwen3的MoE版本在推理速度上很有优势但显存占用会高一些需要权衡。DeepSeek也很强尤其DeepSeek-R1系列在推理任务上的表现有目共睹。但有些团队的显卡可能跑不动完整的R1蒸馏版本反而更实用。ChatGLM系列目前迭代到ChatGLM4它在中文场景稳定但生态比Qwen略窄一些。我的经验是主攻自然语言理解、文本生成、文献处理的课题组选Qwen主攻数学推理、代码生成且算力充足的团队可以看DeepSeek需要长文本处理且希望中文风格稳定的可以考虑GLM系列。一个容易被忽略的点是一定要看模型的许可证。部分开源模型对商用有额外限制课题组内部研究通常没问题但如果和外部企业有合作或者将来想发开源项目务必先查清楚。另外选模型时也要看tokenizer是否适合你的领域。比如代码混合场景多的Qwen的tokenizer压缩率更好纯中文文献多的几个模型差异不大。2.2 领域语料构建清洗、去重、格式转换语料构建这件事听起来简单做起来全是细节。很多团队直接把PDF文档丢给模型处理效果很差因为PDF提取出来往往带页码、页眉页脚、乱码、图表错位。我建议先走一遍标准清洗流程。文本提取可以用PaddleOCR配合版面分析也可以用一些专项工具如MinerU、marker等从PDF中抽取Markdown格式文本效果比直接pdftotext好得多。提取后要做以下几步清洗去除页眉页脚、参考文献列表、重复段落把全角标点统一成半角删除只包含数字和符号的行对段落做合并和分段保持语义完整。清洗完成后需要做去重。课题组文档里相似内容极多比如同一组实验数据在开题报告、中期报告、结题报告里反复出现。可以使用MinHash或SimHash基于文本相似度去重保底也要做一次精确的md5去重。还有一个常被忽略的步骤是格式转换。不同的下游应用需要不同格式RAG库需要分块后的文本微调需要指令对数据集继续预训练需要纯文本语料。所以建议在清洗之后先保存一份规范的纯文本语料库比如JSONL格式每行是一段再从这个中间格式派生出RAG分块和微调指令避免重复清洗。2.3 语料规模与质量权衡什么时候该做继续预训练在讲微调之前必须把继续预训练continual pretraining和指令微调SFT区分开。很多课题组搞混了拿着领域语料直接做SFT结果发现模型变笨了因为SFT的数据格式要求是指令-回答不是知识文本。如果你有一大批领域文献、专利文本想让模型博闻强识应该做继续预训练让模型在领域语料上继续学习语言和知识。但继续预训练的成本比SFT高很多因为学习率要小、步数要长、且容易遗忘通用能力。那什么时候有必要做继续预训练我的判断标准是如果领域语料超过1亿token并且通用模型在这种专业文本上几乎无法理解基本术语才建议考虑。对于大多数课题组几百万token的语料更合理的做法是做RAG让模型在推理时去检索知识而不是把几百万token硬塞进权重里。硬塞进去的后果是训练成本高、更新困难且还有遗忘风险。正确的知识更新方式应该是更新知识库而不是频繁重新微调。先做好这个判断能帮你省下大量算力和时间。3. RAG检索增强知识库落地实践3.1 RAG到底是什么为什么课题组知识库首选它RAGRetrieval-Augmented Generation的思路很简单在模型回答问题之前先从外部知识库中检索出相关文本片段拼进上下文里再让模型结合这些片段生成答案。我把RAG理解成开卷考试——模型不需要把所有的书都背下来只要考试的时候会翻书、会引用就行。这个特性对课题组来说太合适了因为课题组的知识是持续增长的今天来了新一批实验数据明天可能就有新论文这些内容只需要更新知识库索引就够了不需要重训模型。RAG还有一个隐性优势可以溯源。模型答完题你能告诉用户答案来自哪份文档哪个段落这对科研场景非常重要。纯微调模型做不到这一点它只能给你一个无法验证的答案。所以即使你后面做了微调也建议保留RAG层形成微调负责表达能力RAG负责事实来源的组合。3.2 开源知识库拆解工具与 embedding 模型选择知识库构建的第一步是文档拆解。很多人用langchain的简单TextSplitter按固定字符大小切分效果很差——会把表格拆成乱码把一段完整的推导过程切得七零八落。更好的做法是用保留版式结构的切分器。我实际用下来比较稳的方案是先用MinerU或LayoutReader做版面分析把PDF转成Markdown保留标题层级再按标题和段落结构进行语义切分设置分块大小在500到800个token之间分块重叠控制在50到100个token。这样切出来的块不会把语义切断检索效果也更好。做RAG知识库时有一个热词是RAG知识库能存储图片吗很多人问。其实是可以的但要注意方式目前主流的 embedding 模型不支持直接对图片内容向量化你需要先用视觉语言模型比如Qwen-VL把图片内容转换成文字描述再把描述入库。对于图表类图片这套方案格外好用。另外也可以把图片本身作为附件存起来检索到相关文字描述后再把图片返回给用户看但纯向量检索是检索不到像素的。embedding 模型的选择也很有讲究。目前常用的中英文模型有BGE系列、Qwen3-Embedding、M3E等。我建议按这个思路选如果主要处理中文文献BGE-large-zh或Qwen3-Embedding-0.6B都不错如果中英混杂可以用BGE-M3它支持多语言且能输出稀疏和稠密两种向量。有一点要记住embedding模型的输入长度有限通常是512或1024 token分块大小要根据它来设计。另外还要注意embedding模型更新后必须重建整个索引否则新旧向量无法对比。3.3 检索优化混合检索、rerank、命中率提升只靠向量检索往往不够。向量检索擅长找语义相似但精确匹配能力弱比如文献编号GB/T 1234-2020这类精确信息语义向量很容易找错。所以我强烈建议做混合检索同时跑向量检索和BM25关键词检索再把两路结果合并。开源的Elasticsearch或MeiliSearch都支持BM25也可以直接用Milvus或Qdrant的混合检索能力。合并之后还有一个提升命中率的利器rerank。向量检索先召回top50再用一个交叉编码器模型比如bge-reranker对这50个候选块做精排选出top5喂给大模型。这一步对最终答案质量影响极大我实测过加了rerank之后回答的引用准确率能提升20%以上。衡量RAG效果不能只看最终回答好不好更核心的指标是检索命中率hit rate和MRR。命中率指在检索候选里是否包含正确文档MRR看正确文档排在第几位。调优时可以把测试数据做成问题标准答案来自哪个文档块的形式用检索API反复测命中率。如果命中率低先调分块大小、重叠数、检索topK再考虑重切分或改embedding模型。3.4 本体与Agentic RAG的进阶玩法社区最近在热聊ontology RAG和Agentic RAG。前者是把领域知识结构化成本体实体、关系、属性再用图数据库存储和检索。比如你的课题涉及材料、工艺、性能三类实体本体RAG就能支持所有做过X工艺的材料里哪种的耐腐蚀性最好这种跨实体推理问题传统向量库做不到。构建本体需要人工整理但一旦建成效果拔群。Agentic RAG则更进一步把检索过程交给一个Agent来编排。它会先理解用户问题然后自主决定是查向量库、查数据库还是查Web甚至多步检索再综合回答。开发难度也随之增大但对于课题组的一些复杂调试场景比如帮我找出去年实验中所有异常数据并分析原因Agentic RAG能自动迭代查询体验比一次性检索好很多。新手建议先把基础RAG跑通再做这些进阶形态。4. LoRA/QLoRA高效微调实战4.1 为什么选LoRA而不是全参数微调如果直接全参数微调7B模型即使是AdamW优化器也要至少60GB以上的显存这直接把绝大多数课题组排除在外。LoRALow-Rank Adaptation的大思路是冻结原始模型的所有参数只在旁边加一个低秩矩阵作为可训练的适配器。这样可训练参数量通常只有原来的0.5%到1%。比如7B模型LoRA只训练几十到一百多M的参数显存需求大幅下降单张24G卡就能跑。LoRA训练出的适配器是一个很小的权重文件使用的时候加载原始模型再加上这个adapter。这带来一个灵活度同一个基座模型可以挂不同的适配器分别对应不同任务比如一个适配器处理文献综述另一个处理数据报告。切换的成本很低不需要重新部署整个模型。QLoRA则是把量化思想引入LoRA。原始模型用4bit量化加载NF4格式进显存大幅降低显存占用训练过程中LoRA层保持BF16精度。通过这样的设计单张24G卡甚至可以微调32B级别的模型。代价是训练速度比LoRA慢一些因为4bit反量化有额外计算开销。如果你卡不够QLoRA几乎是唯一解。4.2 QLoRA训练流程细节加载、配置、训练、合并这里我给出一套实际可跑的流程基于transformerspeft库。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from trl import SFTTrainer # 4bit量化加载配置 bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, quantization_configbnb_config, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct, trust_remote_codeTrue) tokenizer.pad_token tokenizer.eos_token # 对量化模型做预处理冻结基座准备k-bit训练 model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config)这里有几个关键点。r和lora_alpha的比例我习惯保持lora_alpha是r的2倍即alpha2r突出LoRA的作用强度。target_modules要根据你的基座模型来定不同模型的线性层命名不一样可以用model.named_modules()打印出来一一确认别直接抄网上模板。学习率建议设置在1e-5到2e-5之间SFT训练建议用AdamW优化器。训练参数方面epochs建议3到5轮batch size要配合梯度累积让有效批量达到16到32个样本。如果发现模型过拟合显式背诵训练集降低epochs或者提高LoRA dropout。训练完成后调用的方法是插件合并回主模型merged_model model.merge_and_unload() merged_model.save_pretrained(merged_model_dir, safe_serializationTrue)注意如果你用的是量化模型合并输出后的权重仍然是16bit精度的如果想要4bit模型还需要进一步做GPTQ/AWQ量化不要混淆。4.3 微调后的灾难性遗忘问题排查微调后模型变笨这是最常见的坑。一种表现是领域能力没提升反而下降另一种是通用对话能力变差比如模型忘了如何回答常识问题。原因主要有三个数据质量问题、训练参数问题、以及数据配比问题。数据质量方面最容易翻车的是指令数据里存在回答与问题不匹配。训练完成后模型学到了这种错误模式于是答非所问。我建议训练前清洗至少一轮把每个样本的指令、输入、输出完整读一遍删掉语焉不详或逻辑矛盾的样本。另外输出里不要包含特殊标记符如果输出中有换行或列表要明确规范。训练参数方面学习率过高是遗忘的元凶。LoRA虽然只训练小部分参数但学习率太高同样会破坏原始模型权重在低秩空间的稳定性。出现遗忘时先降学习率到5e-6同时减少训练轮数。数据配比方面如果满眼都是领域数据模型会逐渐变成只按这种风格说话的话痨。建议在训练集中混入20%到30%的通用指令数据来自公开数据集如alpaca等不能全部是领域数据。混入通用数据能极大缓解通用能力退化。5. 知识蒸馏与模型压缩5.1 蒸馏用于私有化的两种路径知识蒸馏是把大模型的能力迁移到小模型的技术。这里的大模型通常指能力强的教师模型小模型指学生模型。在课题组私有化场景下蒸馏有两个典型用途。一是把闭源或超大模型比如几百B的API模型的能力蒸馏到本地7B模型上这样既保留了接近大模型的对话质量又能本地运行。二是把同系列的大模型蒸馏到更小尺寸比如把14B蒸馏到7B或3B进一步降低部署成本。这里要强调蒸馏不等于拿API的输出去微调。一段正规的蒸馏流程需要收集教师模型在大量输入上的输出分布包括对数概率logits而不仅仅是argmax的文本。但实际操作中很多团队拿不到API的logits就退而求其次用教师模型生成的文本来做SFT这叫黑盒蒸馏也是一种可行方案。这种方案效果肯定不如有logits的白盒蒸馏但仍比直接从零训练小模型好得多。5.2 蒸馏数据集构建和教师模型推理记录黑盒蒸馏的核心是构造高质量的输入集合。可以从三个来源收集一是通用开放指令集覆盖基础能力二是领域语料的提问改写用模板或规则生成相关问题三是已有人工标注的问答对。构建的原则是宁缺毋滥一条质量差的教师输出会把学生的能力带偏。教师模型推理时有几个参数需要设置。温度建议在0.7左右太低会变成模式化的重复太高会输出不相关的废话。top_p控制在0.9附近。为了提高多样性可以对同一问题用不同的system prompt和教师温度多次采样然后做相似度去重、分桶存储。生成完成后建议做一个质量过滤用规则过滤掉对不起我不确定这类无意义回答以及过短或明显的胡言乱语。顺带一提蒸馏过程中也要注意教师模型的授权和合规要求。不要把禁止使用的模型输出用于训练其他模型这一点在做之前要确认清楚。我不会展开说具体哪个模型但这已经是行业通用规则了。5.3 蒸馏与微调的取舍有些团队会纠结我已经做了LoRA微调还需要蒸馏吗答案是看目标。如果目标模型是你用来上线服务的7B模型而教师是14B那蒸馏可以让学生在7B尺寸上达到接近14B的效果如果你本来就只打算微调7B那蒸馏的意义就不大不如直接微调。还有一种更实操的组合先用蒸馏让学生掌握通用能力再用LoRA做领域调优。顺序很重要先通用后领域两者叠加效果好反过来如果先领域后蒸馏容易把领域特征蒸馏丢。蒸馏还有个额外优势学生模型是标准的、无adapter的独立权重部署更简单也不用在推理时额外加载LoRA。如果你的课题组要把模型部署到多台机器上或者嵌入到工具中蒸馏得到的独立模型更省心。缺点是需要额外一轮训练跨体系蒸馏的过程往往比你想象的更耗时。6. GPTQ/AWQ量化压缩与vLLM部署6.1 量化的原理与GPTQ/AWQ的选择部署阶段第一个拦路虎就是显存。一个7B的FP16模型光权重就占14GB加上推理时的KV Cache24G卡跑起来也不宽裕。量化就是降低权重精度比如从16bit降到4bit体积直接缩小到原来的四分之一。常见的量化方法有两种训练后量化PTQ和量化感知训练QAT。GPTQ和AWQ都属于PTQ不需要重新训练只需要少量校准数据做离线量化。GPTQ的核心是基于二阶信息做逐层误差补偿它在层内通过Hessian矩阵估计量化误差再逐一补偿权重能在4bit下保持很好的效果。AWQ的思路稍有不同它根据激活值的分布找到重要权重通道对这些通道做缩放保护而不是均等量化。实际体验上AWQ在低比特如4bit下的推理速度通常比GPTQ稍快而GPTQ的模型兼容性更广一些。选择时可以这样看如果你用vLLM做高并发AWQ的预填充和解码速度通常更占优如果你需要把量化后的模型放到transformers原生环境里跑GPTQ支持更成熟。两者都需要校准数据我习惯在量化时每层给128到256条校准样本从训练集中随机采样即可样本质量比数量更重要。6.2 vLLM高并发推理部署配置vLLM的核心优势是使用了PagedAttention把KV Cache像虚拟内存一样分页管理实现了超高显存利用率和连续批处理调度。这意味着多人同时访问的时候它能把不同请求打包成批次最大程度压满GPU算力。我实测过7B模型在vLLM上可以实现比原生transformers高出5到10倍的吞吐量。部署时最简单的路径是使用官方vLLM镜像。一个常见的部署场景是docker run --runtime nvidia --gpus all \ -v ~/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct-AWQ \ --served-model-name qwen7b \ --quantization awq \ --max-model-len 32768 \ --tensor-parallel-size 1这里解释几个参数。--max-model-len设的是最大上下文长度越长占用的KV Cache越多显存不够时要往下调。--tensor-parallel-size是多卡并行数单卡设1两张卡也可以设2。启动后它会提供一个OpenAI兼容的接口你只要把API base改成http://localhost:8000/v1就能像调用OpenAI一样调用本地模型。如果你看到社区里有docker vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b这类热词其实是在问vLLM是否支持embedding模型加载。答案是可以但需要特定的启动方式。vLLM从某个版本开始支持了embedding模型的部署但参数和chat模型不同需要指定--task embed并确保你的vLLM版本足够新。更稳妥的做法还是单独部署embedding服务用一个轻量工具如FastAPI包一层防止版本兼容问题。6.3 从Ollama/LM Studio到vLLM的迁移和共存很多课题组最初图省事用Ollama或LM Studio在本地跑模型。它们的好处是安装简单、对硬件要求低、几行命令就能跑起来。但缺点也很明显并发能力弱、吞吐量低、没有动态批处理。如果只是一个人偶尔实验Ollama完全够用如果做成了组内共享服务三五个人同时用就可能排队卡顿。我建议的共存方式是个人开发调试阶段用Ollama跑FP16或GGUF量化模型方便快速测试正式部署阶段用vLLM跑AWQ或GPTQ量化模型做到高并发。两者可以并存模型权重可以各有各的格式互不干扰。迁移时注意Ollama用的是GGUF格式vLLM一般优先支持HF格式的GPTQ/AWQ模型所以需要先下载或转换一个HF格式的量化权重再用vLLM加载。很多人也会用llama.cpp的量化格式直接跑CPU推理这在没有GPU的机器上确实很有用。但CPU推理的吞吐量远低于GPU如果课题组有哪怕一张旧显卡都建议优先用GPUvLLM。6.4 显存估算和并发参数调整跑vLLM之前先算一笔账。假设7B模型4bit量化权重占约4GB每一条请求的KV Cache大约需要2 * num_layers * num_kv_heads * head_dim * seq_len * dtype_size字节。举个例子Qwen2.5-7B有28层KV heads为4head_dim为128上下文按4096算单条请求的KV Cache大约为2*28*4*128*4096*2字节约等于60MB。如果你的显存是24G减去4G权重和2G预留留给KV Cache的是18G理论上能支撑大约300条并发请求。实际不会拉满建议控制在20%以下的动态并发量避免内存溢出。再补充一个排查技巧如果启动vLLM时报CUDA out of memory优先检查是不是--max-model-len设得太大这会导致预分配KV Cache过大其次是降低--gpu-memory-utilization比如从默认0.9调至0.8。不要一上来就调低--max-num-seqs因为本来要靠并发拉吞吐自断手脚不划算。7. 常见问题排查与经验心得7.1 知识库检索效果差的排查清单这一节直接给一个盘查列表RAG效果差的时候按顺序过一遍。第一检查分块质量。随便抽十块文本看看是否语义完整表格有没有乱掉。如果乱掉换保留版式的分块工具。第二检查embedding模型的语义空间匹配。试试换一个更大或更对口的中文模型有时模型没选对调其他参数都没用。第三检查检索策略。只用了向量检索精度不足是正常的加上BM25混合检索。第四检查rerank环节。没加rerank的加上bge-reranker。第五检查提示词。你的知识库提示如果只是简单说用上面参考信息回答问题模型不会主动区分新旧知识建议加一句如果参考信息不足以回答直接说不知道不要编造。有读者问到RAG的瓶颈是什么我的回答是最大的瓶颈不在模型而在数据治理。很多知识库效果差根因是文档没有清理切分没有结构同类信息散落各处导致检索结果碎片化。数据治理不到位后面的所有优化手段都是补救。7.2 微调显存不足与训练不收敛问题显存不足的应对顺序是先开CPU offload还是不太好优先尝试更小的batch size加梯度累积这是习惯做法还不行就尝试更小的模型最后才考虑把注意力层也量化。千万别忽略gradient_checkpointing这个开关能省大量显存对速度影响有限。训练不收敛的表现是loss不降或剧烈震荡。先排查学习率过高会震荡过低会爬得很慢可以尝试在整个训练过程中加一个warmup阶段。再看数据集指令数据里如果出现大量重复的输入模型会过拟合于特定表达导致验证集表现差。最后看LoRA配置r太小则模型容量不够建议从16起步实验二范数约束用unsloth库可以进一步稳定训练。7.3 微调与RAG的边界怎么划时不时有人问我已经做了RAG还需要微调吗或者反过来问我已经微调了为什么还要RAG。我直接给结论两者解决的问题不同。RAG解决的是模型不知道答案但库里有微调解决的是模型知道内容但输出风格和格式不对。具体到你的场景如果错误答案都是内容有误、引用错误先优化RAG如果错误答案是内容正确但表达不规范、废话太多、不懂术语缩写再考虑微调。两者应该是组合不是替代。我见过最成功的课题组实践是把RAG当作系统底座把微调当作系统的一根定制天线。系统架构上先查知识库再把检索结果和问题一起交给微调过的模型。这样专业知识来源可靠表达也贴合内部规范两边的好处都拿到了。7.4 部署阶段的几条独家经验最后再分享几个我在真实部署中积累的小经验这些在官方文档里很难一次性看到。第一用容器化方式部署时记得挂载--ipchost或设置--shm-size1g。vLLM和Dataloader在多进程数据交换时共享内存太小会报奇怪的错误很多人踩过这个坑。第二如果加载模型一直卡住检查huggingface的缓存目录权限以及是否设了HF_HUB_OFFLINE。第三使用AWQ量化后的模型时部分旧版本vLLM需要在启动命令里显式加--quantization awq否则会加载失败。如果用的是最新版很多情况下会自动识别但保险起见还是手动指定。第四关于热词里提到的vllm部署deepseek我的建议是去vLLM官方文档查一下你关心的版本是否支持DeepSeek的某几个特殊模块。DeepSeek系列训练和推理都用了一些自定义实现老版本vLLM确实有不支持的坑升级到最新版本、并且从Hugging Face下载正确的配置文件可以最大程度避免问题。第五部署完成后一定要做并发压测可以用locust或最简单的脚本并发请求。我遇到很多团队部署好了单条测试没问题一开放给全组用就一个个报错原因就是并发超过了显存里的KV Cache预算。最后说一句我个人的真实体会做课题组私有AI最难的不是技术而是预期管理。团队里总有人期待本地模型什么都能干也总有人担心私有AI是重复造轮子。我的建议是先从一个小而具体的场景切入比如自动生成周报或从实验记录里提取关键参数把RAG和微调这条链路完整跑通一次再慢慢扩展。小场景跑通带来的正反馈比一上来就铺一个大而全的私有平台有效得多。技术选型永远是为解决实际问题服务的模型跑多大、用不用蒸馏、量化到几bit都应该由你的数据、算力和真实业务场景来决定。如果你已经决定要动手了我的最后一条建议是先别急着下载最大的模型也别急着写微调代码。花两天时间把题组里最高频的50个问题写下来对应给出标准答案然后带着这50个问题去测试通用模型、RAG方案和微调后的效果。有了这50个问题的baseline后续每一个技术决策都会变得非常清晰。这是我在多个项目里验证过最有效的启动方式。
课题组私有AI实战：开源模型选型、RAG检索、LoRA微调与vLLM部署
1. 课题组私有AI的整体设计思路1.1 先想清楚从直接调用API到本地私有化的转变先描述一个我见过无数次的场景课题组里几个博士生和老师一起做项目最初都是直接调用通用大模型的API写写摘要、改改邮件、做点初稿润色确实很快。但用了三个月后问题就暴露了——通用模型不熟悉课题组的专业术语。举个例子同样是压裂曲线通用模型可能理解成材料疲劳但课题组要的是非常明确的工程语义。更麻烦的是文献数据不能总是放到公有云API里很多项目合同和研究数据有保密要求你总不能把未发表的实验数据发给外部服务。所以课题组私有AI这个说法本质上是两件事一是让模型真正懂你这个领域二是让模型运行在你自己的可控环境里。从技术路径上看实现私有AI有几种做法直接用现成的开源模型跑推理这是最简单但效果最有限的只做RAG知识库增强不改模型权重适合快速落地做领域微调改变模型行为习惯让它更贴合任务再把两者结合微调RAG这是课题组落地最常见、效果也最稳的组合。我见过不少团队一上来就想全参数微调一个几十B的模型结果显卡不够、数据不够最后项目烂尾。正确思路应该是先用小步快跑的方式验证先用RAG解决知识不足再用LoRA解决能力不对齐最后再考虑蒸馏和量化。1.2 技术选型的整体考量开源模型、算力、数据三要素课题组私有AI的选型我习惯用一个三要素框架来看模型基座、算力预算、数据资产。模型基座决定了效果上限算力预算决定了你能跑多大的模型数据资产决定了你能把下限拉高多少。三者的关系很像做饭模型是锅算力是火数据是食材。锅再好火不够食材平平做不出硬菜食材再好锅太差也发挥不出来。先说算力预算这是先决条件。一张单卡显存24G的RTX 3090/4090大概能跑7B-14B模型的量化版本两张卡可以跑32B级别的量化如果你们实验室有A100或H100那直接考虑训练和部署更大规模。对于大多数课题组的预算我建议把首选目标放在7B-14B这个档位。别小看这一档经过领域微调和RAG加持它在专业任务上完全可以超过一个更大参数的通用模型。再说数据资产。一个课题组真正拥有的是论文、实验记录、仿真数据、历史项目文档、专利和学位论文。这些材料里可能有几十万token也可能有几百万token。数据质量比数量重要得多尤其是微调场景几千条精心构造的指令数据效果可能比几万条粗糙爬来的数据更好。所以设计私有AI的第一步永远不是选模型而是先盘点你手里到底有什么数据。最后回到模型基座。目前国产开源模型已经非常成熟Qwen系列、DeepSeek、ChatGLM系列都是可选的。选型的时候不能只看榜单分数还要看中文能力、长文本表现、生态工具链以及社区里有没有人踩过坑。这块我在下一节详细展开。1.3 一条可落地的路线微调、知识库、量化、推理四步走我强烈建议课题组按照下面这条路径推进而不是并行乱试第一步先搭一个基线环境直接把选定的开源模型跑起来用几个典型任务比如从实验记录中抽取参数、回答问题测试效果。第二步构建领域知识库用RAG解决模型不知道的问题这一步见效最快通常一两周就能看出明显提升。第三步用LoRA或QLoRA做领域微调解决模型会但做得不规范的问题比如让它学会你课题组的写作风格、格式要求。第四步做量化压缩和推理部署把模型体积和显存占用降下来用vLLM支撑多人同时访问。这套路径的核心逻辑是先用轻量手段解决最大的痛点再逐步深入。如果一开始就埋头微调很可能微调完了发现效果还没RAG好因为你的数据量不够或者指令设计不合理。反过来如果只做RAG模型对领域表达方式的适配能力始终有限。两者结合才是正路。2. 开源模型选型与领域语料构建2.1 国产开源模型怎么挑Qwen、DeepSeek、ChatGLM的选择逻辑现在说到选型我的建议比较明确大部分课题组可以直接从Qwen系列入手。Qwen2.5和Qwen3系列的中文能力、代码能力、指令跟随能力都比较均衡而且社区生态特别好从Hugging Face到ModelScope都有完善的权重和示例。尤其是Qwen3MoE架构和密集架构都有参数档位覆盖从0.6B到235B绝大多数课题组都能找到合适的尺寸。对于需要高效推理的团队Qwen3的MoE版本在推理速度上很有优势但显存占用会高一些需要权衡。DeepSeek也很强尤其DeepSeek-R1系列在推理任务上的表现有目共睹。但有些团队的显卡可能跑不动完整的R1蒸馏版本反而更实用。ChatGLM系列目前迭代到ChatGLM4它在中文场景稳定但生态比Qwen略窄一些。我的经验是主攻自然语言理解、文本生成、文献处理的课题组选Qwen主攻数学推理、代码生成且算力充足的团队可以看DeepSeek需要长文本处理且希望中文风格稳定的可以考虑GLM系列。一个容易被忽略的点是一定要看模型的许可证。部分开源模型对商用有额外限制课题组内部研究通常没问题但如果和外部企业有合作或者将来想发开源项目务必先查清楚。另外选模型时也要看tokenizer是否适合你的领域。比如代码混合场景多的Qwen的tokenizer压缩率更好纯中文文献多的几个模型差异不大。2.2 领域语料构建清洗、去重、格式转换语料构建这件事听起来简单做起来全是细节。很多团队直接把PDF文档丢给模型处理效果很差因为PDF提取出来往往带页码、页眉页脚、乱码、图表错位。我建议先走一遍标准清洗流程。文本提取可以用PaddleOCR配合版面分析也可以用一些专项工具如MinerU、marker等从PDF中抽取Markdown格式文本效果比直接pdftotext好得多。提取后要做以下几步清洗去除页眉页脚、参考文献列表、重复段落把全角标点统一成半角删除只包含数字和符号的行对段落做合并和分段保持语义完整。清洗完成后需要做去重。课题组文档里相似内容极多比如同一组实验数据在开题报告、中期报告、结题报告里反复出现。可以使用MinHash或SimHash基于文本相似度去重保底也要做一次精确的md5去重。还有一个常被忽略的步骤是格式转换。不同的下游应用需要不同格式RAG库需要分块后的文本微调需要指令对数据集继续预训练需要纯文本语料。所以建议在清洗之后先保存一份规范的纯文本语料库比如JSONL格式每行是一段再从这个中间格式派生出RAG分块和微调指令避免重复清洗。2.3 语料规模与质量权衡什么时候该做继续预训练在讲微调之前必须把继续预训练continual pretraining和指令微调SFT区分开。很多课题组搞混了拿着领域语料直接做SFT结果发现模型变笨了因为SFT的数据格式要求是指令-回答不是知识文本。如果你有一大批领域文献、专利文本想让模型博闻强识应该做继续预训练让模型在领域语料上继续学习语言和知识。但继续预训练的成本比SFT高很多因为学习率要小、步数要长、且容易遗忘通用能力。那什么时候有必要做继续预训练我的判断标准是如果领域语料超过1亿token并且通用模型在这种专业文本上几乎无法理解基本术语才建议考虑。对于大多数课题组几百万token的语料更合理的做法是做RAG让模型在推理时去检索知识而不是把几百万token硬塞进权重里。硬塞进去的后果是训练成本高、更新困难且还有遗忘风险。正确的知识更新方式应该是更新知识库而不是频繁重新微调。先做好这个判断能帮你省下大量算力和时间。3. RAG检索增强知识库落地实践3.1 RAG到底是什么为什么课题组知识库首选它RAGRetrieval-Augmented Generation的思路很简单在模型回答问题之前先从外部知识库中检索出相关文本片段拼进上下文里再让模型结合这些片段生成答案。我把RAG理解成开卷考试——模型不需要把所有的书都背下来只要考试的时候会翻书、会引用就行。这个特性对课题组来说太合适了因为课题组的知识是持续增长的今天来了新一批实验数据明天可能就有新论文这些内容只需要更新知识库索引就够了不需要重训模型。RAG还有一个隐性优势可以溯源。模型答完题你能告诉用户答案来自哪份文档哪个段落这对科研场景非常重要。纯微调模型做不到这一点它只能给你一个无法验证的答案。所以即使你后面做了微调也建议保留RAG层形成微调负责表达能力RAG负责事实来源的组合。3.2 开源知识库拆解工具与 embedding 模型选择知识库构建的第一步是文档拆解。很多人用langchain的简单TextSplitter按固定字符大小切分效果很差——会把表格拆成乱码把一段完整的推导过程切得七零八落。更好的做法是用保留版式结构的切分器。我实际用下来比较稳的方案是先用MinerU或LayoutReader做版面分析把PDF转成Markdown保留标题层级再按标题和段落结构进行语义切分设置分块大小在500到800个token之间分块重叠控制在50到100个token。这样切出来的块不会把语义切断检索效果也更好。做RAG知识库时有一个热词是RAG知识库能存储图片吗很多人问。其实是可以的但要注意方式目前主流的 embedding 模型不支持直接对图片内容向量化你需要先用视觉语言模型比如Qwen-VL把图片内容转换成文字描述再把描述入库。对于图表类图片这套方案格外好用。另外也可以把图片本身作为附件存起来检索到相关文字描述后再把图片返回给用户看但纯向量检索是检索不到像素的。embedding 模型的选择也很有讲究。目前常用的中英文模型有BGE系列、Qwen3-Embedding、M3E等。我建议按这个思路选如果主要处理中文文献BGE-large-zh或Qwen3-Embedding-0.6B都不错如果中英混杂可以用BGE-M3它支持多语言且能输出稀疏和稠密两种向量。有一点要记住embedding模型的输入长度有限通常是512或1024 token分块大小要根据它来设计。另外还要注意embedding模型更新后必须重建整个索引否则新旧向量无法对比。3.3 检索优化混合检索、rerank、命中率提升只靠向量检索往往不够。向量检索擅长找语义相似但精确匹配能力弱比如文献编号GB/T 1234-2020这类精确信息语义向量很容易找错。所以我强烈建议做混合检索同时跑向量检索和BM25关键词检索再把两路结果合并。开源的Elasticsearch或MeiliSearch都支持BM25也可以直接用Milvus或Qdrant的混合检索能力。合并之后还有一个提升命中率的利器rerank。向量检索先召回top50再用一个交叉编码器模型比如bge-reranker对这50个候选块做精排选出top5喂给大模型。这一步对最终答案质量影响极大我实测过加了rerank之后回答的引用准确率能提升20%以上。衡量RAG效果不能只看最终回答好不好更核心的指标是检索命中率hit rate和MRR。命中率指在检索候选里是否包含正确文档MRR看正确文档排在第几位。调优时可以把测试数据做成问题标准答案来自哪个文档块的形式用检索API反复测命中率。如果命中率低先调分块大小、重叠数、检索topK再考虑重切分或改embedding模型。3.4 本体与Agentic RAG的进阶玩法社区最近在热聊ontology RAG和Agentic RAG。前者是把领域知识结构化成本体实体、关系、属性再用图数据库存储和检索。比如你的课题涉及材料、工艺、性能三类实体本体RAG就能支持所有做过X工艺的材料里哪种的耐腐蚀性最好这种跨实体推理问题传统向量库做不到。构建本体需要人工整理但一旦建成效果拔群。Agentic RAG则更进一步把检索过程交给一个Agent来编排。它会先理解用户问题然后自主决定是查向量库、查数据库还是查Web甚至多步检索再综合回答。开发难度也随之增大但对于课题组的一些复杂调试场景比如帮我找出去年实验中所有异常数据并分析原因Agentic RAG能自动迭代查询体验比一次性检索好很多。新手建议先把基础RAG跑通再做这些进阶形态。4. LoRA/QLoRA高效微调实战4.1 为什么选LoRA而不是全参数微调如果直接全参数微调7B模型即使是AdamW优化器也要至少60GB以上的显存这直接把绝大多数课题组排除在外。LoRALow-Rank Adaptation的大思路是冻结原始模型的所有参数只在旁边加一个低秩矩阵作为可训练的适配器。这样可训练参数量通常只有原来的0.5%到1%。比如7B模型LoRA只训练几十到一百多M的参数显存需求大幅下降单张24G卡就能跑。LoRA训练出的适配器是一个很小的权重文件使用的时候加载原始模型再加上这个adapter。这带来一个灵活度同一个基座模型可以挂不同的适配器分别对应不同任务比如一个适配器处理文献综述另一个处理数据报告。切换的成本很低不需要重新部署整个模型。QLoRA则是把量化思想引入LoRA。原始模型用4bit量化加载NF4格式进显存大幅降低显存占用训练过程中LoRA层保持BF16精度。通过这样的设计单张24G卡甚至可以微调32B级别的模型。代价是训练速度比LoRA慢一些因为4bit反量化有额外计算开销。如果你卡不够QLoRA几乎是唯一解。4.2 QLoRA训练流程细节加载、配置、训练、合并这里我给出一套实际可跑的流程基于transformerspeft库。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from trl import SFTTrainer # 4bit量化加载配置 bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, quantization_configbnb_config, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct, trust_remote_codeTrue) tokenizer.pad_token tokenizer.eos_token # 对量化模型做预处理冻结基座准备k-bit训练 model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config)这里有几个关键点。r和lora_alpha的比例我习惯保持lora_alpha是r的2倍即alpha2r突出LoRA的作用强度。target_modules要根据你的基座模型来定不同模型的线性层命名不一样可以用model.named_modules()打印出来一一确认别直接抄网上模板。学习率建议设置在1e-5到2e-5之间SFT训练建议用AdamW优化器。训练参数方面epochs建议3到5轮batch size要配合梯度累积让有效批量达到16到32个样本。如果发现模型过拟合显式背诵训练集降低epochs或者提高LoRA dropout。训练完成后调用的方法是插件合并回主模型merged_model model.merge_and_unload() merged_model.save_pretrained(merged_model_dir, safe_serializationTrue)注意如果你用的是量化模型合并输出后的权重仍然是16bit精度的如果想要4bit模型还需要进一步做GPTQ/AWQ量化不要混淆。4.3 微调后的灾难性遗忘问题排查微调后模型变笨这是最常见的坑。一种表现是领域能力没提升反而下降另一种是通用对话能力变差比如模型忘了如何回答常识问题。原因主要有三个数据质量问题、训练参数问题、以及数据配比问题。数据质量方面最容易翻车的是指令数据里存在回答与问题不匹配。训练完成后模型学到了这种错误模式于是答非所问。我建议训练前清洗至少一轮把每个样本的指令、输入、输出完整读一遍删掉语焉不详或逻辑矛盾的样本。另外输出里不要包含特殊标记符如果输出中有换行或列表要明确规范。训练参数方面学习率过高是遗忘的元凶。LoRA虽然只训练小部分参数但学习率太高同样会破坏原始模型权重在低秩空间的稳定性。出现遗忘时先降学习率到5e-6同时减少训练轮数。数据配比方面如果满眼都是领域数据模型会逐渐变成只按这种风格说话的话痨。建议在训练集中混入20%到30%的通用指令数据来自公开数据集如alpaca等不能全部是领域数据。混入通用数据能极大缓解通用能力退化。5. 知识蒸馏与模型压缩5.1 蒸馏用于私有化的两种路径知识蒸馏是把大模型的能力迁移到小模型的技术。这里的大模型通常指能力强的教师模型小模型指学生模型。在课题组私有化场景下蒸馏有两个典型用途。一是把闭源或超大模型比如几百B的API模型的能力蒸馏到本地7B模型上这样既保留了接近大模型的对话质量又能本地运行。二是把同系列的大模型蒸馏到更小尺寸比如把14B蒸馏到7B或3B进一步降低部署成本。这里要强调蒸馏不等于拿API的输出去微调。一段正规的蒸馏流程需要收集教师模型在大量输入上的输出分布包括对数概率logits而不仅仅是argmax的文本。但实际操作中很多团队拿不到API的logits就退而求其次用教师模型生成的文本来做SFT这叫黑盒蒸馏也是一种可行方案。这种方案效果肯定不如有logits的白盒蒸馏但仍比直接从零训练小模型好得多。5.2 蒸馏数据集构建和教师模型推理记录黑盒蒸馏的核心是构造高质量的输入集合。可以从三个来源收集一是通用开放指令集覆盖基础能力二是领域语料的提问改写用模板或规则生成相关问题三是已有人工标注的问答对。构建的原则是宁缺毋滥一条质量差的教师输出会把学生的能力带偏。教师模型推理时有几个参数需要设置。温度建议在0.7左右太低会变成模式化的重复太高会输出不相关的废话。top_p控制在0.9附近。为了提高多样性可以对同一问题用不同的system prompt和教师温度多次采样然后做相似度去重、分桶存储。生成完成后建议做一个质量过滤用规则过滤掉对不起我不确定这类无意义回答以及过短或明显的胡言乱语。顺带一提蒸馏过程中也要注意教师模型的授权和合规要求。不要把禁止使用的模型输出用于训练其他模型这一点在做之前要确认清楚。我不会展开说具体哪个模型但这已经是行业通用规则了。5.3 蒸馏与微调的取舍有些团队会纠结我已经做了LoRA微调还需要蒸馏吗答案是看目标。如果目标模型是你用来上线服务的7B模型而教师是14B那蒸馏可以让学生在7B尺寸上达到接近14B的效果如果你本来就只打算微调7B那蒸馏的意义就不大不如直接微调。还有一种更实操的组合先用蒸馏让学生掌握通用能力再用LoRA做领域调优。顺序很重要先通用后领域两者叠加效果好反过来如果先领域后蒸馏容易把领域特征蒸馏丢。蒸馏还有个额外优势学生模型是标准的、无adapter的独立权重部署更简单也不用在推理时额外加载LoRA。如果你的课题组要把模型部署到多台机器上或者嵌入到工具中蒸馏得到的独立模型更省心。缺点是需要额外一轮训练跨体系蒸馏的过程往往比你想象的更耗时。6. GPTQ/AWQ量化压缩与vLLM部署6.1 量化的原理与GPTQ/AWQ的选择部署阶段第一个拦路虎就是显存。一个7B的FP16模型光权重就占14GB加上推理时的KV Cache24G卡跑起来也不宽裕。量化就是降低权重精度比如从16bit降到4bit体积直接缩小到原来的四分之一。常见的量化方法有两种训练后量化PTQ和量化感知训练QAT。GPTQ和AWQ都属于PTQ不需要重新训练只需要少量校准数据做离线量化。GPTQ的核心是基于二阶信息做逐层误差补偿它在层内通过Hessian矩阵估计量化误差再逐一补偿权重能在4bit下保持很好的效果。AWQ的思路稍有不同它根据激活值的分布找到重要权重通道对这些通道做缩放保护而不是均等量化。实际体验上AWQ在低比特如4bit下的推理速度通常比GPTQ稍快而GPTQ的模型兼容性更广一些。选择时可以这样看如果你用vLLM做高并发AWQ的预填充和解码速度通常更占优如果你需要把量化后的模型放到transformers原生环境里跑GPTQ支持更成熟。两者都需要校准数据我习惯在量化时每层给128到256条校准样本从训练集中随机采样即可样本质量比数量更重要。6.2 vLLM高并发推理部署配置vLLM的核心优势是使用了PagedAttention把KV Cache像虚拟内存一样分页管理实现了超高显存利用率和连续批处理调度。这意味着多人同时访问的时候它能把不同请求打包成批次最大程度压满GPU算力。我实测过7B模型在vLLM上可以实现比原生transformers高出5到10倍的吞吐量。部署时最简单的路径是使用官方vLLM镜像。一个常见的部署场景是docker run --runtime nvidia --gpus all \ -v ~/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct-AWQ \ --served-model-name qwen7b \ --quantization awq \ --max-model-len 32768 \ --tensor-parallel-size 1这里解释几个参数。--max-model-len设的是最大上下文长度越长占用的KV Cache越多显存不够时要往下调。--tensor-parallel-size是多卡并行数单卡设1两张卡也可以设2。启动后它会提供一个OpenAI兼容的接口你只要把API base改成http://localhost:8000/v1就能像调用OpenAI一样调用本地模型。如果你看到社区里有docker vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b这类热词其实是在问vLLM是否支持embedding模型加载。答案是可以但需要特定的启动方式。vLLM从某个版本开始支持了embedding模型的部署但参数和chat模型不同需要指定--task embed并确保你的vLLM版本足够新。更稳妥的做法还是单独部署embedding服务用一个轻量工具如FastAPI包一层防止版本兼容问题。6.3 从Ollama/LM Studio到vLLM的迁移和共存很多课题组最初图省事用Ollama或LM Studio在本地跑模型。它们的好处是安装简单、对硬件要求低、几行命令就能跑起来。但缺点也很明显并发能力弱、吞吐量低、没有动态批处理。如果只是一个人偶尔实验Ollama完全够用如果做成了组内共享服务三五个人同时用就可能排队卡顿。我建议的共存方式是个人开发调试阶段用Ollama跑FP16或GGUF量化模型方便快速测试正式部署阶段用vLLM跑AWQ或GPTQ量化模型做到高并发。两者可以并存模型权重可以各有各的格式互不干扰。迁移时注意Ollama用的是GGUF格式vLLM一般优先支持HF格式的GPTQ/AWQ模型所以需要先下载或转换一个HF格式的量化权重再用vLLM加载。很多人也会用llama.cpp的量化格式直接跑CPU推理这在没有GPU的机器上确实很有用。但CPU推理的吞吐量远低于GPU如果课题组有哪怕一张旧显卡都建议优先用GPUvLLM。6.4 显存估算和并发参数调整跑vLLM之前先算一笔账。假设7B模型4bit量化权重占约4GB每一条请求的KV Cache大约需要2 * num_layers * num_kv_heads * head_dim * seq_len * dtype_size字节。举个例子Qwen2.5-7B有28层KV heads为4head_dim为128上下文按4096算单条请求的KV Cache大约为2*28*4*128*4096*2字节约等于60MB。如果你的显存是24G减去4G权重和2G预留留给KV Cache的是18G理论上能支撑大约300条并发请求。实际不会拉满建议控制在20%以下的动态并发量避免内存溢出。再补充一个排查技巧如果启动vLLM时报CUDA out of memory优先检查是不是--max-model-len设得太大这会导致预分配KV Cache过大其次是降低--gpu-memory-utilization比如从默认0.9调至0.8。不要一上来就调低--max-num-seqs因为本来要靠并发拉吞吐自断手脚不划算。7. 常见问题排查与经验心得7.1 知识库检索效果差的排查清单这一节直接给一个盘查列表RAG效果差的时候按顺序过一遍。第一检查分块质量。随便抽十块文本看看是否语义完整表格有没有乱掉。如果乱掉换保留版式的分块工具。第二检查embedding模型的语义空间匹配。试试换一个更大或更对口的中文模型有时模型没选对调其他参数都没用。第三检查检索策略。只用了向量检索精度不足是正常的加上BM25混合检索。第四检查rerank环节。没加rerank的加上bge-reranker。第五检查提示词。你的知识库提示如果只是简单说用上面参考信息回答问题模型不会主动区分新旧知识建议加一句如果参考信息不足以回答直接说不知道不要编造。有读者问到RAG的瓶颈是什么我的回答是最大的瓶颈不在模型而在数据治理。很多知识库效果差根因是文档没有清理切分没有结构同类信息散落各处导致检索结果碎片化。数据治理不到位后面的所有优化手段都是补救。7.2 微调显存不足与训练不收敛问题显存不足的应对顺序是先开CPU offload还是不太好优先尝试更小的batch size加梯度累积这是习惯做法还不行就尝试更小的模型最后才考虑把注意力层也量化。千万别忽略gradient_checkpointing这个开关能省大量显存对速度影响有限。训练不收敛的表现是loss不降或剧烈震荡。先排查学习率过高会震荡过低会爬得很慢可以尝试在整个训练过程中加一个warmup阶段。再看数据集指令数据里如果出现大量重复的输入模型会过拟合于特定表达导致验证集表现差。最后看LoRA配置r太小则模型容量不够建议从16起步实验二范数约束用unsloth库可以进一步稳定训练。7.3 微调与RAG的边界怎么划时不时有人问我已经做了RAG还需要微调吗或者反过来问我已经微调了为什么还要RAG。我直接给结论两者解决的问题不同。RAG解决的是模型不知道答案但库里有微调解决的是模型知道内容但输出风格和格式不对。具体到你的场景如果错误答案都是内容有误、引用错误先优化RAG如果错误答案是内容正确但表达不规范、废话太多、不懂术语缩写再考虑微调。两者应该是组合不是替代。我见过最成功的课题组实践是把RAG当作系统底座把微调当作系统的一根定制天线。系统架构上先查知识库再把检索结果和问题一起交给微调过的模型。这样专业知识来源可靠表达也贴合内部规范两边的好处都拿到了。7.4 部署阶段的几条独家经验最后再分享几个我在真实部署中积累的小经验这些在官方文档里很难一次性看到。第一用容器化方式部署时记得挂载--ipchost或设置--shm-size1g。vLLM和Dataloader在多进程数据交换时共享内存太小会报奇怪的错误很多人踩过这个坑。第二如果加载模型一直卡住检查huggingface的缓存目录权限以及是否设了HF_HUB_OFFLINE。第三使用AWQ量化后的模型时部分旧版本vLLM需要在启动命令里显式加--quantization awq否则会加载失败。如果用的是最新版很多情况下会自动识别但保险起见还是手动指定。第四关于热词里提到的vllm部署deepseek我的建议是去vLLM官方文档查一下你关心的版本是否支持DeepSeek的某几个特殊模块。DeepSeek系列训练和推理都用了一些自定义实现老版本vLLM确实有不支持的坑升级到最新版本、并且从Hugging Face下载正确的配置文件可以最大程度避免问题。第五部署完成后一定要做并发压测可以用locust或最简单的脚本并发请求。我遇到很多团队部署好了单条测试没问题一开放给全组用就一个个报错原因就是并发超过了显存里的KV Cache预算。最后说一句我个人的真实体会做课题组私有AI最难的不是技术而是预期管理。团队里总有人期待本地模型什么都能干也总有人担心私有AI是重复造轮子。我的建议是先从一个小而具体的场景切入比如自动生成周报或从实验记录里提取关键参数把RAG和微调这条链路完整跑通一次再慢慢扩展。小场景跑通带来的正反馈比一上来就铺一个大而全的私有平台有效得多。技术选型永远是为解决实际问题服务的模型跑多大、用不用蒸馏、量化到几bit都应该由你的数据、算力和真实业务场景来决定。如果你已经决定要动手了我的最后一条建议是先别急着下载最大的模型也别急着写微调代码。花两天时间把题组里最高频的50个问题写下来对应给出标准答案然后带着这50个问题去测试通用模型、RAG方案和微调后的效果。有了这50个问题的baseline后续每一个技术决策都会变得非常清晰。这是我在多个项目里验证过最有效的启动方式。
