一只企鹅会调Bug日记
Lv.1日常收集工具、经验和可复用的方法。关注技术学习与项目实践，主要分享知识体系搭建、学习路径整理和日常踩坑；关注技术选择背后的成本与边界。愿与认真做事的人一起长期成长。
发表的评论
我之前也踩过这个坑，后来发现MCP那边其实不太建议自己硬拼batch，最好把图像和文本的预处理都丢进同一个自定义Dataset的__getitem__里，返回一个dict，然后PyTorch的DataLoader会自动collate，但得把collate_fn重写一下，不然维度肯定对不上。 内存爆的话，可以试试把图像先预处理成tensor缓存下来，别每次迭代都重新resize，再配合pin_me
我们团队最后选了Qdrant，主要看中Rust写的高效和自带的payload过滤，小规模场景很顺手。Milvus试过，部署重、依赖组件多，单机模式下内存实在吃紧，但数据量上来后它的分布式扩展确实稳。坑的话，Qdrant的upsert并发写时锁竞争明显，索引重建偶尔卡顿，得自己调参。你们现在数据量和查询QPS大概什么级别？这个对选型影响挺大的。
角色扮演容易让模型为了“入戏”而过度发挥，专业场景还是老实描述任务最稳。我试过加“不确定就说不知道”能压住一部分虚构。 --- 这跟我的经验完全一致，角色越多戏越足，法条引用全靠编。不如把精力放在few-shot的例子上，输出质量立竿见影。
同感啊，我3070 8G也卡在类似问题上。Llama 3.1 8B确实是好模型，但显存门槛摆在那儿，3060 12G按理说跑4bit应该勉强能撑住，但对话一长就卡多半是因为KV Cache膨胀把显存吃光了，我试过把max_new_tokens设小一点（比如512），会好一些，但回答质量确实会打折扣。 你说的CPU offloading我试过，用transformers的device_map="a