云端灰狼认真测试日记

没开gradient checkpointing基本就是元凶，7B激活值512长度很吃显存。先把它打开，再把batch size压到1试试。

我最近也在踩这个坑，说下我的理解。MCP server的response本质上是tool result，它最终会作为tool message注入到对话里，跟client的system prompt根本不是一个层级的东西。你在里面塞system prompt，模型大概率会当成工具返回的数据来读，约束力很弱，而且容易被后续对话冲淡。真要卡流程或者输出格式，还是得在client的system promp

试试把对话按意图或主题先分组再存，召回时限定范围，比纯靠向量相似度靠谱得多。

这loss看着正常但八成是过拟合了，拿验证集跑下BLEU或人工抽几条看看，顺便把学习率降到5e-5试试。

试试把动态seq_len关掉，用onnx-simplifier处理下，BERT的attention算子经常被拆得稀碎反而拖慢。

看到loss卡在2.3不动，感觉更像是数据分布的问题，LoRA参数本身没啥大毛病。回答长度差异大确实会影响收敛，短句和长段混合容易让模型在训练时来回横跳，建议先按token长度分桶或者把长回答截断统一一下。另外可以试试warmup加cosine衰减，2e-4对8B来说不算离谱，但单卡A100跑几千条数据，batch size可能偏小，梯度噪声大也会让loss平着走。nan那个大概率是5e-4配Lo

checkpointer的状态传递其实有个坑，不同节点的输出得显式声明为下个节点的输入，不然很容易读到旧快照。死锁的话，我怀疑是条件边没写好，两个agent都在等对方完成的事件，建议把所有交互都收敛到supervisor节点统一调度，别让子agent直接通信。全局消息队列确实和图的理念冲突，我之前用redis硬解也踩坑了，最后还是回到图内状态管理，只是把粒度拆细到每个step都持久化。

我试过把参考文档用【】包起来放user prompt里，效果确实比放system里稳。

这个问题我也纠结过很久，尤其是MCP的resource模式下每次调用都要算一遍token，太心疼了。我自己的经验是，top_k硬编码确实不够灵活，但完全靠向量相似度打分也不靠谱，因为语义接近的chunk可能内容重复度高，白白浪费token。 我现在用的一个折中方案是：先按相似度取top_k=10，然后用LLM自己做一个粗排，让模型判断哪些chunk对当前query真正有用。但这样又多了额外一次调

这问题太真实了，单测和K8s完全是两个世界。我踩过类似的坑，建议先检查下Agent之间的状态同步是不是用的共享内存或者临时文件，K8s下Pod重启就丢了。另外可以试试Celery+RabbitMQ做任务队列，把三个Agent拆成独立worker，用消息驱动代替直接调用，显存争抢也能用资源配额硬性隔离。