国内大模型横向评测：K3、DeepSeek、GLM与Qwen的选型实战指南

最近在做多模型接入的小项目，我趁机把国内几款主流大模型拉在一起做了轮横向测试，覆盖对话推理、代码补全、Embedding、本地部署等场景。

一圈测下来的直观感受是：K3 在技术迭代上冲得最猛，DeepSeek 在复杂推理上做得最极致，GLM 在中文业务场景尤其是金融语义理解上表现很稳，Qwen 则把开源模型的门槛和成本压到了最低。

当然，这句话带了不少个人体验色彩。为了让大家能复用这套评估思路，我把测试环境、核心原理、API 接入代码、本地部署步骤以及常见坑都整理成一篇完整教程。既有模型能力分析，也有可复制的工程实践，适合刚开始选型大模型的开发者，也适合已经接入过 API、想优化多模型调度方案的同学。

1. 背景与核心概念：为什么要重新测试国内大模型

1.1 一句体验总结背后的四个关键词

先解释一下“最前沿、最极致、最懂股价、最经济”这几句评价在实际测试中的含义。

• 最前沿：指的是 K3 系列在长文本、工具调用、Agent 等新能力上跟进速度很快，很多新特性属于“先上车再打磨”的类型，适合做前沿玩法验证。
• 最极致：指的是 DeepSeek 的推理链非常长，尤其面对数学、逻辑、代码难题时，会反复自我校验，输出质量极高，但相应的响应时间和推理成本也更高。
• 最懂股价：这一条比较符合 GLM 在金融语料理解上的表现，它对财报、公告、行情数据等中文金融文本的语义抽取更准确，因此很多量化投研场景会优先选 GLM。严格说，这和“预测股价”无关，但确实更懂金融文本。
• 最经济：指的是 Qwen 系列从 0.5B 到 72B 覆盖完整，开源版本多，可以在消费级显卡上部署，API 价格也相对低，是个人开发者和中小团队比较稳的选择。

1.2 这次测试主要覆盖哪些场景

评测大模型不能只看一个通识问答，否则很容易被“感觉”带偏。我这次测试覆盖了四类高频场景。

• 通用对话与知识问答：考察模型的基础语言能力和知识覆盖面。
• 复杂推理与数学逻辑：考察模型的思维链、推理稳定性。
• 代码生成与代码补全：考察模型在真实工程中的可用性。
• API 稳定性与成本：考察响应速度、限流情况、Token 消耗和调用价格。

除此之外，我还测试了本地部署流程，重点验证了 Qwen 和 DeepSeek 的轻量版本在普通开发机上的运行效果。

1.3 先说结论：没有“最好”，只有“更适合”

四款模型并不会有绝对的“最强”。真实选型时，需要结合业务场景、成本预算、部署方式、数据安全要求来综合判断。

如果你追求前沿能力，可以关注 K3；如果要做数学物理考研辅导、复杂代码推理，DeepSeek 很合适；如果做金融文本处理和中文业务系统，GLM 值得试；如果做私有化部署或高频低成本的对外服务，Qwen 是首选。

2. 测试环境与版本说明

2.1 使用方式：官方 API + 本地部署 + 编程场景

我这次的测试环境没有统一的标准服务器，而是模拟了大多数开发者手上的条件。

• 操作系统：Windows 11 / Ubuntu 22.04 双环境。
• 编程语言：Python 3.10+。
• 调用方式：官方 API + OpenAI 兼容接口。
• 本地部署工具：Ollama + transformers。
• 向量数据库：Milvus Lite（用于测试 Qwen Embedding）。
• 编辑器：VS Code + Continue / Cline。

如果你的环境版本不同，不影响整体思路，只需要把依赖包版本和模型名称替换成实际可用的版本即可。

2.2 统一测试维度

为了尽量公平，我设置了以下固定参数。

不同模型对“温度”参数的解析略有差异，但整体趋势一致：温度越低，输出越保守稳定；温度越高，越有创造性。

2.3 一个容易混淆的点：K3 与金蝶 K3

在输入“K3”做检索时，很容易搜到“金蝶 K3 凭证导入”“金蝶 K3 运行时错误 429”这类内容。

需要说明：本文讨论的 K3 是指国内大模型 K3 系列，和金蝶 ERP 系统里的 K3 完全是两回事。如果你是搜“金蝶 K3 运行时错误 429 ActiveX 部件不能创建对象”进来的，那属于 ERP 客户端 COM 组件注册问题，和本文无关，请优先检查金蝶客户端依赖组件是否完整注册。

3. 四款模型的核心能力拆解

3.1 K3：前沿能力的“激进派”

K3 给我最深的印象是功能迭代速度很快，尤其在 Agent 调用、长上下文、代码解释器这些方向上，属于“先推出来再优化”的策略。

