企业级自动化炼金室
Lv.1专注于自动化工程的工程化与业务落地。持续实践性能优化、代码可维护性，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
发表的评论
试试调大batch size或开gradient accumulation，A6000单卡7B这速度其实挺正常的。
MCP 本身确实只定义了消息格式和交互语义，传输层是可以换的，SDK 默认的 stdio/HTTP 只是参考实现，不是强制绑定。我们之前也是 PyTorch 训练流程里要动态调推理，试过 JSON-RPC 裸封装，短平快但错误处理和流式响应得自己补；后来换 gRPC 做传输，主要是看中双向流和多路复用，跟 MCP 的 message 层其实不冲突，就是得自己写个 adapter 把 MCP 的 r
固定长度切确实容易出这问题，产品手册里目录页和正文的文本特征太像了，500字符硬切很容易把表格和标题混在一起。我建议先别急着换embedding，bge-large-zh在中文上其实挺能打的，问题大概率出在切分和元数据上。你可以试试按标题层级切，LangChain有MarkdownHeaderTextSplitter，PDF的话可以先转成markdown或者用unstructured提取结构再切。
有没有更详细的教程推荐？
有没有更详细的教程推荐？
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
有没有更详细的教程推荐？
有没有更详细的教程推荐？
几十万这个量级其实挺尴尬的，Milvus单机版跑起来资源占用不算夸张，但etcd和MinIO那套依赖确实劝退个人项目。我之前几万条用Chroma完全够用，后来涨到二十多万查延迟才开始明显，换了Milvus standalone才稳住。建议你要是懒得折腾运维，可以看看Qdrant，单二进制部署，性能比Chroma强不少，API也挺清爽。
爬虫反爬策略更新太快，Copilot的训练数据早过时了，这种活还是得自己盯着调。
你这问题太真实了，我去年做客服Agent的时候也卡在记忆这块好久。纯塞历史肯定不行，后来我们是short-term用滑动窗口加关键实体提取，long-term才走向量库，但向量召回确实得加一层rerank，不然“我喜欢吃辣”这种偏好根本匹配不到川菜。摘要压缩我也踩过坑，价格人名丢了就是事故，后来改成结构化抽取，把硬信息单独存成KV，摘要只负责语气和意图。图结构听起来很美，但维护成本高，除非你的实体
3060 12G跑7B的Q4确实差不多到头了，上下文一长显存一爆就开始幻觉，这个我踩过同样的坑。embedding和LLM分开部署肯定有用，光embedding那点显存占用就能给你多挤出1G多来跑更长的context，值得折腾。但说实话14B量化后在3060上也不会比7B强多少，本质还是显存瓶颈。建议先用7B把Agent流程和工具调用调通，模型这块等50系出来再升级，流程跑顺了换模型就是改个配置的
7B模型确实容易把示例当模板套，试试只给一个示例或者换成带思维链的写法。
4G内存跑8B量化还是太勉强了，CPU推理建议换Qwen2.5-3B试试，7B大概每秒两三个token。
历史对话别全塞进query，改成只带最近一两轮加个摘要，检索用独立query更稳。
我加Few-shot也遇到过死循环，后来把示例里的Thought精简掉一半就好了，感觉是格式太啰嗦把模型带偏了。
8-10 token/s确实不太正常，4090跑Q4_K_M的8B模型一般能到60以上。先确认下Ollama有没有真正调用GPU，跑的时候看下nvidia-smi的显存占用和GPU利用率，如果显存没怎么吃说明还在CPU上跑。另外Ollama默认context长度可能设得比较大，试试调小num_ctx，这个对速度影响挺明显的。vLLM对量化支持确实挑格式，可以换AWQ或者GPTQ版本试试，比GGUF
试试KV cache量化加PagedAttention，vLLM里开enable_prefix_caching能省不少显存。