Step1 报告：模型选型¶

中文邮政客服任务开源大模型选型研究报告¶

1. 报告目的¶

这份报告只做一件事：把可选的开源模型放到同一套标准下比较，然后把采用路线定下来。
数据是中文邮政客服多轮对话，后面要做 SFT、结构化 JSON 生成，以及必要时和 RAG 结合，所以选型不能只看榜单分数，还要看中文表现、格式稳定性和实际落地成本。

本报告不再回顾更早一代模型，也不做泛泛的模型罗列。
这里只保留 2025-2026 仍值得认真比较、并且确实可能进入方案的主流路线。

本项目的实际约束如下：

数据是 k 级别，不是十万级、百万级
任务是中文客服，不是英语通用问答
数据主体是多轮对话
目标不仅是生成回复，还包括总结与结构化 JSON 输出
需要兼顾可训练性、可部署性、可展示性
当前阶段更看重稳定完成闭环，而不是追求纸面最强 benchmark

所以这里真正关心的，不是谁的理论上限更高，而是谁更适合这批数据、这套资源和这条交付节奏。

2. 任务需求反推模型标准¶

2.1 中文能力是首要条件¶

本项目处理的是中文客服对话。
这类任务和普通开放聊天不一样，它对模型提出的要求更偏“业务风格稳定”：

能理解中文口语、省略、重复表达
能处理客服场景常见话题，如订单、退款、配送、发票、投诉、邮政流程
能维持中文礼貌风格和解释风格
能在多轮对话里保持上下文一致

很多国际主流模型在英语任务上很强，但放到中文客服场景里，稳定性不一定够。
这个任务里，中文能力不是加分项，而是前提条件。

2.2 JSON 生成能力是核心考察项¶

这个项目后续不只是让模型“回答得像人”，还要让模型能：

输出结构化摘要
生成工单字段
生成固定 schema 的 JSON
降低后处理复杂度

按这个任务要求，一个真正适合当前数据的模型，需要具备：

较强的 instruction following
对固定字段格式有较好的服从度
少说废话，少在 JSON 外额外加解释
微调后字段完整率和解析成功率更高

所以这里会把 JSON 能力单独拎出来看。
如果一个模型天然就更容易按格式输出，后面的训练、校验和落盘都会省很多事。

2.3 k 级别数据不适合激进路线¶

当前数据量只是 k 级别。
对应的判断是：

不适合依赖超大规模监督数据才能发挥优势的路线
不适合把大量训练预算押在超大模型上
不采用明显偏 reasoning / think 的模型作为优先路线
不适合为了模型结构本身的复杂性额外付出太多工程成本

按当前条件，优先级很明确：

先用足够强、但仍然好训好跑的模型做出稳定基线
再考虑更大的对照模型拉高上限

3. 选型原则¶

结合任务目标，选型标准定为：

优先保留 2025-2026 仍有现实竞争力的主流开源模型
中文能力优先于英文 benchmark 漂亮程度
JSON 结构化输出能力优先于“会不会想很多步”
优先选择适合 LoRA / PEFT 微调的模型
优先选择能在本地或有限资源下稳定推理、稳定训练的模型
对 MoE、超大上下文、原生多模态等复杂特性保持谨慎
明确区分“适合作为主力 SFT 模型”和“适合作为上限对照模型”

4. 当前主流开源候选池（仅保留 2025-2026 相关路线）¶

这一节只看现在还有比较价值的主流模型，不再展开更早一代路线。

4.1 Qwen 路线¶

Qwen2.5¶

虽然 Qwen2.5 首发时间早于 2025，但在 2025-2026 这一阶段，它仍然是中文开源生态中可用性和成熟度都较高的一条路线，因此不因发布时间稍早而排除。
特别是 Qwen2.5-3B、Qwen2.5-7B，在中文、指令跟随、结构化输出、社区成熟度之间取得了非常平衡的状态。

官方模型卡对 Qwen2.5-7B-Instruct 的描述里，明确强调了：

指令跟随能力
长文本理解和生成
结构化输出，尤其是 JSON
多语言能力，明确覆盖中文

来源：
https://huggingface.co/Qwen/Qwen2.5-7B-Instruct

放到当前任务里，这条线的意义很直接：

