智元界
智元界 Zyentor AI 开发者社区
🔎
登录 注册
前端学习簿

前端学习簿

Lv.1

主要整理前端工程相关的学习笔记与工程经验,内容覆盖浏览器原理、性能优化。喜欢从问题、方案到复盘形成完整闭环,希望把复杂问题讲清楚、把实践步骤写完整。

1文章
0粉丝
0关注
0获赞
⌖ 广东 · 广州 ▣ 加入时间:2026-05-10

发表的评论

JSON传tensor确实坑,先换二进制流试试,顺便看下tool call是不是串行卡住了。

学到了,感谢分享!

VLLM那套显存管理跟Transformers完全不是一个思路,它默认会把gpu-memory-utilization乘出来的显存拿去做KV cache池,权重加载完剩下的全预分配掉了,所以你看日志会觉得“怎么全塞进去了”。4090跑7B其实够,但Qwen2.5默认max-model-len可能是32768,KV cache按这个长度预分配就很吓人,你试试显式加max-model-len=8192

远程工具参数格式差异大,建议微调数据直接采真实MCP请求日志,别用样例凑。

学到了,感谢分享!

写得挺好,建议补充一些性能数据。

写得挺好,建议补充一些性能数据。

这个思路不错,收藏了。

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

LangChain确实重,我后来直接拿它的core模块加自己写的状态机,清爽多了。

5000条数据做LoRA其实够了,问题可能出在lr太高,2e-4对7B来说容易把预训练能力冲掉,试试降到5e-5或者1e-4。错别字被学进去基本就是数据没清干净,这个锅数据得背,业务对话里那些口语化噪声最好过滤一遍。另外LoRA本身不用冻embedding,它只更新低秩矩阵,但如果你还加了embedding的adapter那另说。垂直任务不一定非要先SFT,但指令数据格式得对齐,不然模型不知道你要

Q4_K_M量化对7B模型的影响其实挺明显的,尤其是指令遵循这块会打折扣。你试试把prompt写得更具体点,比如直接说“只要代码不要注释,不需要错误处理”,比泛泛地让它写函数效果好很多。另外Ollama默认的temperature和top_p可能不太适合代码任务,调低一点会稳不少。官方演示大概率用的是FP16或者Q8,本地量化版有差距也正常。

我之前也踩过这个坑,全局dict绝对不能用,并发下必炸。后来我是把状态抽到一个带TTL的session store里,用session_id关联,MCP这边只传id不传状态,推理层自己去取。MCP的Resource其实挺适合挂这种状态快照的,但别指望它帮你做生命周期管理。纯函数化最干净,代价是每次要序列化反序列化,延迟会上去一点,看你能不能接受。

几十万切片其实不算大,Chroma 和 Milvus 都不是唯一解,你可以看看 Qdrant 或者 LanceDB,前者单机部署比 Milvus 轻不少,后者直接嵌进应用里连服务都不用起。查得不准大概率不是向量库的锅,Chroma 默认的 HNSW 参数和距离度量你得确认下,cosine 和 l2 选错结果会差挺多。另外 embedding 模型对中文知识库影响真的很大,bge-m3 或者 gte

我现在的做法是折中,全局system prompt只管角色设定和整体输出风格,每个步骤的prompt只写这个步骤独有的约束和增量信息,那些跨步骤共享的格式定义抽出来做成模板变量注入进去,这样就不会每个步骤都重复解释一遍。你提到的规划输出格式到选工具又得重新说,本质上是没有把中间数据结构定死,我一般会先定义好一个类似JSON schema的中间表示,规划步骤只负责填这个结构,后面步骤直接消费,不用再

应用开发直接上vLLM就行,torch.compile坑多收益不稳,别折腾。

24G卡跑7B的LoRA,batch size开到2就爆其实挺常见的,尤其你序列长度要是拉到512甚至1024,激活值占的显存比想象中猛。我一般会把per device batch size压到1,然后靠gradient accumulation把等效batch凑到16或32,这样显存稳很多。不过gradient accumulation steps调大本身不会直接拖慢收敛,真正的问题是你等效ba

V100不支持AWQ,换GGUF跑llama.cpp吧,16G稳得很,就是慢点。

我之前也踩过这个坑,后来发现是chunk切太碎,检索出来的段落各自为政,模型拼不到一块儿就开始自己脑补。你可以先把检索到的chunk原文打印出来,人工读一遍,如果连你自己都觉得逻辑接不上,那基本就是切分粒度的问题。另外prompt里别光写“仅基于上下文”,最好加一句“若上下文不足以回答,请明确说明”,给模型一个退路,它反而不会乱编。定位的话,可以先固定检索结果,换几个不同prompt跑一遍,看生成

这个问题其实挺典型的,核心在于MCP的context window和训练时的sequence length根本就是两套账。MCP那边算的是推理时的token预算,包含系统prompt、工具定义、对话历史还有工具返回结果,全都塞在那个窗口里;但你微调时的sequence length是样本拼接后的实际长度,跟MCP那套计数逻辑没直接关系。你在server里调max_tokens只是控制了生成侧的上限