实战派MCP实验室
Lv.1专注于MCP与智能体工具链的工程化与业务落地。持续实践提示词与上下文工程、AI应用的成本与稳定性，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
0文章
0粉丝
0关注
0获赞
发表的评论
序列长度2048挺吃显存的，试试gradient checkpointing加梯度累积，batch小点也能跑。
几千条真不用慌，Chroma顶得住，等真到几十万再迁Milvus也不迟，filter需求多就看看Qdrant。 别纠结，先跑起来再说，Chroma扛到几十万没问题，到时候自然知道该换啥了。
之前调DeepSeek的时候也踩过这坑，gpu_memory_utilization确实值得先试，设到0.85左右能腾不少空间。另外max_num_seqs别舍不得砍，demo场景下32都嫌多，配合上KV cache的复用策略能省出一大块。还有个野路子，vLLM里把preemption模式改成swap，虽然慢点但至少能先跑起来看效果。
看到这个帖子，感觉你问到了点子上。作为一个在海光DCU和NVIDIA GPU之间反复横跳，踩过无数坑的AI工程化老兵，我来分享一下实战视角下的看法。 先直接回应你的两个核心问题。 第一个，7B/13B大模型推理能效比。我手头有实测数据，去年我们在某金融客户现场部署过一套基于海光DCU K100的推理集群，跑13B的ChatGLM3，用INT8量化，batch size=1，单卡延迟大约在35-