上个月我们团队在做一个数据处理平台，核心需求就两块：一是让模型生成 Python/TypeScript 代码片段，二是把非结构化文本转成严格的 JSON schema。老板说预算有限，优先考虑开源模型自部署，让我在 Qwen3 和 DeepSeek V3.2 之间选一个。我说行，那我就拿真实任务跑一轮，用数据说话。

结论先放这：代码生成选 DeepSeek V3.2，JSON 结构化输出选 Qwen3。不是综合排名，是按任务类型分的，下面展开说。

先说结论

任务类型	推荐模型	原因
Python 函数生成（算法/数据处理）	DeepSeek V3.2	逻辑严谨，边界处理更完整
TypeScript 类型体操	DeepSeek V3.2	类型推断准确率高约 12%
JSON schema 严格输出	Qwen3	格式遵循度 97%，几乎不漏字段
嵌套 JSON + enum 约束	Qwen3	DeepSeek 偶尔会自己"发明"字段
代码重构/解释	差不多	两者表现接近，看个人习惯

环境准备

我的测试环境：

• 模型版本：Qwen3（通义千问 2026-04 发布的最新版）、DeepSeek V3.2（稳定版）
• 推理框架：vLLM 0.6.x，A100 80G × 2
• 测试集：42 个代码生成任务 + 38 个 JSON 结构化任务，全部来自我们线上真实 prompt
• 温度统一 0.1，max_tokens 2048

如果你不想自己部署，直接通过 API 调也行。我后面贴的代码用的是聚合平台的 endpoint，改个 model 参数就能切换。

代码生成：DeepSeek V3.2 赢在哪

测试方法

我从项目里抽了 42 个 prompt，分三类：

1. 纯算法题（15 个）：LRU Cache、滑动窗口、树遍历
2. 业务逻辑（17 个）：数据清洗函数、API 请求封装、错误重试
3. 类型定义（10 个）：TypeScript 复杂泛型、discriminated union

每个 prompt 跑 3 次取最好结果，人工判断"能不能直接跑通 + 逻辑是否正确"。

结果

纯算法题两者差距不大，DeepSeek 32/45 pass，Qwen3 29/45 pass（每题 3 次所以分母是 45）。

但到业务逻辑这块差距就出来了。举个例子，我让模型写一个带指数退避的 HTTP 重试函数：

from openai import OpenAI

client = OpenAI(
 api_key="your-key",
 base_url="https://api.ofox.io/v1"
)

response = client.chat.completions.create(
 model="deepseek-v3",
 messages=[{
 "role": "user",
 "content": "写一个 Python 函数，实现 HTTP 请求的指数退避重试，要求：最多重试3次，初始等待1秒，遇到429和503才重试，其他状态码直接抛异常。返回 response json。"
 }],
 temperature=0.1
)

DeepSeek V3.2 生成的代码会主动处理 json.JSONDecodeError，还加了 timeout 参数。Qwen3 的版本能跑，但漏了 timeout，而且把所有 4xx 都当成需要重试的——这在生产环境会出事。

类型定义那块更明显。我让它写一个 discriminated union：

// 期望输出类似这种
type Result<T> = 
 | { status: 'success'; data: T; timestamp: number }
 | { status: 'error'; error: Error; retryable: boolean }
 | { status: 'pending'; progress: number }

DeepSeek 三次都给出了正确的类型窄化，Qwen3 有一次把 retryable 字段加到了所有变体上。

JSON 结构化输出：Qwen3 真的稳

这是让我意外的部分。说实话一开始我觉得代码写得好的模型，结构化输出也应该强，但实测不是这样。

测试方法

38 个任务，统一用这个 prompt 模板：

请将以下文本提取为 JSON，严格遵循 schema，不要添加额外字段，缺失信息填 null。

Schema: {schema}
文本: {text}

只输出 JSON，不要解释。

判断标准：
- JSON 能否 parse（基础分）
- 字段是否严格匹配 schema（不多不少）
- 值类型是否正确（string 不能是 number）
- enum 字段是否在允许范围内

