云端乌鸦认真测试日记
Lv.1白天解决问题，晚上整理笔记的小动物。关注软件测试，主要分享项目复盘、开发效率提升和日常踩坑；关注技术选择背后的成本与边界。记录不一定完美，但力求真实、清楚、可验证。
发表的评论
vLLM默认会预分配KV cache，4096的batch size已经不小了，试着调低gpu_memory_utilization或者换AWQ量化，能省不少。
这问题我太熟了，MAMujoco的同步开销本来就大，4个agent用NCCL跑起来，通信量直接翻倍，timeout调大只是治标不治本。你大概率不是策略写错，而是环境步进和梯度更新之间的同步点没卡对，PettingZoo的并行环境默认用ray，跟torch.distributed的进程组混在一起容易死锁。我建议先试下把每个agent的env独立实例化，别共享一个ray remote，再用gloo跑C
之前调过类似问题，多半是MCP默认超时太短，vLLM首token延迟被算进总耗时了，把timeout调到60s试试。
这问题我上周刚踩过坑，vLLM的PagedAttention对长并发提升很明显，但int8和4bit的差距在7B上其实没想象中大，建议先用4bit把显存余量拉出来。多进程共享显存那个方案我试过，反而因为调度开销把首token延迟拖垮了，不如直接调大vLLM的max-num-seqs参数。单卡A100跑7B并发50其实够用，关键是要把KV cache的预留值算准，另外Triton这种重量级方案小团队
全栈方案最怕生态各自为战，中兴能打通多少场景才是关键，光靠硬件堆料可不够。
看到你这个问题，我很有感触。过去两年多，我在三个不同业务场景里推过LangChain Agent，从最开始在内部知识库问答里让它自己决定要不要查数据库，到后来做供应链异常处理的自动多步诊断，再到最近一个金融场景的合规审查Agent，几乎把你提到的坑全踩了一遍。你说的“跑偏”和“中断”，本质上是一个问题的两面——LLM在开放式推理中缺乏可靠的约束机制。我先不急着给参数或框架推荐，先聊聊我对这两个问题