中文客服任务贴合度高
结构化 JSON 输出是官方就强调的能力点
社区实践多，SFT / LoRA 资料成熟
3B / 7B 两个尺寸都很适合做分层实验

结论：

Qwen2.5-3B：推荐作为第一版主力 SFT 起点
Qwen2.5-7B：推荐作为更强的正式候选或最终展示候选

Qwen3¶

Qwen3 是 2025 年的重要新路线。官方模型卡强调它支持：

thinking / non-thinking 两种模式
更强的推理与 agent 能力
更广泛的多语言支持

来源：
https://huggingface.co/Qwen/Qwen3-8B

这条线本身很强，也足够新。
但放到当前任务里，问题也很直接：

当前任务不是推理竞赛，而是中文客服和结构化输出
当前数据没有专门的 think 监督
若使用带明显思维模式的模型，需要额外控制模板、输出风格和训练目标
这会提高实验复杂度

因此，Qwen3 保留在候选池内，但不进入当前主线。

结论：

保留为补充对照模型
不进入第一阶段主线

Qwen3.5 / Qwen3.6¶

这两个版本代表的是 2026 更靠后的新一轮 Qwen 演进。
这里按当前公开版本的路线定位做判断，不展开到逐个 checkpoint 的实验层面。
从公开资料看，这两个版本更明显地往 agent、复杂任务编排和更高阶能力上推进，同时也继续保留中文生态优势。

但是否进入主线，不取决于“是不是最新”，而取决于是不是适合当前任务：

若重点是客服 SFT + JSON，则并不需要过多 agent 特性
越新的模型，生态和微调经验往往越不如 Qwen2.5 成熟
新版本能力更强，不代表在小数据客服场景一定更稳

因此，Qwen3.5 / Qwen3.6 纳入前沿模型跟踪范围，但不进入当前阶段主线方案。

结论：

纳入前沿模型跟踪范围
保留为后续升级路线
当前阶段不替代 Qwen2.5 主线

4.2 GPT-OSS 路线¶

gpt-oss:20b 需要纳入本次比较范围，因为它代表了一条“本地仍可运行、同时能力上限更高”的路线。

OpenAI 官方介绍里明确给出：

它是 open-weight reasoning model
gpt-oss-20b 总参数量为 21B
每个 token 激活参数约 3.6B
采用 MoE 架构
支持 128k 上下文

来源：
https://openai.com/index/introducing-gpt-oss/
https://huggingface.co/openai/gpt-oss-20b

这条线的现实价值主要在两点：

它作为比 3B / 7B 更强的本地上限参考
它作为“若不采用纯中文系模型，而改用更强通用模型”的对照

但它不进入当前阶段 SFT 主力路线，原因也很明确：

它的定位更偏 reasoning 和 agent
架构是 MoE，训练和调参思路更复杂
官方信息里更强调工具使用和复杂任务，而不是中文客服与 JSON 结构化抽取
中文能力并不是它最突出的强项

结论：

保留为强基线 / 上限对照模型
不作为当前项目 SFT 主模型

4.3 Llama 4 路线¶

Llama 4 是 2025 之后最有存在感的国际开源路线之一。
官方公开资料显示，Llama 4 Scout 和 Llama 4 Maverick 已经转向：

MoE
原生多模态
超长上下文

来源：
https://huggingface.co/meta-llama/Llama-4-Scout-17B-16E-Instruct
https://huggingface.co/meta-llama/Llama-4-Maverick-17B-128E-Instruct

这类模型确实代表前沿，但和本项目的匹配度并不高：

本项目核心不是多模态
也不需要百万级上下文
MoE 增加训练和部署复杂度
中文能力不是它的核心卖点
对 k 级别客服 SFT 来说，这条路线明显偏重

结论：

纳入比较范围
明确排除出当前主线

4.4 DeepSeek 新路线¶

DeepSeek 这一部分只保留新的路线，不再回到更早一代。
因此这里只聚焦 2025-2026 的新阶段路线。

对于当前报告，保留 DeepSeek-V4 这一类新路线就够了。
这里同样只做选型层面的概括。
它代表的是新一代中国开源大模型路线，也通常伴随：

更强推理和代码能力
更大规模
更复杂架构
更高部署和训练成本

按当前项目约束看，这条路线的主要问题在于规模和实施成本偏重：

当前数据规模并不支持充分发挥这类模型的上限
训练和推理成本都明显偏高
该类模型仅保留为技术跟踪对象，不进入当前阶段主力方案