在实际测试中，我让 K3 完成一个相对复杂的任务：给定一份销售数据，要求它写 Python 代码做清洗、统计并输出可视化结论。K3 能主动拆解步骤，生成带注释的代码，并给出执行建议，整体体验比较接近一个能理解开发意图的助手。

不过也要注意，K3 的一些新功能可能不够稳定，部分 API 参数会随版本调整。使用时要以下一代官方文档为准，不要写死参数名。

3.2 DeepSeek：极致推理的“慢思考选手”

DeepSeek 系列最核心的特点是“慢思考”，也就是在生成最终答案前，模型内部会经历较长的推理过程。

我测试了一个较难的数学题和一段带隐蔽逻辑陷阱的代码 Bug 分析。DeepSeek 的答案中会出现明显的“再思考一步”“这里可能存在边界条件”“我们换个角度验证”式的推导过程。这种风格在处理复杂任务时非常有价值。

但它的缺点也很明显：响应耗时长，Token 消耗大，不太适合高频低延迟的闲聊场景。另外，如果问题本身很简单，DeepSeek 的“过度思考”反而会让答案显得啰嗦。

3.3 GLM：金融与中文场景的“实用派”

GLM 在中文理解和金融文本处理上有优势。我用它做了两个测试：

1. 从一份模拟的上市公司公告中抽取“净利润、同比变化、风险提示”三个字段。
2. 解释一段包含金融术语的中文文本。

GLM 的输出格式稳定，基本不会漏字段，术语解释也比较贴合中文语境。这也对应了“最懂股价”这个口口相传的印象，准确说，是“最懂金融中文语料”。

如果你准备做金融领域问答、研报摘要、信息抽取，GLM 值得作为首选之一。同时也可以关注 GLM 系列是否有 Flash 或轻量版本，用于降低调用成本。

3.4 Qwen：高性价比的“全家桶”

Qwen 系列最大的优势是“覆盖全面、成本友好”。

从 0.5B 的小参数模型到 72B 级别的大模型，Qwen 基本覆盖了个人开发、私有化部署、企业级应用几种场景。阿里还提供了 Qwen Code 系列用于代码补全，Qwen Embedding 系列用于向量化，形成了比较完整的模型矩阵。

测试中，我重点验证了 Qwen 的本地部署能力。一个 7B 级别的量化模型在 16GB 内存的 MacBook 上也能运行，虽然速度不算快，但至少能完成开发调试。对于预算敏感的项目，Qwen 几乎是性价比首选。

4. 完整实战：一条代码接入四款模型

4.1 统一使用 OpenAI 兼容协议

现在大部分国内大模型厂商都提供了 OpenAI 兼容接口，这意味着你只需要修改 base_url、api_key、model 三个参数，就能在同一个代码框架中切换四款模型。

不需要额外安装复杂的 SDK，一个 openai Python 包就能搞定。

安装依赖：

pip install openai

注意：如果你的项目使用了旧版本 openai，建议升级到 1.x：

pip install -U openai

4.2 编写统一的调用代码

新建一个文件llm_client.py，代码如下。

# 文件路径：llm_client.py from openai import OpenAI def chat_once( api_key: str, base_url: str, model: str, user_content: str, temperature: float = 0.3, max_tokens: int = 2048, ): """ 通过 OpenAI 兼容接口调用不同大模型。 """ client = OpenAI( api_key=api_key, base_url=base_url, ) response = client.chat.completions.create( model=model, messages=[ {"role": "user", "content": user_content}, ], temperature=temperature, max_tokens=max_tokens, ) return response.choices[0].message.content

这段代码的核心逻辑很简单：

• 创建 OpenAI client。
• 设置 base_url 指向对应厂商的接口地址。
• 设置 model 为具体模型名称。
• 调用 chat.completions.create 发送消息。

实际调用时，只需按下面的方式传入不同参数。

# 文件路径：demo.py from llm_client import chat_once # 这里仅做示例，实际 key 请替换为自己的 Key API_KEY = "sk-xxxxxxxx" # 调用示例：K3 k3_result = chat_once( api_key=API_KEY, base_url="https://api.k3.example.com/v1", model="k3-xxx", user_content="解释一下什么是 API 网关", ) print("K3 输出：", k3_result) # 调用示例：DeepSeek deepseek_result = chat_once( api_key=API_KEY, base_url="https://api.deepseek.com/v1", model="deepseek-chat", user_content="解释一下什么是 API 网关", ) print("DeepSeek 输出：", deepseek_result) # 调用示例：GLM glm_result = chat_once( api_key=API_KEY, base_url="https://open.bigmodel.cn/api/paas/v4", model="glm-4-flash", user_content="解释一下什么是 API 网关", ) print("GLM 输出：", glm_result) # 调用示例：Qwen qwen_result = chat_once( api_key=API_KEY, base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", model="qwen-plus", user_content="解释一下什么是 API 网关", ) print("Qwen 输出：", qwen_result)

