阿Rust玩家手记
Lv.1一名专注于Rust系统开发的软件工程师。日常记录故障排查、高并发与性能优化和项目中的问题解决过程；希望内容既讲清为什么，也说明怎么做，也会分享从需求分析到交付上线的完整过程。
发表的评论
这个思路不错，收藏了。
学到了，感谢分享！
刚入门，这个对我帮助很大。
5 tokens/s确实不太对劲，3090跑7B FP16怎么也不该这么慢。先确认下是不是输入prompt特别长，长上下文prefill阶段会拖慢整体吞吐；另外vLLM版本也关键，老版本在30系卡上有些kernel没走flash attention，升级到最新版试试。还有个容易忽略的点，检查下是不是开了什么CPU offload或者swap，显存够的话完全没必要。我之前在A100上碰到过类似情况，
13B单卡跑确实挺吃显存的，我之前试过用GPTQ 4bit量化，大概能压到8G左右，但有些层精度掉得厉害，生成质量会飘。后来换了AWQ感觉好一点，不过对算子确实有要求，vLLM和llama.cpp支持还行。剪枝我也看过，但实操门槛高，不如先试试量化加KV cache优化，或者直接用llama.cpp跑GGUF格式，省心不少。
我也遇到过，后来改成先让它只输出 diff 或者 patch，明确说“不要给我完整文件，只给替换片段”，情况好很多。另外把组件拆小确实有用，上下文里无关代码越少它越不容易乱动。还有个笨办法，改之前先把当前文件 git commit 一下，它要是改飞了直接 reset 重来，比跟它反复拉扯省时间。
变量替换基本在客户端就搞定了，MCP传输那点开销可以忽略，真正影响首token的是长上下文本身。
同一个问题多问几次输出就不稳，这个其实挺典型的，不一定是few-shot数量的问题。GPT-4o本身有随机性，temperature不调低的话，同样的输入确实可能给你不一样的输出，尤其你还要它严格按字段来，稍微一飘就漏了。两个few-shot说实话有点少，而且关键不是数量，是这两个例子有没有覆盖到你实际会遇到的那些边界情况，比如问题模糊、多意图、需要拒答的时候。我自己做类似项目时，会把系统提示里的
这个现象我也撞过，而且不止一次。我的理解是，当system prompt里塞了太多“不要编造”“找不到就说不知道”这类防御性指令时，模型的注意力会被大量分配到“合规检查”上，反而稀释了对检索内容的语义对齐。尤其GPT-4o这种对齐做得比较重的模型，指令越强硬，它越倾向于保守退让，哪怕证据已经在眼前了。你简化prompt后准确率回升，大概率不是检索变好了，而是模型终于敢用检索到的东西了。不过也不能全
4060 8G跑7B确实挺极限的，FP16爆显存太正常了，光权重就14G左右，加上KV cache不炸才怪。4bit量化掉质量这个事我觉得得看具体量化方案，GPTQ有时候确实会伤到一些关键层，尤其多轮对话里上下文一长就容易胡言乱语。GGUF的Q5_K_M或者Q6_K我个人体感是比GPTQ 4bit稳不少，llama.cpp那边对CPU+GPU混合推理支持也成熟，你可以把一部分层offload到CP
这问题太真实了，我也被“优化”两个字坑过，AI一看到就自动开启重写模式。后来我干脆在prompt里明确写“只输出diff，不要给完整文件”，再配合“禁止改动函数签名和CSS类名”，效果会好很多。另外别只说“不动其他”，它理解不了那么抽象，最好直接列出允许改动的行号或者变量名。我现在还会先让它复述一遍边界，确认没跑偏再让它动手。
两张4090跑8B别硬堆batch，试试per_device=1累积8步，rank降到16先。长文本才是真凶，500token建议截断或分桶。
2e-4对LoRA来说确实偏高了，尤其你还跑了3个epoch，Llama3这种基座很容易被带跑偏。我一般用1e-4甚至5e-5，epoch控制在1-2，loss降太快反而要警惕。2万条纯客服对话分布太窄，建议掺10%-20%的通用指令数据，能明显缓解胡编和中英混杂。评测别只看loss，跑一下mmlu或者自己的通用问答集，对比微调前后回答质量最直观。
stdio模式在服务器上跑基本行不通，它设计上就是给本地进程通信用途的，你放到远端没有stdin/stdout管道自然各种崩。服务器部署得换成SSE或者streamable HTTP这类transport，配置方式跟本地完全不一样。我之前也踩过这个坑，建议先去翻翻官方那个example仓库里的remote server示例，照着改一下transport那行就能跑起来。
Agent场景延迟比尺寸重要，7B 4bit配SGLang试试，比vLLM对量化友好。长上下文确实影响规划，但显存扛不住就别硬撑。
验证时不更新BN也会占显存，试试`torch.inference_mode()`，比no_grad更省。
角色设定是给生成用的，别塞进检索query里，分开就对了。
2万条数据微调BERT绰绰有余，先查查标签有没有标错，法律文书类别混淆很常见。
我也被这个问题折磨过一阵，后来发现Cursor的diff模式其实比聊天模式听话得多。你选中代码后按Cmd+K调出inline edit，它默认就只在你圈定的范围内生成修改，基本不会越界去动别的函数。但如果你用的是侧边栏chat，哪怕选了代码，模型还是会把整个文件当上下文，很容易顺手“优化”别的地方。我的习惯是重构小片段一律用Cmd+K，大范围调整才开chat，而且chat里会明确说“只输出这个函数
我最近也这感觉，感觉是上下文塞太多它反而抓不住重点，试试关掉无关文件只留当前模块。