企业官网建设流程全解析

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都有完善的权重和示例。尤其是Qwen3，MoE架构和密集架构都有，参数档位覆盖从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到底是什么，为什么课题组知识库首选它

RAG（Retrieval-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以上的显存，这直接把绝大多数课题组排除在外。LoRA（Low-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训练流程细节：加载、配置、训练、合并

这里我给出一套实际可跑的流程，基于transformers+peft库。

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_4bit=True, bnb_4bit_use_double_quant=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16 ) model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B-Instruct", quantization_config=bnb_config, device_map="auto", ) tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct", trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token # 对量化模型做预处理：冻结基座，准备k-bit训练 model = prepare_model_for_kbit_training(model) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config)

这里有几个关键点。r和lora_alpha的比例我习惯保持lora_alpha是r的2倍，即alpha=2r，突出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_serialization=True)

注意，如果你用的是量化模型，合并输出后的权重仍然是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 Cache，24G卡跑起来也不宽裕。量化就是降低权重精度，比如从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 \ --ipc=host \ 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，如果课题组有哪怕一张旧显卡，都建议优先用GPU+vLLM。

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为4，head_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 部署阶段的几条独家经验

最后再分享几个我在真实部署中积累的小经验，这些在官方文档里很难一次性看到。

第一，用容器化方式部署时，记得挂载--ipc=host或设置--shm-size=1g。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，后续每一个技术决策都会变得非常清晰。这是我在多个项目里验证过最有效的启动方式。