LongCat-2.5 开源之后，自部署先拿什么试
本文由本站基于公开热点摘要整理和原创分析生成。来源：美团技术团队原文。
基于公开摘要可见，美团开源了 LongCat-2.5，采用 MIT 协议，支持商用推理部署和二次训练。摘要没给出足以估算部署成本的信息，我不会拿它给机器选型。倒是有件事可以先想清楚：如果手头真有一个任务想交给模型，接上以后，原来的服务会多背多少活？
先拿一条不用当场回的请求试
如果要评估自部署，我会挑工单归类这种活。模型只给候选标签，拿不准的单子还走人工队列，原来的归类逻辑也先留着。推理慢一会儿，用户照样能提交工单。拿这个试，比在一个必须当场返回结果的接口里塞一次推理要好收拾。
样本别全挑干净的。拿一批脱敏的旧工单，特意留几条很长的、正文没说清楚的，还有归错组就会延误处理的。验收时，平均准确率可以看，但我会单独翻一遍错分记录。把一个普通咨询错分给另一个组，和把一条紧急故障丢进普通队列，是两码事。如果模型只在原有规则就能解决的单子上表现好，换它的理由也就少了。
也别把历史标签全当标准答案。有的单子来回转过几次，最早那个标签只能说明它当时被派给了谁。碰到模型和历史记录不一致的样本，最好请懂业务的人抽查，顺便看哪些类别的边界本来就说不清。遇上这种类别，我宁愿先留给人工，也不急着靠二次训练去拟合旧标签。
机器扛得住，队列也得扛得住
本地压测我更想知道的是，长短请求混着来，短请求会不会也卡在后面。把排队时间和实际推理时间分开记：都算进一个耗时数字里，值班时就不好判断是处理得慢，还是活根本没轮到。再看队列里最老的一条等了多久。队列里只剩几条也未必没事，其中一条可能已经挂了半天。
还可以在试跑时停掉一个推理进程，看看调用方怎么收场。队列消费者要是超时就立刻重试，进程刚拉起来又会接到一波旧活。重试得有上限，等过了归类时限的工单就交回原流程，别继续挤新工单的队。成本按实际处理完的工单算，机器空转、失败重跑和人工改标签都得算进去。否则看着单次推理便宜，接入之后未必省钱。
回滚别只留在部署脚本里
模型没换，提示词或输出格式改了，业务也可能出错。比如上一版返回系统认识的标签，新版多吐了一句解释，下游却把整段话当成标签存进去了。我会把模型版本、提示词和输出校验一起记在发布记录里，写入前用允许的标签列表做校验。先让新版本旁路跑，只记它本来会怎么分，不真改工单。等错分的代价和积压都看得清楚了，再拨一点流量过去。
切回旧流程时，还有个容易漏的情况：开关关了，已经发出去的推理请求却还会回来。要是人工刚改完标签，迟到的结果不能把它覆盖掉。可以在写入时检查工单是否仍处于待自动归类状态，状态变了就丢弃结果。这个检查放在写库的地方，比只在发请求前看一次开关管用。
对小团队，我的上线门槛很简单：值班的人能关掉模型路径，未处理的工单还能交回原来的流程。要是关个开关还得手工捞队列、补状态，先把这条退路修好，再谈扩大使用范围。
