mx2dream

受限于项目复杂度，一般情况不会太卡。SOLO 模式我用起来反而不如常规的 Builder 模式

试试运气

@Sh1xin 这么看，你说的这些场景有点复杂了，不是单纯的技术问题了。从输入源就有问题，还涉及多部门，估计这个你一时很难解决，如果公司内部某些部门没有动力推进解决这些，问题会一直存在。对外部的小客户给一点优惠利益，你们再搞个统一的业务填报的入口，让他们往你们提供的入口迁移啊。不过这些事想想就很麻烦，就看你们自己的决策了。
还有个想法，反正识别表单类的场景一般涉及的上下文和缓存也不大，就不用专门留太多冗余了，如果你多跑几个 VLM ，比对之后达到一定标准就往下个流程走呢，或者买点专门提供这块方案的供应商谈谈。

@Sh1xin 试图用自动化解决绝大部分问题我认为也是一种幻觉，有些识别问题技术解决不了的就通过管理来解决。比如上传资料时按类别、清晰度、重要性和保密性等等打标签进行分级，如果资料级别达到比较高的程度，就在流程上专门引入人工校对或给相应权限的人复核就行了（否则全部自动化了还要人干什么），如果资料没那么重要，就不用太苛求太高的识别正确率了。

①知识库②智能客服问答③OCR 这些需求使用 30B 左右的参数有点浪费了。优先考虑总参数 100B 激活参数 10B 左右的稀疏模型高精度版，或 32B 尽量往上的稠密模型。这四张 A100 ，2 张主力跑 LLM 模型和框架，1 张用于 OCR 和向量检索嵌入，推荐先用传统 OCR 处理（比如 PaddleOCR 之类的），不推荐直接用 VLM 模型进行识别，总之尽量不要在第一步就引入 LLM 的幻觉），再搭配内外部知识库的 RAG 进行修正和降低幻觉，另外 1 张留给 KV 缓存和上下文，FlashAttention 建议打开，这东西在长上下文里对显存吞吐都有不少提升。另外，235B 有点太大了，没有多少冗余了。

你要是还有精力，还可以根据你们公司内部的专门需求折腾下 Agent 。
开始搭建好环境和框架之后，先搞几个 10B 左右的小模型测试一下，然后再换主力模型，这样稳一点。

我也吃过一年多二甲双胍和复合维生素和 B12 ，保持体重是达成的，但没瘦多少。二甲双胍性价比比较高，对于血糖正常的就当保健品吃的。我是单纯因为运动少日常碳水不少胖起来的，另一种没吃过不评价

没有生育计划，非那雄胺，预防 50 岁以后的前列腺增生问题和起夜尿尿问题，缓解脱发，主动降低欲望

当前惯用的使用策略是慢速的免费模型用来进行比较零碎的和浅层次的概念方案讨论，快速的付费模型用于代码和报告的实现，节省费用，免费的还是香的

这次并不是请求太快了，我的请求次数一直都是限制在它的合理限制内的，10 月之前还正常，最近用着用着就突然持续性报错了。
尝试单次请求仍然不行，刚看到那些免费模型的 uptime 从 9 月末 10 月初开始的请求次数断崖式降到非常低的位置，可能是 provider 修改了政策或 OpenRouter 要激活充值的休眠余额了。
刚才切换了一个付费模型，然后又试了一次免费模型，这下单次请求也正常了，不报错了