最近在做多模型接入的小项目我趁机把国内几款主流大模型拉在一起做了轮横向测试覆盖对话推理、代码补全、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 统一测试维度为了尽量公平我设置了以下固定参数。维度设置温度 temperature0.2偏确定最大输出长度 max_tokens2048上下文长度按各模型官方默认值测试问题同一套 20 个问题不同模型对“温度”参数的解析略有差异但整体趋势一致温度越低输出越保守稳定温度越高越有创造性。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 在中文理解和金融文本处理上有优势。我用它做了两个测试从一份模拟的上市公司公告中抽取“净利润、同比变化、风险提示”三个字段。解释一段包含金融术语的中文文本。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.xpip install -U openai4.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_keyapi_key, base_urlbase_url, ) response client.chat.completions.create( modelmodel, messages[ {role: user, content: user_content}, ], temperaturetemperature, max_tokensmax_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_keyAPI_KEY, base_urlhttps://api.k3.example.com/v1, modelk3-xxx, user_content解释一下什么是 API 网关, ) print(K3 输出, k3_result) # 调用示例DeepSeek deepseek_result chat_once( api_keyAPI_KEY, base_urlhttps://api.deepseek.com/v1, modeldeepseek-chat, user_content解释一下什么是 API 网关, ) print(DeepSeek 输出, deepseek_result) # 调用示例GLM glm_result chat_once( api_keyAPI_KEY, base_urlhttps://open.bigmodel.cn/api/paas/v4, modelglm-4-flash, user_content解释一下什么是 API 网关, ) print(GLM 输出, glm_result) # 调用示例Qwen qwen_result chat_once( api_keyAPI_KEY, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, modelqwen-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_keyapi_key, base_urlbase_url) response client.chat.completions.create( modelmodel, 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并附带简短的业务建议简洁实用。QwenSQL 写法中规中矩注释清晰适合快速复制。从这个结果可以看出选模型不能脱离场景。如果只是要一个稳妥答案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_keysk-xxxxxx, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, ) def get_embedding(text: str): resp client.embeddings.create( modeltext-embedding-v3, inputtext, ) 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(aliasdefault, hostlocalhost, port19530) # 定义字段 fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length512), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), ] schema CollectionSchema(fieldsfields, descriptiontext embedding) collection Collection(namedemo_collection, schemaschema) print(Collection created:, collection.name)这里有一点要特别注意不同的 Embedding 模型向量维度可能不同写入 Milvus 时要保证 dim 参数与模型输出维度一致。5.3 Agent 场景Codex 接入 DeepSeek 和 GLM很多开发者喜欢用 Codex CLI 来自动化改代码。默认 Codex 走 OpenAI 接口但可以通过环境变量把它指向 DeepSeek 或 GLM。在终端中执行export OPENAI_API_KEYsk-xxxxxx export OPENAI_BASE_URLhttps://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_keyollama, base_urlhttp://localhost:11434/v1, ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 你好介绍一下你自己}], ) print(resp.choices[0].message.content)本地部署的优点是完全掌控数据缺点是对硬件要求较高。如果模型参数量大建议使用量化版本例如qwen2.5:7b-q4_K_M可以显著降低显存占用。6. 测试结果记录与选型结论6.1 我的观察记录我在同一批测试问题上记录了四款模型的输出特点。维度K3DeepSeekGLMQwen通识问答优秀优秀良好良好复杂推理良好极致良好中等代码生成良好优秀良好良好中文金融文本良好良好优秀中等响应速度快较慢快快成本中等较高中等较低本地部署一般支持一般支持完善需要说明的是这个表格只是基于我的测试样本不代表模型真实能力排名。6.2 选型建议做复杂数据分析和深度推理优先 DeepSeek。做金融文本抽取与语义理解可以重点测试 GLM。做低成本私有化部署选 Qwen。做前沿 Agent 玩法和快速原型关注 K3。在实际业务中最常见的方式是同时接入两家模型将不同难度的请求分流到不同模型上这样可以平衡质量和成本。7. 常见问题与排查思路7.1 返回 429 或 402 错误问题现象常见原因解决思路429 Too Many Requests并发超限或触发限流降低 QPS加入重试和退避策略402 Payment Required账户余额不足检查控制台余额并充值InvalidApiKeyAPI Key 错误检查 Key 前后是否有空格Model Not Found模型名称过时查阅官方文档获取最新模型名推荐在代码中加入简单的重试逻辑避免偶发限流影响业务。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 工程化的实践笔记。