结论：

保留 DeepSeek-V4 作为前沿中国模型代表
不作为当前项目的主力 SFT 路线

4.5 Mistral Small / 同级国际小中模型¶

Mistral Small 3.1 这一类模型需要写进去，是因为它代表了一条现实可选的国际中等规模路线。
参数量还在可讨论范围内，社区影响力也足够大，因此有必要纳入比较。

公开模型卡信息显示，这类模型通常会强调：

较好的通用指令能力
长上下文
多语言
比超大模型更可部署

来源：
https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503

但在本项目场景下，它依然很难抢过 Qwen：

中文不是其天然强项
JSON 结构化输出并不是它最鲜明的卖点
24B 量级也并不轻

结论：

纳入国际通用路线比较范围
不进入当前主线

4.6 Gemma 3、InternLM、GLM、Yi、Baichuan 等中文相关路线¶

这些模型都和中文场景有关，所以需要纳入比较，保证主要中文路线没有漏掉。
综合看下来，它们都保留在比较范围内，但不进入当前主线。

Gemma 3¶

它是 2025 新一轮重要开源模型之一，但整体上更偏 Google 系国际通用路线。
对于中文客服 + JSON 任务，它的主要问题仍然是：

中文不是第一卖点
微调和中文客服落地经验不如 Qwen 丰富

InternLM¶

InternLM 在中文环境下具有一定代表性，尤其在国内研究和工程语境中有持续存在感。
但如果目标是尽快把结果做稳，当前还是优先选择 Qwen 这条路线，原因主要有三点：

社区更成熟
SFT 资料更多
JSON 结构化经验更丰富

GLM / Yi / Baichuan¶

这些模型都会在报告里点到。
至于为什么不进入当前主线，理由基本一致：

社区势能不如当前主流第一梯队
与本项目最相关的公开实践不如 Qwen 充分
在中文客服 + JSON + 小数据 SFT 这个组合任务上，没有足够理由压过 Qwen 主线

结论：

纳入中文路线比较范围
不进入当前主实验主线

5. 为什么中文能力和 JSON 能力会把候选池进一步收缩¶

如果只看名气，候选池会很大。
但把标准换成下面这些之后：

中文客服是否自然
多轮对话是否稳
是否适合小数据微调
JSON 字段是否容易对齐
是否经常在 JSON 外多说解释

候选池会迅速收缩。

真正还能留下来的模型，其实并不多。

5.1 Qwen 系列的优势最完整¶

Qwen 对本项目的主要优势在于整体能力配置较为均衡：

中文能力强
指令跟随强
JSON 输出能力被官方明确强调
尺寸覆盖合理，3B / 7B 都有现实意义
社区微调经验最成熟之一

对当前任务来说，这种“没有明显短板”的特点很重要。

5.2 GPT-OSS-20B 更像能力上限，不像项目主线¶

gpt-oss:20b 当然值得保留，因为它足够强。
但它更像：

更高能力上限
更强本地对照
更适合做辅助 benchmark

而不是“小数据中文客服 SFT 的第一选择”。

5.3 新模型并不自动进入当前主线¶

像 Qwen3.5 / 3.6、Llama 4、DeepSeek-V4 这样的新路线，技术上更前沿，但：

更前沿不等于更适合小数据客服 SFT
更大不等于更容易稳定产出 JSON
更复杂也不意味着更适合当前阶段交付

所以这里的结论可以直接写成：

候选模型覆盖了当前主流新路线
实施主线仍确定为 Qwen2.5

这就是当前阶段的工程取舍。

6. 本机工程指标与合规补充¶

模型选型不能只停留在“哪个模型能力强”，还需要看训练效率、量化后内存占用、本地推理速度、中文语义理解、长对话上下文、JSON 结构化输出准确率和商用合规性。结合本项目实际任务，模型路线不建议写成“只选一个模型解决所有问题”，而应写成分工式流程：

Qwen2.5 系列负责中文邮政客服任务的 SFT 主线。
gpt-oss:20b 作为结构化 JSON 生成、格式修复、字段校验的工具节点或流程节点。

这样设计的核心原因是：中文客服 SFT 与 JSON 结构化输出并不是同一个最优解问题。前者更看重中文语义、客服语气、小数据微调稳定性和训练成本；后者更看重格式服从、schema 对齐、字段完整性和后处理成本。

