daniel2493468168

@spike0100 对，分类这块确实还有空间。现在我们是「每条工单单独调一次」，其实完全可以攒够 N 条或每 30 秒 batch 一次再推理——下面 @panghu960 提到的 slot 并行也验证了这个方向，吞吐还能再往上抬一截。准备把 batch 化也补进来，谢谢提醒。

@panghu960 这条回复质量太高了，四条都是真金白银的实战经验，逐条回应：

1. 吞吐 vs 延迟：完全同意。我们场景 2000 次/天其实 80%是夜间报表摘要，完全可以 batch 跑——当时只看了单流 54tok/s 就下了结论，确实是决策模型不对。
2. promptcache：这条我不知道，受教了。固定 systemprompt+slot 复用，马上去试，如果数据好会更新到博客版（注明来自你的回复）。
3. GBNF 约束解码：真实踩坑。字段抽取 JSON 少括号导致重试，一度让我们怀疑模型能力——原来加 grammar 就能锁 schema ，这个直接解决我们的线上痛点。
4. 分层路由：对，全量替换确实是懒人方案。小模型吃量、大模型兜底，成本和质量的平衡点还是得算细账。

准备把这四条都补进博客版教程（会注明来自本帖讨论），这种「评论区比正文专业」的时刻就是发帖的意义。多谢！

@gangsta 是这样的，Agent 客户端（ DeepSeek Harness / OpenCode ）系统提示词+工具定义动辄几千 token ，每次请求全量 prefill ，小模型的 prefill 速度撑不住这个开销——不是模型不行，是这类客户端压根没为 3B 级别设计。裸调用快得多是因为 prompt 短、且可以精简到任务本身。

另外你这个「 qwen3.5-9b 在 16G 机器上的对比数据」对我来讲挺有价值的，正好和我 32G 跑 3B 的数据形成互补（内存带宽是共同瓶颈）。方便的话给一下 prefill t/s 具体数字？

@skallz 免费额度个人玩玩没问题。不过我们是要在公司生产环境里跑的：多账号轮换基本都要注册主体的手机号，另外客户数据过第三方 API 这关，做 ToB 业务的都知道怎么回事。所以最后还是选了数据不出本机的方案——省的不只是 API 费，还有合规解释的成本。当然如果只是个人项目，你这个思路完全成立。

@prosgtsr 也可以的，只是还有些场景比如创建同名分支啥的，idea 不好搞，这个方便些

@xy2401 嗯嗯，也可以的，只不过每个项目都要复制一次

@irrigate2554 是的，对我来讲包一下，一个命令更方便