深夜代码笔记

我们也在生产上跑Qwen2.5-7B，一开始也是单卡A10被OOM教育了。后来试过AWQ 4bit，确实能塞进去，但你说的速度变慢我也遇到过，尤其是batch size小的时候反而不如FP16快。后来发现是kernel没选对，换用vLLM自带的awq_marlin后端之后吞吐才正常，输出质量的话我们做了一轮评测，日常问答几乎无感，但代码生成和数学推理确实会掉一点，看你们场景能不能接受。如果内部工具

显存慢慢涨基本就是有变量没释放，比如loss累积或者metric里存了tensor。用torch.cuda.memory_summary()看下历史峰值，能定位到哪一步涨的。

LoRA微调本来计算量就小，编译开销根本摊不平，慢很正常。大模型全参训练才可能看到收益。

我踩过这个坑，纯哈希去重太死板了，稍微改个字就失效。后来改成入库前先跟最近几条算相似度，超过阈值就只更新时间戳和权重，不新增记录。Chroma本身没有内置这功能，得在写入前自己拦一道。另外摘要去重适合长对话，短查询反而容易丢细节，慎用。

我之前用Qwen2.5-32B也踩过这个坑，循环调用确实挺常见的，但后来发现不完全是模型能力的问题。ReAct框架本身对模型的指令遵循要求就比较高，Qwen系在工具调用上的训练数据可能没覆盖那么多“看结果决定下一步”的场景，所以它容易陷入“我还没得到满意答案就再试一次”的模式。我最后的解法是在工具返回里加一个很明确的字段，比如status: success 或者 need_more_info，然后

我之前也遇到过，Chroma里堆了一堆“订单号是多少”的重复记忆，检索时确实乱。后来我是在入库前先算个相似度，超过阈值就只更新时间戳、不新增记录，效果还行。但阈值别设太高，不然稍微换个问法就漏了，建议在0.85到0.9之间试试。哈希去重太死板了，换一个字就失效，LLM摘要成本又高，不太划算。

几万条笔记Chroma完全够用，别被“生产环境”吓到，MCP本地场景延迟真没差。

我最近也在折腾类似的东西，chunk调大确实能缓解但治标不治本。后来试了parent document retriever，子块切小点专门用来匹配，父块放完整段落给模型看，效果明显好不少。重排我觉得挺值得加的，检索回来的顺序对连贯性影响很大。二次摘要没试过，感觉多一步容易丢细节，你可以先跑个小样本对比看看。

指数退避确实比无脑重试靠谱，但得区分下超时原因。如果是工具端限流或网络抖动，重试有意义；要是工具本身挂了，退避到天荒地老也没用。我一般会在client层包一层tenacity，配max_retries加jitter，再给每个工具单独设个熔断阈值，连续失败几次就直接降级返回默认值。另外MCP本身好像没内置中间件机制，你可能得自己在调用封装那层做。

我3060 12G之前也跑过类似方案，建议别急着等50系。先把embedding单独拆出去用CPU或小显存跑，能省出1-2G给上下文，胡言乱语多半是KV cache爆了不是模型不行。14B量化在12G上勉强能跑但速度会很难受，不如把7B的上下文管理和工具调用逻辑调稳，等换卡再上大模型。

这个思路不错，收藏了。

我也被这个坑过，Cursor有时候确实太"热心"了，尤其涉及业务规则的时候。你可以在项目根目录放一个.cursorrules文件，把哪些逻辑不能碰、异常值定义是什么写清楚，它就会收敛很多。另外我习惯在关键代码块上面加注释标注"请勿修改此段"，实测有效。实在不放心就多用diff review，别直接accept all。

50并发用8张A10其实挺宽裕的，别急着上4bit量化，先调gpu_memory_utilization到0.9，再开enable_chunked_prefill，batch size不用硬拉，靠continuous batching撑并发更划算。量化乱码大概率是GPTQ的group size和校准集不匹配，换AWQ或者FP8试试，7B这尺寸FP8显存也扛得住。估算的话粗略按权重+KV cache

我试过按文档类型拆两个Agent，路由用个轻量分类器就行，比硬塞一个省心多了。

7B模型FP16大概14G，你24G卡加载后OOM大概率是TorchServe默认没限制并发数，请求一多KV cache直接爆了。上vLLM吧，PagedAttention对显存碎片管理好很多，同样24G能扛的并发比TorchServe高不少，TGI也行但部署稍麻烦点。4bit量化掉速和乱码基本是量化方案的问题，换AWQ或GPTQ试试，比bitsandbytes稳。实在不够再考虑A100，但先换框

我之前也有类似的感觉，特别是写那种重复性高的CRUD接口时，Copilot一补全我就直接回车，连变量名都懒得想。后来有次面试被问到手写一个带超时控制的worker pool，我居然卡在channel的close时机上了，当时就意识到问题不是Copilot让我变菜，而是我主动放弃了思考的过程。其实工具本身没问题，关键是使用方式，我现在会刻意在Copilot给出建议后先自己想一遍逻辑再决定要不要接受，

一万条数据对法律领域来说其实不算多，loss卡在1.8很可能是数据多样性不够或者重复模式太多，模型很快就学完了表面规律。建议先抽几十条验证集样本看看loss和实际输出对不对得上，有时候loss降不动但生成质量还在涨。另外LoRA的target module选对了吗？只挂q_proj和v_proj效果有限，可以试试加上k_proj、o_proj甚至MLP层。学习率2e-4对LoRA来说不算高，问题更

我也踩过这坑，ReAct对顺序敏感的流程确实不太稳。后来改成用LangGraph把每个步骤做成节点，工具调用变成显式的边，顺序就锁死了，比单纯靠prompt靠谱多了。你这种查库存再报价的场景，其实更适合先规划再执行的两段式，让模型先输出完整计划再逐步跑。不过状态机也不是万能的，遇到需要动态分支的时候还是得留点灵活空间。

我最近也在做类似的事，最深的感觉是别把prompt当成一个静态文本去调，而是把它当成一个需要测试的“程序模块”。你遇到的JSON格式偶尔崩、字段漏掉，很多时候不是模型不懂，而是约束不够硬。我现在会把schema直接塞进prompt里，再在代码侧做一次强制校验和重试，温度0也挡不住那种随机性，但这一层兜底能把不稳定压下去不少。 另外我觉得CoT不是万能药，尤其分类任务里它反而可能让模型自由发挥。我

本地部署和API版在prompt上确实有差别，API那边通常做了后处理和系统级约束，你拿一样的模板套本地模型，效果肯定飘。回答偏长和爱加免责声明，多半是训练数据里的安全对齐在起作用，光靠“请直接回答”这种硬指令压不住。建议试试在system里给个明确的角色和字数范围，比如“你是客服助手，回答控制在三句话内”，比单纯喊口号管用。温度先降到0.3左右，重复输出往往是温度太高加上top_p没设好导致的。