340M / 1B / multi-Decide 三个版本怎么选英文场景、多语言需求、微调预算一次讲清【免费下载链接】GLiNER2.5-Decide项目地址: https://ai.gitcode.com/hf_mirrors/fastino/GLiNER2.5-DecideGLiNER2.5 家族一口气发布了三个 Decide 决策分类模型340M 英文版、1B 版和 287M 的 multi-Decide 多语言版。面对同一套架构的三个变体很多人的第一直觉是参数越大越好——但官方基准给出了一个反直觉的结论在英文任务上340M 版反而是整个家族的精度冠军甚至超过了 1B 版和一个 4B 参数的大模型。如果选错了版本轻则白白损失几个点的准确率重则直接让模型在真实语料上失去语言覆盖。本文结合fast-decisions17 领域基准数据与本仓库源码把三个版本的定位差异、适用场景和微调预算一次讲清。三版同台先看同一张基准表三个 Decide 版本之间不存在越大越强的递进关系官方基准数据可以直接说明这一点。在fastino/fast-decisions中模型平均准确率GLiNER2.5-Decide (340M)60.2%GLiNER2.5-Decide-1B59.6%JevK557.6%GLiNER2.5-multi-Decide (287M)56.7%SemIf (Qwen3.5-4B)56.4%GLiFormer large-v149.0%Laya Router46.6%三个关键事实都写在这张表里。其一340M 英文版以 60.2% 拿下家族第一比 1B 版高 0.6 个点比 Qwen3.5-4B 驱动的 SemIf 高 3.8 个点——在结构化决策分类这个专门任务上更大的通用模型并不能靠规模取胜。其二multi-Decide 虽然只有 287M 参数却是家族中唯一一个为多语言输入训练的版本它牺牲了约 3.5 个点的英文精度换来了跨语言覆盖。其三1B 版的定位既不是英文冠军也不是多语言方案它的价值在微调场景——这一点稍后展开。340M 英文版英文场景的精度与成本双优解本仓库存放的正是 340M 英文版README 开篇即写明The 340M English classification model in the GLiNER2.5 family。它的架构细节可以直接从仓库配置中读出编码器基于 DeBERTa-v3-largeconfig.json 中model_name字段标注为microsoft/deberta-v3-largeencoder_config/config.json 显示 24 层 Transformer、hidden size 1024、16 个注意力头、intermediate size 4096最大位置编码 512——这意味着单次输入被限制在 512 token 以内长文档需要分块处理。模型头则是 GLiNER2 的 span 提取架构span_mode为markerV0、max_width为 8。340M 版最核心的设计是标签即输入。它不依赖任何 prompt 模板也不做 token 生成而是把标签集合作为输入的一部分注入模型。这一点在 tokenizer 配置中看得最清楚tokenizer_config.json 注册了一组专用的结构标记[SEP_STRUCT]、[SEP_TEXT]、[P]、[C]、[E]、[R]、[L]、[EXAMPLE]、[OUTPUT]、[DESCRIPTION]——模型正是通过这些结构标记把候选标签与待分类文本组织成一次前向传播将分类任务建模为对标签的 span 匹配与打分。这也是它能在调用时任意更换标签集、无需重训练的根本原因。更实际的一点是一次前向可以同时打多个决策头。README 中的邮件分诊示例把三个决策放进同一次调用输出直接给出三个答案model.classify_text( From: compliancegroup.example\nSubject: Protocol update — action required today\n\nPlease confirm the new retention rule is applied before Fridays audit., { intent: [fyi, request, approval, complaint, newsletter, security_alert], urgency: [low, normal, high, critical], route: [support, billing, legal, security, finance, archive], }, ){intent: request, urgency: high, route: legal}对意图识别、工单路由、审核分级这类低延迟、高吞吐的运营决策场景这意味着路由系统不需要跑三次模型也不需要拼接提示词。340M 的体量让它可以跑在 CPU 上配合 Apache 2.0 许可直接本地部署——这是它作为英文场景默认选择的底气精度最高、成本最低、部署最轻。multi-Decide多语言需求的唯一官方解README 在基准表后有一句非常明确的指引The suite is English. Use GLiNER2.5-multi-Decide when the input is multilingual.整个评测套件是英文的当输入是多语言时请使用 multi-Decide。这就是官方对版本边界最直接的划界340M 和 1B 是英文模型只有 287M 的 multi-Decide 是面向多语言训练的方案。需要提醒的是multi-Decide 的 56.7% 是它在英文基准上的成绩——它牺牲英文精度换来了多语言能力。因此选型逻辑应该是先确认输入语言再谈精度。如果业务语料是纯英文选 multi-Decide 等于无端损失 3.5 个点如果语料混有中文、西语、阿语等语言340M 英文版根本没有对应的语言覆盖这时 multi-Decide 是官方唯一能开箱即用的选择。它和 340M 版共享同一套 schema 驱动接口调用方式和训练数据格式完全一致迁移成本只在于换一个模型名。1B 版微调才是它的主场1B 版在英文基准上只有 59.6%低于 340M 的 60.2%。这个数字初看令人困惑但它揭示了 1B 版的真实定位它不是更强的 340M而是更适合微调的 340M。更大的参数量意味着更强的拟合能力与更多的可训练容量代价是更高的推理延迟、更大的显存/内存占用以及更高的微调算力门槛。社区对该版本的主流共识也正是适用于有微调需求且算力充足的场景——开箱即用不是它的强项私有分类体系下的精度上限才是。微调流程本身在 README 中有完整定义。训练数据是一行一个样本的 JSONL每个classifications对象对应一个决策头字段与推理时的classify_text参数一一对应{input: My subscription renewed after the service was already down. Can I get that charge refunded?, output: {classifications: [{task: intent, labels: [order_status, refund_request, cancel_subscription, other], true_label: [refund_request]}]}} {input: Battery dies before lunch, but the keyboard and the screen are great., output: {classifications: [{task: aspects, labels: [battery, keyboard, screen, camera, price], true_label: [battery, keyboard, screen], multi_label: true}]}}训练代码同样开箱即用核心只有三步# pip install gliner2[train] from gliner2 import AutoExtractor from gliner2.training.trainer import ExtractorTrainer, TrainingConfig model AutoExtractor.from_pretrained(fastino/GLiNER2.5-Decide) config TrainingConfig(output_dirout, num_epochs3, batch_size8) ExtractorTrainer(model, config).train(train_datatrain.jsonl) tuned AutoExtractor.from_pretrained(out/final)微调预算的账要算清楚如果只是做英文意图分类、情感分析这类常见任务340M 版开箱即用的 60.2% 已经足够完全没有微调的必要只有当业务需要私有标签体系、定制标签描述、序数评分这类 README 中反复强调的进阶能力且手头算力充足时1B 版才值得投入。仓库中的 SKILL.md 还给出了另一条降低预算的路径——将任务描述交给 Fastino Agent 托管服务由平台侧自动完成数据构建与微调适合没有自建训练管道的团队。此外README 特别提醒序数评分如把0到10当作普通标签在训练时按普通类别处理loss 并不知道6比0更接近7因此序数头的评估除了准确率还应看平均绝对误差MAE。三个场景的选型决策树把上面的分析压缩成一张决策树实际操作时按顺序回答三个问题即可Q1. 输入语料包含英文以外的语言吗 ├─ 是 → 选 GLiNER2.5-multi-Decide287M多语言唯一官方方案 └─ 否纯英文→ 进入 Q2 Q2. 需要开箱即用还是计划微调私有分类体系 ├─ 开箱即用 → 选 GLiNER2.5-Decide340M英文精度最高、CPU 可跑 └─ 计划微调 → 进入 Q3 Q3. 微调算力/预算是否充足 ├─ 是 → 选 GLiNER2.5-Decide-1B拟合容量更大、微调上限更高 └─ 否 → 仍选 340M 版微调训练成本更低且 59.6%→60.2% 的 差距说明小模型在多数任务上并未拉开明显劣势三条核心判断值得记住英文场景默认 340M多语言场景只有 multi-Decide1B 版的价值必须靠微调兑现。选错版本的真实代价最后用数据说话把选错的代价量化出来英文场景误选 multi-Decide直接损失 3.5 个点的精确匹配准确率60.2% vs 56.7%还要为多语言能力付出额外的推理开销——多语言编码器在英文输入上没有任何收益。多语言场景误选 340M/1B英文单语模型对中文、西语等输入没有语言覆盖zero-shot 分类直接失效业务上线即翻车这是比精度损失严重得多的代价。盲目上 1B 版开箱即用的英文精度反而比 340M 低 0.6 个点同时推理延迟、内存占用、微调显存需求全部上升——花更大的成本买到更差的开箱效果除非微调后能追回并超过 340M 的上限否则这笔账是亏的。GLiNER2.5 三个 Decide 版本的选型本质上不是选参数最大的而是在语言覆盖与算力预算的双重约束下选精度最优的那个。340M 英文版用 17 领域 60.2% 的成绩证明了小而专的价值专门为运营决策优化的编码器架构、标签即输入的 schema 驱动接口、一次前向的多头并行打分——这些设计让它在英文场景下同时拿下了精度与成本两端的优势。理解这一点选型就不再是拍脑袋而是一道有基准数据支撑的确定性问题。【免费下载链接】GLiNER2.5-Decide项目地址: https://ai.gitcode.com/hf_mirrors/fastino/GLiNER2.5-Decide创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考