需要说明的是，上方的 base_url 和 model 名称只是示例写法，不同时期的模型名称和接口路径可能变化，请以官方文档为准。

4.3 响应结果解析

OpenAI 兼容接口返回的内容是标准结构：

response.choices[0].message.content # 模型回答正文 response.usage.prompt_tokens # 输入 Token 数 response.usage.completion_tokens # 输出 Token 数 response.usage.total_tokens # 总 Token 数

如果要做成本统计，可以在调用后打印 usage。

def chat_once_with_usage(api_key, base_url, model, user_content): from openai import OpenAI client = OpenAI(api_key=api_key, base_url=base_url) response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": user_content}], ) content = response.choices[0].message.content total_tokens = response.usage.total_tokens print(f"[{model}] 消耗 Token: {total_tokens}") return content

这套封装基本能满足日常测试和原型开发。

4.4 实际效果对比：模拟真实问题

我用一个数据库场景问题做了对比。

问题：

请对订单表 orders 添加一个复合索引，字段为 user_id 和 create_time， 要求写出 SQL 语句，并说明为什么推荐这个顺序。

四款模型都给出了正确 SQL，但风格差异明显。

• K3：给出了额外的分区建议和索引失效注意事项，内容更全。
• DeepSeek：先分析了两种字段顺序的区别，再给出建议 SQL，逻辑推导最细。
• GLM：直接给 SQL，并附带简短的业务建议，简洁实用。
• Qwen：SQL 写法中规中矩，注释清晰，适合快速复制。

从这个结果可以看出：选模型不能脱离场景。如果只是要一个稳妥答案，Qwen 足够；如果想深入理解原理，DeepSeek 更有价值。

5. 多场景实战：代码补全、Embedding 与本地部署

5.1 代码补全场景：Qwen Code 与 IDE 集成

在 VS Code 中，可以使用 Continue 插件接入 Qwen Code 或 DeepSeek 的代码补全接口。以 Qwen 为例，在 Continue 配置文件中添加如下模型配置。

{ "models": [ { "title": "Qwen Code", "provider": "openai", "model": "qwen-code", "apiBase": "https://dashscope.aliyuncs.com/compatible-mode/v1", "apiKey": "sk-xxxxxx" } ] }

配置保存后，在代码编辑器中触发补全，IDE 会自动把上下文发送到模型接口。

这类代码补全模型适合日常写函数、写单元测试、生成样板代码。不过要注意，代码补全服务对延迟比较敏感，如果接口响应时间超过 3 秒，体验会明显下降。

5.2 向量化场景：Qwen Embedding 与 Milvus

做 RAG 或知识库检索时，需要把文档切块并向量化。我用 Qwen Embedding 配合 Milvus 做了一个最小示例。

第一步，安装依赖：

pip install pymilvus openai

第二步，将文本向量化并写入 Milvus：

# 文件路径：embedding_demo.py from openai import OpenAI # 构造客户端 client = OpenAI( api_key="sk-xxxxxx", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", ) def get_embedding(text: str): resp = client.embeddings.create( model="text-embedding-v3", input=text, ) return resp.data[0].embedding if __name__ == "__main__": text = "大模型检索增强生成实践" vec = get_embedding(text) print("向量维度：", len(vec))

第三步，把向量写入 Milvus：

# 文件路径：milvus_demo.py from pymilvus import ( connections, CollectionSchema, FieldSchema, DataType, Collection, ) # 连接 Milvus connections.connect(alias="default", host="localhost", port="19530") # 定义字段 fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True), FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=512), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1024), ] schema = CollectionSchema(fields=fields, description="text embedding") collection = Collection(name="demo_collection", schema=schema) print("Collection created:", collection.name)

这里有一点要特别注意：不同的 Embedding 模型，向量维度可能不同，写入 Milvus 时要保证 dim 参数与模型输出维度一致。

5.3 Agent 场景：Codex 接入 DeepSeek 和 GLM

很多开发者喜欢用 Codex CLI 来自动化改代码。默认 Codex 走 OpenAI 接口，但可以通过环境变量把它指向 DeepSeek 或 GLM。

在终端中执行：

export OPENAI_API_KEY="sk-xxxxxx" export OPENAI_BASE_URL="https://api.deepseek.com/v1"

然后运行：

codex "在项目根目录新增一个 README.md"

这样 Codex 就会使用 DeepSeek 作为底层模型。同样的方式也可用于接入 GLM，把地址改成智谱的接口地址即可。

需要注意：Codex 对函数调用和工具调用的兼容性有一定要求，不是所有模型都能完美支持。如果遇到工具调用失败，优先检查模型是否支持 function calling，而不是盲目调整 Prompt。

