LongCat-2.5 开源之后，自部署先拿什么试
内容提要
美团以MIT协议开源LongCat-2.5，可商用推理与二次训练，但公开信息不足以估算部署成本。建议先用工单归类等非实时任务试部署：保留原规则与人工兜底，用含长文本、模糊描述和错分代价高的脱敏旧工单验收，重点查错分记录，不把历史标签当标准答案。压测需区分排队与推理耗时，关注最老请求等待时间，并测试推理进程中断后的重试上限。成本按实际完成工单计，含空转、重跑和人工改标。发布记录需绑定模型版本、提示词与输出校验，先旁路运行再放量；回滚时在写库处校验工单状态，丢弃迟到结果。小团队上线门槛是值班人员能关闭模型路径且未处理工单可交回原流程。
延伸解读
为什么工单归类适合作为首个试点
文章建议先拿工单归类这类非实时任务试部署，因为模型只给候选标签，拿不准的仍走人工，原规则也保留。推理慢不影响用户提交，比在必须即时返回的接口里塞推理更容易收拾。验收样本要包含长文本、模糊描述和高错分代价的工单，并单独翻错分记录，区分普通咨询错分与紧急故障错分。
压测要分开看排队与推理耗时
本地压测应关注长短请求混合时短请求是否被卡住，并把排队时间和实际推理时间分开记录，否则值班时难以判断是处理慢还是没轮到。还要看队列中最老请求等了多久，队列只剩几条也可能有一条已挂很久。试跑时可停掉一个推理进程，观察调用方是否超时立即重试、旧活是否重新挤入队列，重试需有上限，超时工单交回原流程。
回滚要覆盖提示词与迟到结果
模型没换，提示词或输出格式改了也可能出错，例如新版多吐一句解释，下游却把整段话当标签存。发布记录应绑定模型版本、提示词和输出校验，写入前用允许标签列表校验，先旁路运行再放量。切回旧流程时，开关关了已发出的推理请求仍会回来，若人工刚改完标签，迟到结果不能覆盖，可在写库处检查工单是否仍待自动归类，状态变了就丢弃。
小团队的上线门槛与成本口径
对小团队，文章给出的上线门槛是值班人员能关掉模型路径，且未处理工单能交回原流程；若关开关还需手工捞队列、补状态，应先修好退路再扩大使用。成本应按实际完成工单计算，把机器空转、失败重跑和人工改标签都算进去，否则单次推理看似便宜，接入后未必省钱。
Q&A
LongCat-2.5 开源后，自部署应该先拿什么类型的任务来试？
建议先拿工单归类这种非实时任务试部署。模型只给候选标签，拿不准的单子仍走人工队列，原有归类逻辑也保留。这样推理慢一点不影响用户提交工单，比在必须实时返回的接口里塞推理更好收拾。
用旧工单验收模型时，样本应该怎么挑？
不要全挑干净的样本。拿一批脱敏旧工单，特意留几条很长的、正文没说清楚的，以及归错组就会延误处理的。验收时除了看平均准确率，要单独翻错分记录，区分普通咨询错分和紧急故障错分。
历史工单的标签能直接当作模型评估的标准答案吗？
不能。有的单子来回转过几次，最早标签只能说明当时派给了谁。模型和历史记录不一致时，最好请懂业务的人抽查，并识别边界不清的类别，这类先留给人工，不要急着用二次训练拟合旧标签。
本地压测时应该重点关注哪些指标？
要区分排队时间和实际推理时间，避免混成一个耗时数字；关注队列中最老请求的等待时间；还可以停掉一个推理进程，观察调用方重试行为，重试要有上限，超时工单交回原流程。
自部署成本应该怎么计算才合理？
成本按实际处理完的工单计算，要把机器空转、失败重跑和人工改标签都算进去。否则单次推理看着便宜，接入后未必省钱。
模型版本或提示词变更后，回滚要注意什么？
发布记录要绑定模型版本、提示词和输出校验，写入前用允许的标签列表校验。先旁路运行只记录不真改，再逐步放量。回滚时在写库处检查工单是否仍处于待自动归类状态，状态变了就丢弃迟到结果，避免覆盖人工修改。
小团队上线自部署模型的最低门槛是什么？
值班人员能随时关闭模型路径，且未处理的工单能交回原流程。如果关开关还需要手工捞队列、补状态，应先修好这条退路再扩大使用范围。
