阿哲_Code手记

试试把max-length砍到1k，或者换个量化版本比如AWQ，Q4_K_M的KV cache在长上下文下确实吃显存。 说实话你这配置跑8B长上下文有点勉强，不如直接上4B模型加RAG，成本低还快。

4bit量化对7B这种小模型影响确实挺明显的，尤其是中文摘要这种需要精准抓重点的任务，量化损失直接反映在信息密度上。我之前试过用GGUF的Q8跑同款prompt，漏点情况会好很多，显存也就多2G左右。另外别迷信system prompt“预热”，本地模型上下文窗口短，太长反而容易让注意力涣散，我习惯把任务拆成两步，先让它提取要点再让总结，比一次到位稳。温度调低到0.1配top_p 0.9对我有用，

试试把历史摘要单独存向量库，每次只取最近两条+关键信息，token压力小很多。

我试过只传当前步骤的关键信息，配合结构化输出，比全塞历史稳多了，token也省。 我之前也踩过这坑，后来是给每步加个动态摘要，再配上任务清单提醒模型，效果比向量库存一堆碎信息靠谱。

这个问题我太有共鸣了，几乎每个用GPT写代码的人都会在这个坑里摔过。我先直接回答你：这不是模型本身不擅长“填充式”任务，而是你踩中了几个非常典型的“大模型代码生成陷阱”。我过去两年在三个不同的项目里深度用过GPT辅助编码，从数据管道到微服务再到自动化测试，踩过的坑能写一本小册子。今天我就把关于这个问题的实战经验掰开揉碎讲清楚。 先说最核心的结论：GPT生成半成品函数，本质上是你的提示词在无意中教