5.4 本地部署 Qwen 和 DeepSeek 轻量版

相比在线 API，本地部署更利于数据隐私保护。个人开发者最容易上手的方式是使用 Ollama。

安装 Ollama 后，直接拉取模型：

ollama pull qwen2.5:7b ollama pull deepseek-r1:7b

启动服务：

ollama serve

然后通过 OpenAI 兼容接口调用：

# 文件路径：ollama_demo.py from openai import OpenAI client = OpenAI( api_key="ollama", base_url="http://localhost:11434/v1", ) resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "你好，介绍一下你自己"}], ) print(resp.choices[0].message.content)

本地部署的优点是完全掌控数据，缺点是对硬件要求较高。如果模型参数量大，建议使用量化版本，例如qwen2.5:7b-q4_K_M，可以显著降低显存占用。

6. 测试结果记录与选型结论

6.1 我的观察记录

我在同一批测试问题上记录了四款模型的输出特点。

需要说明的是，这个表格只是基于我的测试样本，不代表模型真实能力排名。

6.2 选型建议

• 做复杂数据分析和深度推理：优先 DeepSeek。
• 做金融文本抽取与语义理解：可以重点测试 GLM。
• 做低成本私有化部署：选 Qwen。
• 做前沿 Agent 玩法和快速原型：关注 K3。

在实际业务中，最常见的方式是同时接入两家模型，将不同难度的请求分流到不同模型上，这样可以平衡质量和成本。

7. 常见问题与排查思路

7.1 返回 429 或 402 错误

推荐在代码中加入简单的重试逻辑，避免偶发限流影响业务。

7.2 DeepSeek 响应很慢

DeepSeek 为了输出高质量答案，会进行较长的内部推理。如果业务对延迟要求高，可以设置max_tokens上限，或使用其非推理类快速模型。

如果是在本地部署，还需要确认 CPU 或 GPU 是否支持模型运行，建议优先使用量化模型。

7.3 本地部署 Qwen 内存不足

如果在 Ollama 拉取模型后运行报内存不足，一般有两个原因：

• 模型参数量过大。
• 未使用量化版本。

解决方案：

# 删除原模型 ollama rm qwen2.5:7b # 拉取量化版本 ollama pull qwen2.5:7b-q4_K_M

量化模型体积更小，在消费级设备上也能运行。

7.4 金蝶 K3 与 AI 模型混淆

再次强调，如果你搜索“K3”是为了找大模型，请忽略金蝶 K3 相关内容。金蝶 K3 属于 ERP 软件，常见的“运行时错误 429 ActiveX 部件不能创建对象”和 AI 无关，属于前端组件调用系统 COM 失败，排查时应先确认金蝶客户端是否以管理员权限运行、组件是否完整安装。

8. 最佳实践与工程建议

8.1 不要把业务绑死在单一模型上

大模型技术迭代很快，今天表现最好的模型，三个月后可能被其他模型超越。建议在项目初期就抽象出模型调用层，内部做好统一接口封装，方便替换底层模型。

8.2 建立模型网关

在微服务架构中，可以在业务服务和模型 API 之间加一层模型网关，负责路由、限流、重试、日志和成本统计。这样做的好处是：

• 不同业务可以按优先级分配不同模型。
• 某个模型故障时可以自动切换备用模型。
• 方便统一统计 Token 成本和延迟。

8.3 控制上下文长度和 Token 成本

长对话场景中，历史消息会不断消耗 Token。建议定期压缩历史消息，或使用摘要替代完整历史。例如，超过 20 轮对话后，将前面的内容摘要成一段话，再继续请求模型。

8.4 关注数据安全和合规

在调用云端 API 时，不要将敏感的生产数据直接发送给模型。如果需要处理高敏数据，优先选择私有化部署。同时注意，不同的模型服务商对数据存储和训练策略不同，上线前要仔细阅读平台服务协议。

8.5 建立评测集

不要靠感觉判断模型好坏。建议根据业务整理 50 到 100 条评测数据，让多个模型输出结果，再由人工打分。每次模型版本更新后，跑一遍回归测试，才能知道效果是否提升。

9. 总结

这次把 K3、DeepSeek、GLM、Qwen 四款模型放在一起测试，最大的收获是：选模型不是选“最强”，而是选“最匹配”。

K3 适合追逐前沿能力，DeepSeek 适合复杂的推理任务，GLM 适合中文金融场景，Qwen 适合成本敏感和私有化部署场景。实际开发中，我更推荐搭建一套通用的模型接入层，把不同模型组合起来使用。

你可以直接从文中的 Python 调用代码开始，替换成自己的 API Key，再针对业务准备一批测试问题，跑一轮真实的横向评测。

如果这篇文章对你有帮助，可以收藏备用。后续我还会补充更多关于模型评估、RAG 落地和 Agent 工程化的实践笔记。