6.1 本机 Ollama 模型情况¶

本机已安装多个候选模型，和当前任务最相关的是：

模型	本机文件大小	参数/结构	上下文长度	量化方式	许可证与可用范围	当前定位
`qwen2.5:3b`	1.9GB	3.1B dense	32K	Q4_K_M	Qwen Research License：适合研究、实验、课程验证；对外服务、商用部署和再分发需要单独核对许可条款	快速实验、流程验证、低成本 SFT 起点
`qwen2.5:7b`	4.7GB	7.6B dense	32K	Q4_K_M	Apache 2.0：可商用、可修改、可再分发，需保留许可证和版权声明	中文客服 SFT 主力候选
`qwen2.5:14b`	9.0GB	14.8B dense	32K	Q4_K_M	Apache 2.0：可商用、可修改、可再分发，需保留许可证和版权声明	能力上探、较强中文基线
`gpt-oss:20b`	13GB	20.9B MoE，约 3.6B active	128K	MXFP4	Apache 2.0：可用于实验、定制和商业部署，适合本地工具节点	JSON 结构化生成/校验节点，强本地对照

许可证差异的含义是：qwen2.5:3b 虽然体积小、适合快速试错，但它不是本项目对外部署的首选；qwen2.5:7b、qwen2.5:14b 和 gpt-oss:20b 使用 Apache 2.0，工程上更适合进入可交付或商用合规路径。这里的结论用于模型选型，不替代正式法务审核。

从工程角度看，qwen2.5:3b 和 qwen2.5:7b 的模型文件明显更小，更适合作为高频实验对象；qwen2.5:14b 能力更强但训练与推理成本更高；gpt-oss:20b 虽然总参数更大，但 MoE 激活参数较少，并且官方和本机均显示其具备较强的本地部署可行性。

6.2 本机单条推理测试¶

测试 prompt：

请判断下面用户问题属于哪类邮政客服意图，只输出JSON：用户说“寄EMS到上海大概要几天，多少钱？”字段为intent、reason、confidence。

测试结果：

模型	单条推理 wall time	输出格式观察	语义观察
`qwen2.5:3b`	10.6 秒	输出了 JSON，但包在 Markdown 代码块中	能识别为物流/EMS 相关，理由基本正确
`qwen2.5:7b`	11.5 秒	输出了 JSON，但包在 Markdown 代码块中，`confidence` 为字符串	意图更贴近“时效和费用查询”
`qwen2.5:14b`	13.5 秒	输出裸 JSON，格式较稳定	理由完整，但意图标签略泛
`gpt-oss:20b`	5.6 秒	CLI 中展示 thinking，最终答案为裸 JSON	意图标签最细，字段完整度较好

这组测试不是严格 benchmark，只是本机同题快速验证。它能说明两个方向：

Qwen2.5 系列对中文邮政问题理解稳定，适合作为 SFT 主线。
gpt-oss:20b 在同题下最终 JSON 字段更完整，意图标签更细，适合放在结构化输出节点中。

gpt-oss 的速度不能只按总参数量理解。gpt-oss:20b 是 MoE 架构，总参数约 20.9B，但单次推理只激活约 3.6B 参数；gpt-oss:120b 总参数约 117B，但单 token 只激活约 5.1B 参数。因此它们的显存占用和推理耗时更接近“激活参数量”，不是每次都把全部参数当作 dense 模型参与计算。这也是 gpt-oss:20b 在本机单条 JSON 任务中速度较快的主要原因。

需要注意的是，gpt-oss:20b 在 Ollama CLI 中会显示 thinking 过程。正式流程中不应直接把 CLI 全量文本当作业务输出，而应使用 API 调用、响应字段分离、最终 JSON 提取或 schema 校验方式，只保留最终结构化结果。

6.3 多维度选型对比¶