结果数据

指标	Qwen3	DeepSeek V3.2
JSON parse 成功率	100% (38/38)	97.4% (37/38)
字段完全匹配率	97.3%	89.5%
类型正确率	98.1%	94.7%
enum 遵循率	95.6%	88.2%

DeepSeek 那个 parse 失败的 case 是它在 JSON 前面加了一句 "以下是提取结果："，虽然加 json markdown 标记了但我的 parser 没处理这种情况。算小问题，但在批量跑 pipeline 的时候这种"偶尔不听话"挺烦人的。

更关键的是字段匹配率。DeepSeek 有个毛病——它会"好心"地给你加字段。比如 schema 里没有 confidence_score，它觉得有用就自己加上了。Qwen3 在这方面特别老实，说什么就是什么。

一个真实的报错场景

我们 pipeline 里用 Pydantic 做 validation，DeepSeek 输出经常触发这个：

pydantic.error_wrappers.ValidationError: 1 validation error for ExtractedEntity
extra_field
 extra fields not permitted (type=value_error.extra)

后来我加了 model_config = ConfigDict(extra='ignore') 才绕过去，但这本质上是模型不够遵循指令。

调用链路和工程选型

graph TD
 A[业务 Prompt] --> B{任务类型判断}
 B -->|代码生成| C[DeepSeek V3.2]
 B -->|JSON 结构化| D[Qwen3]
 C --> E[代码 Lint + 单测验证]
 D --> F[Pydantic Schema 验证]
 E --> G[输出结果]
 F --> G

我们最终的方案是两个模型都用，按任务类型路由。如果你不想自己部署两套推理服务，可以通过 OpenRouter 或 ofox.io 这类聚合平台直接调 API，ofox.io 是 0% 加价对齐模型官方定价，切模型只需要改 model 参数，不用维护多套 client。

踩坑记录

坑 1：Qwen3 的 system prompt 长度敏感

当 system prompt 超过 800 token 的时候，Qwen3 的 JSON 遵循度会明显下降（从 97% 掉到 91% 左右）。我的解决办法是把 schema 说明放到 user message 里，system prompt 只留一句"你是一个 JSON 提取助手，只输出合法 JSON"。

坑 2：DeepSeek V3.2 的 stop token 问题

用 vLLM 跑 DeepSeek 的时候，偶尔会出现输出末尾多一个换行 + 重复开头几个 token 的情况。查了半天发现是 stop token 配置的问题，需要显式设置：

sampling_params = SamplingParams(
 temperature=0.1,
 max_tokens=2048,
 stop=["<|endoftext|>", "<｜end▁of▁sentence｜>"]
)

折腾了大半天才搞定，DeepSeek 的 special token 命名确实有点非主流。

坑 3：并发高了 Qwen3 会偷懒

这个我也不确定是不是 vLLM 的 batch 调度问题，但当并发超过 16 的时候，Qwen3 的输出质量会有轻微下降，具体表现是 JSON 字段偶尔缺失。降到 8 并发就正常了。可能跟 KV cache 压力有关，目前没找到比降并发更好的办法。

不同场景怎么选

如果你主要做 AI 辅助编码（类似 Cursor/Cline 的场景）：DeepSeek V3.2。代码质量和边界处理确实好一档。

如果你在做数据 pipeline（文本→结构化数据→入库）：Qwen3。省心，不用写一堆 fallback 逻辑去处理格式问题。

如果两种都要：像我们一样做路由，或者直接用 Claude Sonnet 4.6 这种闭源模型一把梭——贵是贵点，但两项都能打 95 分以上，少操心。

小结

跑完这一轮测试花了我三天（其中两天在调 vLLM 配置），结论就一句话：开源模型现在没有"全能选手"，按任务选型才是正解。DeepSeek V3.2 写代码强，Qwen3 做结构化强，各有各的甜区。

如果你的场景跟我类似，建议拿自己的真实 prompt 跑一轮，别光看 benchmark 分数。HumanEval 分高不代表写业务代码就好使，这是我这次最大的体会。