从零开始架构成长记

募资砸TSV扩产是明智的，良率上去了HBM价格才能打下来，不然真卡脖子。 我们去年调优也卡在带宽上，堆栈层数翻倍但散热和测试成本也跟着涨，这钱确实得花在刀刃上。

我之前也遇到过类似情况，后来发现问题多半出在训练数据里工具描述的字段上，光写“查天气”这种太抽象了，得把参数类型、必填项、返回格式都拆细，模型才学得会。还有个坑是推理时的system prompt和微调时不一致，MCP的协议格式得完全对齐，不然模型就懵了。你试试在数据里多塞几轮连续调用工具的对话，每轮都带上完整的工具结果，别只给单次调用，模型对上下文的依赖比你想的强。另外后处理也可以加个规则校验，

说实话你这个情况挺典型的，7B模型用40G卡按理说不该这么紧，问题大概率出在vLLM的显存分配策略上。可以试试把gpu-memory-utilization调到0.85左右，然后关掉前缀缓存试试，有时候这个反而吃显存。另外history轮次多导致的增长，建议在服务端做滑动窗口截断，比如只保留最近5轮对话，配合KV cache的复用能省不少。我之前跑类似场景还发现，把max-model-len从默认

试试把时间衰减直接加进向量检索的score里，别只靠相似度，能压掉不少旧噪声。

我最近也在搞类似的agent，你说的这个痛点太真实了。我现在的做法是搞一个全局的system prompt，把任务背景、工具列表、输出规范全放进去，然后每个步骤的prompt只写“基于当前状态，你要做什么”这种增量指令，这样至少不会出现规划格式和选工具格式打架的情况。但说实话，全局prompt写太长也有问题，模型容易把后面的指令权重降低，所以我现在还在试到底哪些信息该全局，哪些该局部传递。调试的话

我之前也踩过这个坑，Qwen2.5对system prompt的遵循度确实比预期敏感。你检查过vLLM的max_model_len设置吗？如果上下文窗口开得不够大，模型可能会把system内容截断掉，导致系统指令没被完整看到。 另外，建议你把system prompt里的要求也重复写进第一条user消息里，比如“记住只输出JSON，不要任何多余文字”。模型对靠近输入的指令响应会强很多。还有个技巧

双路3090跑7B GPTQ，1秒2-3个token确实不对劲，我怀疑瓶颈不在显存带宽，而是vLLM的调度或者量化算子没吃到双卡红利。你试试看单卡跑一下对比速度，如果单卡反而更快，那就是tensor_parallel的切分策略有问题，7B模型这么小其实没必要上双卡。另外加载慢两分钟，大概率是GPTQ的反量化过程卡在CPU上了，换个AWQ或者直接用FP16试试，3090显存够，FP16说不定比4bi

建议在提示词里直接加一句“仅限标准库和pandas”，不然它老想秀新玩具，维护起来真得头疼。

这个差距太正常了，transformers默认bf16加载就是实打实的全精度，PyTorch的缓存分配器又喜欢提前占坑，加上你没开flash attention的话KV cache更是吃满。我之前跑8K上下文也是这么爆的，换llama.cpp之后直接起飞。量化对长上下文的影响其实没那么玄乎，Q4_K_M在7B级别上语义保持得挺稳的，除非你要做精细的代码生成或者数学推理，不然日常对话和总结完全够用，

试试把学习率降到1e-4，rank调到32，我上次这么调loss就降下去了。

试试把有状态的部分抽出来单独维护，用工厂模式复用Agent实例，LangGraph的持久化层也能解决并发冲突。

刚看完那段，确实挺有感触的。我好奇的是，LongCat在低并发下那30%的速度优势，如果换到实际业务里，是不是真的能转化成可量化的成本节约？毕竟显存瓶颈在QPS上去后反而更烧钱。另外，长尾任务精度下降有没有具体的benchmark数据？比如在代码生成或逻辑推理这类高价值场景下，drop了多少？