维度	Qwen2.5-3B	Qwen2.5-7B	Qwen2.5-14B	gpt-oss:20b
训练效率	最高，适合快速试错	较高，适合主线 SFT	中等，成本明显上升	不建议作为当前中文客服 SFT 主线
量化后本机文件大小	1.9GB	4.7GB	9.0GB	13GB
本地推理速度	快，但格式稳定性一般	较快，语义更稳	更稳但更重	本次测试最快，适合独立工具节点
中文语义理解	可用	稳定	更强	可用，但官方定位更偏通用推理和 agent
长对话上下文	本机 32K	本机 32K	本机 32K	本机 128K
JSON 结构化输出	需要 prompt/后处理约束	需要 prompt/后处理约束	较稳	最适合做 JSON 生成/修复/校验
商用合规性	只建议研究和流程验证，商用前需复核许可	Apache 2.0，可作为主线 SFT 候选	Apache 2.0，可作为能力上探候选	Apache 2.0，可作为本地结构化工具节点
当前项目定位	快速实验	SFT 主力	能力上探	结构化节点/强对照

7. 最终推荐方案¶

综合中文能力、JSON 生成能力、SFT 难度、部署成本、时间和数据规模，最终方案定为：

7.1 第一优先主线方案¶

Qwen2.5-3B
Qwen2.5-7B

采用理由：

中文能力强
指令跟随与结构化输出能力成熟
更适合当前 k 级别数据做 LoRA / PEFT
更容易从训练、验证到展示形成完整闭环

实施方式：

3B 先做快速实验、流程验证、字段设计验证，仅用于研究和流程验证阶段
7B 做更强版本、正式对比、最终展示

7.2 结构化工具节点与强对照路线¶

gpt-oss:20b

当前定位如下：

作为强本地基线
作为更大模型上限参考
作为结构化 JSON 生成、修复、校验节点
作为长上下文对话摘要和复杂 schema 处理节点

不采用其作为主线的原因：

不是最适合当前项目的第一主线
更偏 reasoning / agent
MoE 路线工程复杂度更高
当前项目数据规模是 k 级别，优先目标是稳定中文客服闭环，而不是训练一个更复杂的通用推理模型

7.3 保留观察但不进入当前主线的路线¶

Qwen3
Qwen3.5
Qwen3.6
Llama 4
DeepSeek-V4
Mistral Small 3.1
Gemma 3
InternLM
GLM / Yi / Baichuan

这些路线保留在报告中，用来交代候选池已经完整覆盖；
但在当前阶段，它们都不进入主实验主线，也不替代 Qwen2.5。

8. 推荐落地流程¶

推荐流程如下：

数据侧先整理为标准 SFT 样本，包含用户问题、客服回复、总结、意图、业务字段。
使用 qwen2.5:3b 做快速 SFT 试跑，验证数据格式和训练脚本。
使用 qwen2.5:7b 做正式中文客服 SFT，得到主力客服回复模型。
在推理流程后增加 gpt-oss:20b 结构化节点，用于：
将对话或模型回复转为固定 JSON；
修复不合法 JSON；
补齐缺失字段；
对字段类型和枚举值做校验；
对长对话做结构化摘要。
对最终 JSON 再做程序校验，包括 json.loads、必填字段、字段类型、枚举值和置信度范围。

可以把最终系统写成：

用户问题/多轮对话
  -> Qwen2.5 SFT 客服模型：负责中文客服理解与回复
  -> gpt-oss:20b JSON 工具节点：负责结构化字段生成、修复和校验
  -> 程序侧 schema 校验与落库

这种分工比单模型方案更稳。Qwen2.5 做它最擅长的中文客服 SFT，gpt-oss:20b 做它最擅长的结构化输出和长上下文处理，程序侧再兜底校验格式。

9. 结论¶

把当前任务概括成下面几个条件：

中文邮政客服多轮对话
k 级别数据
需要稳定 SFT
需要生成结构化 JSON
需要按当前阶段节奏交付

那么当前阶段的模型路线确定为：

以 Qwen2.5-3B 和 Qwen2.5-7B 作为主力 SFT 方案
以 gpt-oss:20b 作为结构化 JSON 工具节点和更强本地对照方案
将 Qwen3 / Qwen3.5 / Qwen3.6 / Llama 4 / DeepSeek-V4 等模型纳入前沿跟踪范围，但不进入当前主线

结合现有数据规模、任务目标和实施条件，当前最重要的是三件事：中文要稳，结构化输出要稳，训练过程要能控。
按这个标准，Qwen2.5 放在主线更合适，gpt-oss:20b 更适合做结构化输出节点和能力对照。
最终保留这组组合，主要考虑的不是模型热度，而是任务适配度、训练稳定性和落地成本。