企业级NLP应用札记

7B微调开compile确实容易踩坑，我这边试下来感觉dynamic shape是最大元凶，batch里seq len一变就疯狂重编译，显存也跟着涨。后来把dynamic设成False、padding到固定长度才勉强跑通，但加速根本没到30%，有时候还不如不开。自定义算子那块更麻烦，rope和flash attention经常直接graph break，得手动加mark_compile_regio

80条工具样本确实太少了，模型根本没学会字段对齐，建议先补到500条以上再谈调参。

说实话这个坑我前阵子刚踩过一遍，LangChain确实抽象层套得太深，新手光搞清楚Chain、Agent、Tool之间的调用关系就得花好几天，而且版本迭代快，网上教程经常对不上号。AutoGPT那种自主循环的思路看着爽，但真跑起来任务一复杂就开始鬼打墙，token哗哗烧还找不到问题出在哪。我现在用的是Qwen2.5配Smolagents，代码量少很多，工具调用逻辑写得直白，跑多步任务相对稳。如果只

我们之前也是本地vLLM塞MCP里，单机自用挺爽，但一上多人并发就开始抢显存，更新模型还得把整个MCP重启一遍，后来干脆拆成API转发层了。其实多绕那一层没想象中那么脆，反而版本切换、限流、监控都好做，MCP那边只维护路由逻辑。本地跑更适合固定版本、低并发、对延迟特别敏感的场景，生产环境我倾向API。多版本的话可以让MCP按请求头或配置选后端，别把权重和路由耦合在一起。

测试集85%但实际一用就崩，大概率不是单纯过拟合，而是测试集和真实分布的gap太大了。你测试集里的问法是不是跟训练集套路差不多？真实用户可不会按模板说话。建议先抽几十条线上badcase看看，是不是稍微换个句式模型就抓不住意图了。另外7B模型做客服本身容量就有限，数据里要是复读样本多，它学会偷懒也正常。

这个坑我也踩过，大概率是微调时没把tool call的格式喂进去，模型没见过MCP那种嵌套的tool result结构，自然容易懵。建议微调数据里就按MCP的实际格式构造多轮工具调用样本，让模型提前适应。另外上下文被截断可能不是max_tokens的问题，得看看FastMCP那边历史管理是不是每次只塞了最近几轮，或者tool result把窗口挤爆了。可以先把完整请求打日志出来，对比下微调样本和实

这个思路我试过类似的，确实能缓解一点，但别指望它治本。MCP本质就是个工具调度层，你让LLM先查库或搜一圈再拼query，等于多了一层意图过滤，垃圾chunk会少些，尤其对那种“关键词对不上”的场景挺管用。但问题是延迟和成本直接起飞，而且LLM自己判断该调啥工具也不一定准，调错了反而把好chunk滤掉。真要搞建议先拿小流量AB测，别一上来就全量接进主链路。

我最近也踩过几乎一样的坑，用Llama 3.2配Chroma做本地知识库，检索出来的片段看着挺准，但模型就是不好好答。后来发现一个很关键的点：这东西对上下文格式特别敏感，你直接把top5片段拼起来塞进prompt，它反而容易懵，得给每段加上来源和分隔符，最好再明确告诉它“只根据下面内容回答”。另外all-MiniLM-L6-v2确实有点弱，尤其中文场景，换bge-m3或者gte-large这类模型

说到这个30%的速度提升，我其实有点怀疑测试条件。之前我们内部也对比过几个推理框架，发现端到端延迟的差距在高并发下会被完全抹平，甚至反转。LongCat那个剪枝策略在batch size拉大之后，单位token成本反而上去了，因为显存碎片化太严重。不过它在单路低延迟场景确实能打，比如语音助手那种一次只来一个请求的。但问题是现在稍微正经点的业务哪还有纯低并发的，基本都要扛住突发流量。所以我觉得与其纠

KV cache 确实是元凶，INT4 权重省的那点显存全被它吃回去了。你可以试试 llama.cpp 或 vLLM，它们对 KV cache 有分页管理和更激进的回收策略，比手动拼 prompt 强不少。滑动窗口加摘要混着用比较稳，近期几轮保留原文，更早的压成摘要，关键实体单独存一份外挂记忆。3090 24G 跑 8B 长期对话本身没问题，瓶颈在框架和上下文管理，不是模型量级。

ONNX在CPU上慢太正常了，ORT对CPU的优化本来就有限，尤其Resize和Pad这类动态shape的op，实现效率跟PyTorch的cudnn kernel没法比。你真正该看的是转成TensorRT engine后的速度，ONNX只是中间格式，别拿它跟原模型比CPU推理。另外DeepLabV3+里那些插值和padding，在TRT里也容易掉到slow path，建议导出时固定输入尺寸，关掉d

我之前也踩过这个坑，最后发现是chunk切得太死，把关键上下文拦腰截断了。你可以先做个简单验证：拿几个bad case，把原始文档里对应的完整段落直接喂给模型看能不能答对，如果完整段落能答对但检索出来的chunk不行，那大概率是切分问题。反过来如果完整段落也答不好，再回头查embedding和查询改写这块。bge-m3本身不差，但查询和文档如果长度差异太大，相似度打分容易失真，可以试试给query

这个问题我觉得未必是embedding的锅，ada-002虽然不算中文最强，但也没差到那个地步。你描述的现象更像是检索策略的问题——“第三版接口变更了哪些内容”这种query里其实包含了一个很强的结构化筛选条件，也就是“第三版”，而向量检索是拿语义相似度去匹配的，它分不清版本号这种精确约束，反而会把语义上最接近的“接口变更”相关片段全捞上来，不管它是第几版。我建议你先把元数据过滤加进去，给每个ch

试试在模板里直接给个JSON样例，Claude照着填就不太爱加废话了。

我也踩过这坑，模板太死反而让模型在多轮里丢了重点，试试精简few-shot再混点自然语言。

5000条数据做客服其实不算少了，loss震荡不降大概率是数据质量的问题，问答对里有没有很多重复或者矛盾的样本？另外你只改attention层rank16可能容量不太够，客服场景术语和话术差异挺大的，试试把mlp层也加上，rank拉到32看看。还有loss不降不代表模型没学到，生成不稳定可能是过拟合到训练集的固定句式了，建议留个验证集盯着eval loss，比盯train loss靠谱。

7B模型做分类确实容易这样，我试过把指令挪到system里会稳不少，user只放待分类文本。另外temperature 0.1对分类来说可能还是偏高，可以试试贪心解码或者设成0。还有个坑是max_tokens别给太大，不然它容易自由发挥。few-shot示例最好固定格式，连标点都别变。

16G跑7B的Q4按理说够用，问题多半出在KV cache上。ctx 4096加上system prompt和几轮对话，KV cache能吃好几个G，显存直接见底。可以试试把ctx降到2048，或者开flash attention，llama.cpp加-fa参数能省不少显存。另外vLLM对40系卡的支持确实容易踩坑，建议先用llama.cpp的server模式跑通再说，别急着换框架。

Agent逻辑跟推理框架关系不大，把LLM用API调就完事了，纠结这个纯属浪费时间。

3000张图微调ResNet18按理说不该这么难，loss卡1.8有点像学习率没调对，你用的多少？另外预训练模型如果没冻结底层，小数据集很容易过拟合或者震荡，可以试试先只训fc层再解冻。还有检查下数据增强是不是太狠了，或者标签有没有对错，我之前就踩过label mapping错位的坑，acc死活上不去。