一只刺猬收集工具
Lv.1白天解决问题，晚上整理笔记的小动物。关注技术学习与项目实践，主要分享学习路径整理、读书与思考和日常踩坑；关注技术选择背后的成本与边界。欢迎一起交流，也欢迎不同观点。
发表的评论
这个超时我踩过，大概率是MCP Python SDK里SSE的写回被Ollama的同步请求堵住了。你日志里模型出结果但回调回不去，基本能确认是异步循环卡住，建议把Ollama调用丢到线程池或者换成httpx异步客户端。另外MCP服务器那边的timeout参数默认可能就是60秒，SSE keep-alive也得手动开，不然中间层容易掐连接。CORS一般不影响服务端回调，先别折腾那个，重点查async
我之前也踩过这个坑，调chunk size确实是个两难，大了召回不准，小了上下文断裂。后来我试了个思路，感觉比单纯调窗口有用：在入库的时候就把文档按语义段落切，而不是按固定token数切，比如用句向量做相邻句子的相似度突变点来分段，这样每段本身就是个完整语义单元。检索完再做一步小rerank，不光看query和chunk的相关性，还看chunk和chunk之间的连贯性，比如把Top10先捞出来，然
重排基本是刚需，但你这case更像分块粒度问题，法律条款按语义切比固定300字靠谱多了。
试试用真实数据建个评测集，每次改完prompt跑一遍对比，比感觉靠谱多了。 我是拿Python脚本批量测的，顺便记录输出格式错误率，调起来效率高不少。
你这显存大头八成是KV cache和CUDA context，官方数据都是纯模型权重，把gpu_memory_utilization调低点试试。
24G跑7B LoRA这个占用其实挺正常的，我3090跑类似配置也差不多要20G往上，关键是你max_seq_len和batch_size乘起来的总token数决定了峰值。你试试把gradient_accumulation_steps提到16，batch_size保持1，然后开gradient_checkpointing，能省不少。另外target_modules别全选，像q_proj和v_pro
语义切分比固定长度靠谱，我项目里用400字chunk+80重叠，按Markdown标题切分效果好很多。