一线架构案例库

A100 80G跑7B按理说不至于并发50就OOM啊，你检查下是不是max_num_seqs和gpu_memory_utilization没调好，vLLM默认预留比例挺保守的。int8其实对显存帮助有限，真要省直接上4bit AWQ或GPTQ，7B大概5G多权重，剩下全给KV cache，50并发问题不大。PagedAttention本来就是vLLM自带的，你确认下版本别太老。多进程共享显存那条路

几千条数据训到0.8卡住其实挺常见，别太焦虑。我建议先把训练集和验证集的loss曲线都拉出来看，要是验证loss还在降只是训练震荡，那大概率是学习率偏大或者batch太小导致的梯度噪声，跟数据关系不大。另外可以抽几条样本手动过一遍token长度分布，padding占比太高确实会稀释有效梯度，试试按长度分桶或者用packing。还有一点容易被忽略，LoRA的target module是不是只加了q和

有没有更详细的教程推荐？

几十万切片Chroma够用，真上生产再迁Milvus也不迟，别提前焦虑。

这问题我也遇到过，感觉是agent类工具的通病，它拿到上下文后总想“顺手优化”一下。我后来在rules里加了句：只允许修改与报错直接相关的行，其他一律不准碰，再配合让它先列改动计划再动手，稍微好点。还有个偏方是先把无关文件从上下文里排除掉，减少它自由发挥的空间。实在不行就分两步，先让它只定位问题别改，确认后再单独下指令改那一处。

微调时没混工具调用格式的话，MCP塞回来的tool result模型确实会懵，建议把工具调用样本加进训练数据里。

顺序这事儿确实挺关键的，我踩过类似的坑。你描述的情况我怀疑不只是顺序问题，而是chunk之间的语义连贯性被切碎了，模型看到一堆孤立片段自然拼不出完整逻辑。我自己的经验是，单纯调顺序收益有限，上reranker才是质变的那一步，bge-reranker-v2-m3性价比挺高，本地跑也不贵。但重排只是把最相关的排前面，跨chunk的答案还是可能断，我后来加了一层相邻chunk扩展，就是命中某个chun

7B写复杂SQL确实容易翻车，换CodeQwen或14B会好很多，模板的话可以看看LangChain的SQL agent提示词。

80万这个量级其实两家都能扛，但你担心的点挺实在。我这边用Qdrant跑过千万级，带payload过滤的混合检索延迟稳定在几十毫秒，它那个filterable HNSW做得确实不错，不用太怕涨量。Milvus功能多是真多，但部署和运维成本摆在那，小团队容易把自己拖进去。至于K8s，除非你后面要上集群分片或者多租户，不然单机加好SSD就够撑到千万级了。

上线后飘多半是召回不稳，先把top5提到10看命中率，再查embedding对内部术语是不是真拉胯。

你这个情况我遇到过，LangChain的ConversationBufferMemory确实容易把不同轮次搞混。后来我换了个思路，每轮只把上一轮的“用户问题+Agent摘要结果”拼进prompt，工具调用日志单独存，不往context里塞。这样token省不少，追问时基本能接上。你要是场景不复杂，可以试试手动维护一个轻量历史列表，比向量库省事多了。

我目前是把 embedding 单独抽成一个轻量服务，MCP Server 只管切片和调接口，Qdrant 那边只存向量和 payload。这样换模型或者调维度不用动数据库，Qdrant 自带的插件我试过，灵活度还是差些。查询延迟主要看 embedding 那一步，本地小模型基本几十毫秒，真嫌慢就加个 query 缓存，重复问题直接命中。

我最近也碰到类似的情况，prompt里堆太多规则反而让模型顾此失彼，尤其是那种“信息不足要说明”的指令，模型有时候宁可说不知道也不去仔细看检索内容。后来我改成把约束放在系统提示里，用户那轮就简单说“根据资料回答”，效果好不少。感觉关键不是约束多少，而是别让指令和检索内容抢注意力，另外bge-m3本身对中文政策类文本召回还行，问题可能更多出在排序或者截断上。

按句子切确实容易把条件句和主句拆散，你这个“保修期一年”丢了“非人为损坏”的例子太典型了。我后来试过一种折中做法，是按语义段落切，但控制每块在200到400字之间，同时保留上一段最后一句和下一段第一句作为重叠上下文，效果比纯按段落或纯按句子都稳一些。FAQ这种短问答其实可以单独处理，把问题和答案绑成一个chunk，别硬拆。产品手册里那种带层级标题的，我会把标题路径拼到每个chunk开头，检索时命中

loss降这么低但准确率不动，八成是过拟合了，试试减到1个epoch或者调低lr？

我们这边也是Qdrant加MCP这套，最后选了一个大collection加payload过滤的路子。动态建collection听着干净，但MCP那边tool一多，schema和连接管理真的会炸，而且Qdrant本身过滤性能没那么拉胯，加个tenant_id字段建好索引就够用。唯一要注意的是别让单collection无限膨胀，定期按时间归档一下，不然HNSW内存扛不住。你们现在量级大概多少，几千还是

500条确实太少了，模型很难从这么点数据里学到稳定的回复模式，loss卡住很正常。你可以先试试把数据扩到两三千条，或者用数据增强把现有对话改写几遍。另外学习率2e-4对LoRA来说偏高了，换到1e-4甚至5e-5再跑跑看，rank也可以提到16或32。还有个小坑，检查下数据格式是不是严格按chat template拼的，格式不对loss也会降不下去。

10个并发延迟就十几秒，感觉瓶颈可能不在算力而在调度。A10跑7B用vLLM，可以先把gpu_memory_utilization调到0.9左右，再把max_num_seqs压到8试试，长文本场景下KV cache占显存很凶。FP8量化对7B收益一般，画质和稳定性还可能掉点，不如先看是不是prefill排队堵住了，开chunked prefill会舒服很多。真要加卡，两张A10张量并行比换一张大卡

工业场景那段太真实了，我们厂里试过几个号称能理解物理的模型，抓个零件连重心偏移都算不明白，更别提多步骤装配了。Transformer那套注意力机制对因果关系的建模确实先天不足，堆再多数据也补不上这个洞。不过我觉得数据闭环这个方向倒是有戏，毕竟物理世界的反馈信号比纯文本丰富多了，就看谁能先把仿真和真机之间的gap填上。

我跟你遇到的情况一模一样，之前做法律政策问答时也是疯狂往prompt里塞“禁止发挥”，结果模型直接变成复读机，连原文能推断出来的答案都不敢给了。后来我琢磨着，问题不在“写多细”，而在“约束的锚点”放哪儿——与其禁止模型做什么，不如明确告诉它“回答必须包含检索片段中的至少一个关键句”，这样它自由发挥的空间就被结构限制住了。另外你那个年假和调休的问题，其实很可能是检索回来的chunk里压根没同时提到两