最近做技术选型把国内几款主流大模型在真实业务场景里挨个测了一遍包括长文档分析、复杂代码排查、金融文本抽取和端侧离线部署。跑完之后最大的感受确实像网上流传的那句话最前沿的是 K3最极致的是 DeepSeek最懂股价的是 GLM最经济的是 Qwen。这句话适合当结论但开发者不能只停在结论上。我们更需要搞清楚每句话背后的技术原因以及什么时候该选谁、怎么接入、有哪些坑。这篇文章就以 K3、DeepSeek、GLM、Qwen 四条线展开结合 API 调用、本地部署和工程排错整理一套能直接用在实际项目里的选型与实战笔记。1. 背景与核心概念1.1 国内大模型格局为什么值得重新评估过去两年国内大模型市场已经走过了“发布一个模型就刷屏”的早期阶段进入了一个更务实的时期模型开始拼推理能力、长文本、工具调用、成本、开源生态和私有化部署体验。衡量一个模型能不能用不再是看跑分榜单而是看它在真实业务中被调用时的表现。我把这种需求归纳成四个维度前沿性能看到多新的架构思路、多模态能力、Agent 工具调用水平。极致性复杂逻辑、代码推理、数学推导能不能给出稳定且有深度的结果。场景化在垂直领域是不是更懂业务比如金融文本、办公文档、结构化抽取。经济性同质量输出下的 token 成本以及能否在本地方便部署。这四个维度正好对应标题里提到的 K3、DeepSeek、GLM、Qwen。理解了每个模型的长处选型时就不会“谁火用谁”而是“哪个场景用哪个模型”。1.2 四个模型的定位速览先给一个总体印象后续章节会详细展开模型核心印象适合场景K3迭代激进前沿方向跟进快探索类 Agent、长上下文、多模态实验DeepSeek推理链路强回答严谨代码 Debug、复杂逻辑、数学题、技术问答GLM场景化能力均衡金融/办公文本好文本抽取、JSON 输出、RAG、智能客服Qwen开源生态完整成本可控私有化部署、批量离线任务、嵌入模型这里的“适合场景”是常见观察不是绝对的。实际项目中最好用你自己的测试集跑一遍再用。1.3 K3 在多语境下到底指什么先说一个容易踩坑的点K3 这个名字并不唯一。除了 AI 模型语境里的 K3例如 Kimi K3 这类新版本迭代代号还有金蝶 K3ERP 系统、路由器 K3硬件型号等完全不同的概念。搜索 K3 时你会看到“金蝶 K3 凭证导入”“K3 TTL 刷机”“运行时错误 429 ActiveX 部件不能创建对象”这类结果它们跟大模型没有任何关系。如果你是想做 AI 模型选型看到 K3 时应该先确认它的语境是模型代号、产品版本还是硬件名称。本文按 AI 模型方向讨论重点观察 K3 在长上下文、Agent、多模态等方向的前沿尝试。由于这类代号的版本迭代非常快具体参数和 API 入口需要以官方文档为准不建议听信二手消息。2. 环境准备与版本说明2.1 本地环境准备实际调用大模型 API不需要很高配置一个普通的开发机即可。但如果你要做本地部署建议准备独立显卡显存越大越好。推荐环境清单操作系统Windows 10/11、macOS、Ubuntu 20.04 以上均可。Python3.9 以上建议 3.10 或 3.11。依赖管理pip 或 conda。OpenAI SDK主要负责调用兼容 OpenAI 接口的模型。Ollama / vLLM用于本地部署 Qwen 等开源模型。Node.js 或 Java根据需要接入其他工具链。IDEVS Code 或 JetBrains 系列。不需要把四个模型的 SDK 都装一遍。现在大部分国内模型都提供 OpenAI 兼容接口统一用openai库就能快速验证。2.2 获取 API Key 与模型访问方式四种模型获取方式大体分两类闭源或半开源模型的云端 API去对应开放平台申请 API Key比如 DeepSeek 开放平台、智谱开放平台、阿里云百炼。开源模型的本地部署去 Hugging Face、ModelScope 或 Ollama 拉权重在本地运行。用 API 的优势是免运维速度和稳定性有保障适合生产环境。本地部署的优势是数据不出内网、离线可用、按量成本低适合数据敏感或批量处理的场景。2.3 统一 OpenAI 兼容接口现在国内主流大模型几乎都兼容 OpenAI 的请求格式。这意味着你只需要改base_url和api_key就能用同一套代码切换模型。OpenAI 兼容接口的核心结构from openai import OpenAI client OpenAI( api_key你的APIKey, base_url模型的兼容地址 ) response client.chat.completions.create( model模型名称, messages[ {role: user, content: 你好} ] ) print(response.choices[0].message.content)这个设计大大降低了迁移成本。后面每组代码示例本质都是在替换base_url、api_key、model三个参数。3. 四款模型的核心特点拆解3.1 K3前沿性体现在哪K3 在标题里被形容为“最前沿”主要是因为它身上集中了很多探索性能力。比如更长的上下文窗口、更强的工具调用、多模态输入的融合以及在 Agent 场景下的任务规划能力。测试长文本场景时直接把一份几十页的文档丢给它要求它输出结构化摘要K3 对上下文的整合能力比较强不容易“读到后面忘前面”。测试工具调用时让它模拟调用外部函数完成数据查询它的参数生成也比较规范这对 Agent 开发很关键。不过也要注意前沿不代表稳定。新模型迭代快有时候能力刚发布API 参数就会调整。如果你想快速跟进最新能力可以保持关注如果是核心生产链路建议先用成熟版本验证不要急着上未稳定的新接口。3.2 DeepSeek极致的推理过程DeepSeek 的“极致”主要体现在推理方面。把它当调试助手时它倾向于先分析问题可能的原因再给出最小复现步骤和修复方案。这种“先思考再回答”的特性在复杂问题排查中非常有用。我测试一个典型的场景模拟线上偶发 Redis 连接超时让 DeepSeek 给出排查思路。它没有直接丢一个通用结论而是把可能原因拆成网络、连接池、序列化、Redis 配置几个维度再逐一给出验证方式。这种结构化思考方式省去了很多盲目试错的时间。DeepSeek 的 API 有deepseek-chat和deepseek-reasoner两类模型。reasoner会输出更长的推理链路适合逻辑推理强的任务chat响应更快适合日常对话。3.3 GLM场景化能力与“懂股价”的来源“GLM 最懂股价”这句民间总结并不是说它能预测股市而是它在金融文本、数据抽取、结构化输出这些场景里表现更顺手。很多测试者会拿股票公告、财报、研报去问 GLM发现它比很多模型更擅长把非结构化文本整理成结构化信息。例如给它一段公告文本要求提取“公司名称、公告日期、影响事项、相关金额”它能稳定输出规范 JSON。这个能力在金融数据分析、内部知识库建设、公文处理等场景中非常实用。在开放能力上GLM 也提供不同级别的模型。有些模型提供免费额度或试用体验比如“GLM Coding 7 天体验卡”这类活动主要面向开发者试跑编码场景。需要注意的是免费体验通常有并发、上下文长度或有效期限制正式使用前要看清规则。3.4 Qwen经济性与开源生态Qwen 最突出的优势是开源生态完整和成本可控。从几亿参数的小模型到几百亿参数的大模型基本都有对应版本。这就意味着可以用小模型跑批量分类、抽取任务成本极低。可以用中等尺寸模型在本地做私有化部署。可以用大尺寸模型做高质量生成按需切换。在相同输出质量的前提下Qwen 系列的 token 单价通常比较有竞争力而且支持本地部署能够绕开按量计费的成本模型。除了 Chat 模型Qwen 也提供了 Embedding 模型。搭配 Milvus、Elasticsearch 这类向量数据库可以快速搭建 RAG 检索链路。实践中最常听到的组合是 Qwen Embedding Milvus Java LangChain4j这个组合适合 Java 后端团队落地知识库问答。4. 实战案例调用与部署4.1 DeepSeek API 最简调用先来最常用的 DeepSeek API 调用示例。安装依赖后用统一 OpenAI 客户端即可。pip install openaiPython 调用代码# 文件路径deepseek_demo.py from openai import OpenAI client OpenAI( api_keysk-你的DeepSeek密钥, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是资深后端开发工程师回答要简洁有条理。}, {role: user, content: 请解释 Redis 缓存穿透并给一个最小处理思路。}, ], temperature0.3, max_tokens1024, streamFalse, ) print(resp.choices[0].message.content)这段代码的运行结果会是一段结构清晰的解释。对于更深度的推理需求可以把model换成deepseek-reasoner但响应时间会更长输出 token 也会更多成本相应提高。建议在代码里加一个统一的call_llm函数把base_url、api_key、model作为参数传入这样后续切换模型时不需要改业务代码。4.2 GLM 的兼容接入与编码场景GLM 同样提供 OpenAI 兼容接口base_url 和智谱平台的地址对应即可。这样写# 文件路径glm_demo.py from openai import OpenAI client OpenAI( api_key你的智谱APIKey, base_urlhttps://open.bigmodel.cn/api/paas/v4 ) resp client.chat.completions.create( modelglm-4-flash, messages[ {role: user, content: 从下面这段文本中提取公司名称、公告日期、影响金额并输出JSON。\n文本某科技公司于2025年11月发布公告宣布获得3.2亿元战略投资资金将用于AI研发。} ], temperature0.2, ) print(resp.choices[0].message.content)因为 GLM 接入了 OpenAI 兼容协议很多第三方工具也能直接配置使用。比如开发者常说的“GLM 接入 Codex”实际上就是把工具配置里的模型供应商改成 GLM 的 base_url 和 key然后在工具中选择对应模型即可。编码相关的使用建议是把任务描述写得像需求文档明确输入、输出、异常处理边界。GLM 对指令的理解能力不错但输出结果还是要靠充分描述来约束。4.3 Qwen 本地部署与低成本批量调用Qwen 支持本地部署这是很多团队选择它的关键原因。最省事的方式是用 Ollama。# 安装 Ollama 后拉取 Qwen 模型 ollama pull qwen2.5:7b # 启动服务 ollama serve在另一个终端运行对话ollama run qwen2.5:7b你也可以通过 HTTP API 调用本地模型这样更容易集成到业务代码# 文件路径qwen_ollama_demo.py import requests resp requests.post( http://localhost:11434/api/chat, json{ model: qwen2.5:7b, messages: [{role: user, content: 写一个 Python 装饰器记录函数执行耗时}], stream: False, }, timeout120, ) print(resp.json()[message][content])本地部署的好处是数据不出内网适合处理敏感文档。缺点是模型能力受限于硬件7B 模型在处理复杂逻辑时效果肯定不如云端几百 B 的大模型。所以在批量任务中建议先用小模型过滤明显简单的问题再把复杂样本交给云端大模型这样能平衡成本与质量。4.4 进阶以 Qwen 为例的向量化与 RAG 思路知识库问答是当前最热门的落地场景之一。思路大致是先对文档切片用 Embedding 模型转成向量再存入向量数据库查询时把用户问题向量化后做相似度检索最后把检索结果交给大模型生成回答。Qwen 的 Embedding 模型可以通过阿里云 DashScope 兼容接口调用# 文件路径embedding_demo.py from openai import OpenAI client OpenAI( api_key你的DashScope API Key, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) resp client.embeddings.create( modeltext-embedding-v3, inputQwen 文本向量化示例, dimensions1024 ) print(resp.data[0].embedding[:10])向量入库时可以选 Milvus、Faiss、PgVector 等数据库。Java 后端团队经常搭配 LangChain4j 使用示例结构大致如下// 文件路径EmbeddingStoreConfig.java // 以下代码为思路示意实际 API 请以当前 LangChain4j 版本为准。 EmbeddingStoreTextSegment store MilvusEmbeddingStore.builder() .uri(http://localhost:19530) .collectionName(qwen_embeddings) .dimension(1024) .build();这里要特别注意维度一致性。你调用 Embedding 模型时设置的dimensions必须和建集合时设置的dimension保持一致不然查询时会报错。4.5 选型建议与成本对比从工程视角给一个简化版选型建议场景推荐模型理由复杂代码 DebugDeepSeek推理链路清晰适合逐步分析金融/公告文本抽取GLM结构化输出稳定场景化理解好本地离线批量任务Qwen 7B/14B可私有化部署成本低长文档摘要、前沿 Agent 实验K3长上下文和工具调用是重点方向RAG 嵌入与检索Qwen Embedding生态好兼容 OpenAI 接口成本方面本地部署 Qwen 主要是硬件一次性投入云端 API 是按 token 计费大批量任务一定要做缓存和路由避免重复调用。5. 常见问题与排查思路实际对接过程中比较容易出现以下几类问题。问题现象常见原因解决思路请求返回 429并发超限或额度不足检查套餐额度增加重试和限流请求超时网络不稳定或输出太长调大 timeout使用流式输出输出被截断max_tokens 设置过小提高上限或先分段再汇总本地部署显存不足模型参数量太大使用量化版 GGUF换更小模型JSON 输出格式不稳定提示词约束不够使用 JSON Schema后置校验字段嵌入查询结果为空向量维度不一致检查集合维度与模型输出维度模型返回内容偏旧上下文知识截止时间较早使用 RAG 补充最新资料排查顺序建议先看返回码再看请求参数最后看网络和配置。很多“模型不听话”的问题其实是提示词没有把输出格式约束清楚。下面展开两个最常见的场景。5.1 请求报错与限流如果调用 API 时持续出现 429 或连接错误先检查账户余额再看是不是请求频率过高。多数开放平台都有并发限制个人测试时建议加入重试机制import time from openai import OpenAI client OpenAI(api_key你的APIKey, base_url你的BaseUrl) def call_with_retry(messages, retries3): for i in range(retries): try: resp client.chat.completions.create( model模型名称, messagesmessages, max_tokens1024, ) return resp.choices[0].message.content except Exception as e: print(f第 {i 1} 次请求失败: {e}) time.sleep(2 ** i) raise RuntimeError(请求重试后仍然失败)这个函数用指数退避策略等待重试可以减少突发并发导致的问题。生产环境建议用消息队列做异步削峰而不是在一个线程里死等。5.2 本地部署资源不足本地部署 Qwen 时最大的门槛是显存。7B 模型量化后大约需要 6GB 到 8GB 显存14B 模型需要更多。如果你的机器显存不足可以选择更小尺寸的模型或者使用 GGUF 量化版。在 Ollama 中可以用不同 tag 拉取不同量化版本ollama pull qwen2.5:7b-q4_K_M这里q4_K_M表示 4 bit 量化版本能在尽量保留效果的前提下减少显存占用。如果仍然不够可以考虑用 CPU 推理但速度会明显下降只适合离线场景。6. 最佳实践与工程建议6.1 多模型路由与降级真实项目里不建议只绑定一个模型。正确做法是维护一个模型路由层根据任务类型、成本预算、服务可用性动态选择模型。# 文件路径model_router.py def choose_model(task_type: str) - str: if task_type code_debug: return deepseek-reasoner if task_type financial_extract: return glm-4-flash if task_type batch_classify: return qwen2.5:7b if task_type long_doc: return k3-前沿模型 return qwen-turbo路由层还可以加入熔断逻辑主模型连续报错时自动切换到备用模型。当某个模型响应延迟升高时降低它的流量比例。对简单问题直接用小模型复杂问题才走大模型。这能显著降低成本和故障风险。6.2 结构化输出与结果校验很多业务场景要求模型输出 JSON 或特定字段。单纯靠提示词写“请输出 JSON”并不够最好在代码层做校验和兜底。建议流程在提示词里给出明确的字段说明和示例。使用模型提供的 JSON 输出模式或参数。拿到结果后用json.loads解析做字段校验。解析失败或缺少字段时自动重试一次。import json def parse_model_json(text: str) - dict: try: return json.loads(text) except json.JSONDecodeError: raise ValueError(f模型输出不是合法 JSON: {text[:200]})这样可以避免模型偶尔输出多余说明导致业务崩坏。6.3 数据与权限安全使用云端 API 时要避免把用户隐私、账号明文、高敏感业务数据直接放进提示词。常见做法是脱敏后再发送手机号、身份证、密钥等替换成占位符。日志中不打印完整 prompt 和完整输出。涉及核心数据时优先使用私有化部署。API Key 不要硬编码在代码里用环境变量或配置中心管理。这一点在金融、政务、医疗场景尤其重要。合规要求严格时你的技术方案不仅要能用还要能证明数据流向是安全的。6.4 评估迭代与成本预算上线前一定要准备评估集不要靠一两个例子判断模型效果。评估集可以从真实历史数据中抽 100 条到 500 条覆盖常见场景和边界情况。评估维度建议准确率抽取结果或分类结果是否正确。格式率输出是否为合法 JSON/XML。鲁棒性掺杂噪声、错别字后是否依然稳定。延迟接口响应时间是否满足业务要求。成本每月 token 消耗是否在预算内。每次切换模型版本都重新跑一遍相同评估集才能判断这次升级是变好还是变坏。7. 总结与学习路线7.1 本文核心收获一句话版本K3 代表了前沿探索DeepSeek 代表了极致推理GLM 代表了场景落地Qwen 代表了经济与开源。具体到项目里你要做的是按场景建模而不是按名气选型。从实操角度看我们完成了这几件事掌握了 OpenAI 兼容接口的统一调用方式。完成了 DeepSeek API、GLM 兼容接入和 Qwen 本地部署的最小链路。理解了 Embedding 与 RAG 的基本流程。整理了请求限流、JSON 解析、多模型路由等工程化方案。7.2 下一步学习方向如果你接下来想深入可以按这个路线推进从 API 调用走向提示词设计学会用 few-shot 示例约束输出格式。学习 RAG 链路把公司内部文档接进大模型。尝试微调小模型用 LoRA 等方式让 Qwen 更懂你的业务术语。搭建一套多模型评估脚本让选型从“感觉”变成“数据”。大模型领域变化很快今天的主流可能过两个月就被新版本替代。保持测试习惯、形成自己的评估集比记住某个模型的名字更有价值。建议你直接用本文的代码跑一遍把四个模型放到自己的业务数据里实测一次再下结论。 国内大模型选型实战：K3、DeepSeek、GLM、Qwen对比与部署指南
最近做技术选型把国内几款主流大模型在真实业务场景里挨个测了一遍包括长文档分析、复杂代码排查、金融文本抽取和端侧离线部署。跑完之后最大的感受确实像网上流传的那句话最前沿的是 K3最极致的是 DeepSeek最懂股价的是 GLM最经济的是 Qwen。这句话适合当结论但开发者不能只停在结论上。我们更需要搞清楚每句话背后的技术原因以及什么时候该选谁、怎么接入、有哪些坑。这篇文章就以 K3、DeepSeek、GLM、Qwen 四条线展开结合 API 调用、本地部署和工程排错整理一套能直接用在实际项目里的选型与实战笔记。1. 背景与核心概念1.1 国内大模型格局为什么值得重新评估过去两年国内大模型市场已经走过了“发布一个模型就刷屏”的早期阶段进入了一个更务实的时期模型开始拼推理能力、长文本、工具调用、成本、开源生态和私有化部署体验。衡量一个模型能不能用不再是看跑分榜单而是看它在真实业务中被调用时的表现。我把这种需求归纳成四个维度前沿性能看到多新的架构思路、多模态能力、Agent 工具调用水平。极致性复杂逻辑、代码推理、数学推导能不能给出稳定且有深度的结果。场景化在垂直领域是不是更懂业务比如金融文本、办公文档、结构化抽取。经济性同质量输出下的 token 成本以及能否在本地方便部署。这四个维度正好对应标题里提到的 K3、DeepSeek、GLM、Qwen。理解了每个模型的长处选型时就不会“谁火用谁”而是“哪个场景用哪个模型”。1.2 四个模型的定位速览先给一个总体印象后续章节会详细展开模型核心印象适合场景K3迭代激进前沿方向跟进快探索类 Agent、长上下文、多模态实验DeepSeek推理链路强回答严谨代码 Debug、复杂逻辑、数学题、技术问答GLM场景化能力均衡金融/办公文本好文本抽取、JSON 输出、RAG、智能客服Qwen开源生态完整成本可控私有化部署、批量离线任务、嵌入模型这里的“适合场景”是常见观察不是绝对的。实际项目中最好用你自己的测试集跑一遍再用。1.3 K3 在多语境下到底指什么先说一个容易踩坑的点K3 这个名字并不唯一。除了 AI 模型语境里的 K3例如 Kimi K3 这类新版本迭代代号还有金蝶 K3ERP 系统、路由器 K3硬件型号等完全不同的概念。搜索 K3 时你会看到“金蝶 K3 凭证导入”“K3 TTL 刷机”“运行时错误 429 ActiveX 部件不能创建对象”这类结果它们跟大模型没有任何关系。如果你是想做 AI 模型选型看到 K3 时应该先确认它的语境是模型代号、产品版本还是硬件名称。本文按 AI 模型方向讨论重点观察 K3 在长上下文、Agent、多模态等方向的前沿尝试。由于这类代号的版本迭代非常快具体参数和 API 入口需要以官方文档为准不建议听信二手消息。2. 环境准备与版本说明2.1 本地环境准备实际调用大模型 API不需要很高配置一个普通的开发机即可。但如果你要做本地部署建议准备独立显卡显存越大越好。推荐环境清单操作系统Windows 10/11、macOS、Ubuntu 20.04 以上均可。Python3.9 以上建议 3.10 或 3.11。依赖管理pip 或 conda。OpenAI SDK主要负责调用兼容 OpenAI 接口的模型。Ollama / vLLM用于本地部署 Qwen 等开源模型。Node.js 或 Java根据需要接入其他工具链。IDEVS Code 或 JetBrains 系列。不需要把四个模型的 SDK 都装一遍。现在大部分国内模型都提供 OpenAI 兼容接口统一用openai库就能快速验证。2.2 获取 API Key 与模型访问方式四种模型获取方式大体分两类闭源或半开源模型的云端 API去对应开放平台申请 API Key比如 DeepSeek 开放平台、智谱开放平台、阿里云百炼。开源模型的本地部署去 Hugging Face、ModelScope 或 Ollama 拉权重在本地运行。用 API 的优势是免运维速度和稳定性有保障适合生产环境。本地部署的优势是数据不出内网、离线可用、按量成本低适合数据敏感或批量处理的场景。2.3 统一 OpenAI 兼容接口现在国内主流大模型几乎都兼容 OpenAI 的请求格式。这意味着你只需要改base_url和api_key就能用同一套代码切换模型。OpenAI 兼容接口的核心结构from openai import OpenAI client OpenAI( api_key你的APIKey, base_url模型的兼容地址 ) response client.chat.completions.create( model模型名称, messages[ {role: user, content: 你好} ] ) print(response.choices[0].message.content)这个设计大大降低了迁移成本。后面每组代码示例本质都是在替换base_url、api_key、model三个参数。3. 四款模型的核心特点拆解3.1 K3前沿性体现在哪K3 在标题里被形容为“最前沿”主要是因为它身上集中了很多探索性能力。比如更长的上下文窗口、更强的工具调用、多模态输入的融合以及在 Agent 场景下的任务规划能力。测试长文本场景时直接把一份几十页的文档丢给它要求它输出结构化摘要K3 对上下文的整合能力比较强不容易“读到后面忘前面”。测试工具调用时让它模拟调用外部函数完成数据查询它的参数生成也比较规范这对 Agent 开发很关键。不过也要注意前沿不代表稳定。新模型迭代快有时候能力刚发布API 参数就会调整。如果你想快速跟进最新能力可以保持关注如果是核心生产链路建议先用成熟版本验证不要急着上未稳定的新接口。3.2 DeepSeek极致的推理过程DeepSeek 的“极致”主要体现在推理方面。把它当调试助手时它倾向于先分析问题可能的原因再给出最小复现步骤和修复方案。这种“先思考再回答”的特性在复杂问题排查中非常有用。我测试一个典型的场景模拟线上偶发 Redis 连接超时让 DeepSeek 给出排查思路。它没有直接丢一个通用结论而是把可能原因拆成网络、连接池、序列化、Redis 配置几个维度再逐一给出验证方式。这种结构化思考方式省去了很多盲目试错的时间。DeepSeek 的 API 有deepseek-chat和deepseek-reasoner两类模型。reasoner会输出更长的推理链路适合逻辑推理强的任务chat响应更快适合日常对话。3.3 GLM场景化能力与“懂股价”的来源“GLM 最懂股价”这句民间总结并不是说它能预测股市而是它在金融文本、数据抽取、结构化输出这些场景里表现更顺手。很多测试者会拿股票公告、财报、研报去问 GLM发现它比很多模型更擅长把非结构化文本整理成结构化信息。例如给它一段公告文本要求提取“公司名称、公告日期、影响事项、相关金额”它能稳定输出规范 JSON。这个能力在金融数据分析、内部知识库建设、公文处理等场景中非常实用。在开放能力上GLM 也提供不同级别的模型。有些模型提供免费额度或试用体验比如“GLM Coding 7 天体验卡”这类活动主要面向开发者试跑编码场景。需要注意的是免费体验通常有并发、上下文长度或有效期限制正式使用前要看清规则。3.4 Qwen经济性与开源生态Qwen 最突出的优势是开源生态完整和成本可控。从几亿参数的小模型到几百亿参数的大模型基本都有对应版本。这就意味着可以用小模型跑批量分类、抽取任务成本极低。可以用中等尺寸模型在本地做私有化部署。可以用大尺寸模型做高质量生成按需切换。在相同输出质量的前提下Qwen 系列的 token 单价通常比较有竞争力而且支持本地部署能够绕开按量计费的成本模型。除了 Chat 模型Qwen 也提供了 Embedding 模型。搭配 Milvus、Elasticsearch 这类向量数据库可以快速搭建 RAG 检索链路。实践中最常听到的组合是 Qwen Embedding Milvus Java LangChain4j这个组合适合 Java 后端团队落地知识库问答。4. 实战案例调用与部署4.1 DeepSeek API 最简调用先来最常用的 DeepSeek API 调用示例。安装依赖后用统一 OpenAI 客户端即可。pip install openaiPython 调用代码# 文件路径deepseek_demo.py from openai import OpenAI client OpenAI( api_keysk-你的DeepSeek密钥, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是资深后端开发工程师回答要简洁有条理。}, {role: user, content: 请解释 Redis 缓存穿透并给一个最小处理思路。}, ], temperature0.3, max_tokens1024, streamFalse, ) print(resp.choices[0].message.content)这段代码的运行结果会是一段结构清晰的解释。对于更深度的推理需求可以把model换成deepseek-reasoner但响应时间会更长输出 token 也会更多成本相应提高。建议在代码里加一个统一的call_llm函数把base_url、api_key、model作为参数传入这样后续切换模型时不需要改业务代码。4.2 GLM 的兼容接入与编码场景GLM 同样提供 OpenAI 兼容接口base_url 和智谱平台的地址对应即可。这样写# 文件路径glm_demo.py from openai import OpenAI client OpenAI( api_key你的智谱APIKey, base_urlhttps://open.bigmodel.cn/api/paas/v4 ) resp client.chat.completions.create( modelglm-4-flash, messages[ {role: user, content: 从下面这段文本中提取公司名称、公告日期、影响金额并输出JSON。\n文本某科技公司于2025年11月发布公告宣布获得3.2亿元战略投资资金将用于AI研发。} ], temperature0.2, ) print(resp.choices[0].message.content)因为 GLM 接入了 OpenAI 兼容协议很多第三方工具也能直接配置使用。比如开发者常说的“GLM 接入 Codex”实际上就是把工具配置里的模型供应商改成 GLM 的 base_url 和 key然后在工具中选择对应模型即可。编码相关的使用建议是把任务描述写得像需求文档明确输入、输出、异常处理边界。GLM 对指令的理解能力不错但输出结果还是要靠充分描述来约束。4.3 Qwen 本地部署与低成本批量调用Qwen 支持本地部署这是很多团队选择它的关键原因。最省事的方式是用 Ollama。# 安装 Ollama 后拉取 Qwen 模型 ollama pull qwen2.5:7b # 启动服务 ollama serve在另一个终端运行对话ollama run qwen2.5:7b你也可以通过 HTTP API 调用本地模型这样更容易集成到业务代码# 文件路径qwen_ollama_demo.py import requests resp requests.post( http://localhost:11434/api/chat, json{ model: qwen2.5:7b, messages: [{role: user, content: 写一个 Python 装饰器记录函数执行耗时}], stream: False, }, timeout120, ) print(resp.json()[message][content])本地部署的好处是数据不出内网适合处理敏感文档。缺点是模型能力受限于硬件7B 模型在处理复杂逻辑时效果肯定不如云端几百 B 的大模型。所以在批量任务中建议先用小模型过滤明显简单的问题再把复杂样本交给云端大模型这样能平衡成本与质量。4.4 进阶以 Qwen 为例的向量化与 RAG 思路知识库问答是当前最热门的落地场景之一。思路大致是先对文档切片用 Embedding 模型转成向量再存入向量数据库查询时把用户问题向量化后做相似度检索最后把检索结果交给大模型生成回答。Qwen 的 Embedding 模型可以通过阿里云 DashScope 兼容接口调用# 文件路径embedding_demo.py from openai import OpenAI client OpenAI( api_key你的DashScope API Key, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 ) resp client.embeddings.create( modeltext-embedding-v3, inputQwen 文本向量化示例, dimensions1024 ) print(resp.data[0].embedding[:10])向量入库时可以选 Milvus、Faiss、PgVector 等数据库。Java 后端团队经常搭配 LangChain4j 使用示例结构大致如下// 文件路径EmbeddingStoreConfig.java // 以下代码为思路示意实际 API 请以当前 LangChain4j 版本为准。 EmbeddingStoreTextSegment store MilvusEmbeddingStore.builder() .uri(http://localhost:19530) .collectionName(qwen_embeddings) .dimension(1024) .build();这里要特别注意维度一致性。你调用 Embedding 模型时设置的dimensions必须和建集合时设置的dimension保持一致不然查询时会报错。4.5 选型建议与成本对比从工程视角给一个简化版选型建议场景推荐模型理由复杂代码 DebugDeepSeek推理链路清晰适合逐步分析金融/公告文本抽取GLM结构化输出稳定场景化理解好本地离线批量任务Qwen 7B/14B可私有化部署成本低长文档摘要、前沿 Agent 实验K3长上下文和工具调用是重点方向RAG 嵌入与检索Qwen Embedding生态好兼容 OpenAI 接口成本方面本地部署 Qwen 主要是硬件一次性投入云端 API 是按 token 计费大批量任务一定要做缓存和路由避免重复调用。5. 常见问题与排查思路实际对接过程中比较容易出现以下几类问题。问题现象常见原因解决思路请求返回 429并发超限或额度不足检查套餐额度增加重试和限流请求超时网络不稳定或输出太长调大 timeout使用流式输出输出被截断max_tokens 设置过小提高上限或先分段再汇总本地部署显存不足模型参数量太大使用量化版 GGUF换更小模型JSON 输出格式不稳定提示词约束不够使用 JSON Schema后置校验字段嵌入查询结果为空向量维度不一致检查集合维度与模型输出维度模型返回内容偏旧上下文知识截止时间较早使用 RAG 补充最新资料排查顺序建议先看返回码再看请求参数最后看网络和配置。很多“模型不听话”的问题其实是提示词没有把输出格式约束清楚。下面展开两个最常见的场景。5.1 请求报错与限流如果调用 API 时持续出现 429 或连接错误先检查账户余额再看是不是请求频率过高。多数开放平台都有并发限制个人测试时建议加入重试机制import time from openai import OpenAI client OpenAI(api_key你的APIKey, base_url你的BaseUrl) def call_with_retry(messages, retries3): for i in range(retries): try: resp client.chat.completions.create( model模型名称, messagesmessages, max_tokens1024, ) return resp.choices[0].message.content except Exception as e: print(f第 {i 1} 次请求失败: {e}) time.sleep(2 ** i) raise RuntimeError(请求重试后仍然失败)这个函数用指数退避策略等待重试可以减少突发并发导致的问题。生产环境建议用消息队列做异步削峰而不是在一个线程里死等。5.2 本地部署资源不足本地部署 Qwen 时最大的门槛是显存。7B 模型量化后大约需要 6GB 到 8GB 显存14B 模型需要更多。如果你的机器显存不足可以选择更小尺寸的模型或者使用 GGUF 量化版。在 Ollama 中可以用不同 tag 拉取不同量化版本ollama pull qwen2.5:7b-q4_K_M这里q4_K_M表示 4 bit 量化版本能在尽量保留效果的前提下减少显存占用。如果仍然不够可以考虑用 CPU 推理但速度会明显下降只适合离线场景。6. 最佳实践与工程建议6.1 多模型路由与降级真实项目里不建议只绑定一个模型。正确做法是维护一个模型路由层根据任务类型、成本预算、服务可用性动态选择模型。# 文件路径model_router.py def choose_model(task_type: str) - str: if task_type code_debug: return deepseek-reasoner if task_type financial_extract: return glm-4-flash if task_type batch_classify: return qwen2.5:7b if task_type long_doc: return k3-前沿模型 return qwen-turbo路由层还可以加入熔断逻辑主模型连续报错时自动切换到备用模型。当某个模型响应延迟升高时降低它的流量比例。对简单问题直接用小模型复杂问题才走大模型。这能显著降低成本和故障风险。6.2 结构化输出与结果校验很多业务场景要求模型输出 JSON 或特定字段。单纯靠提示词写“请输出 JSON”并不够最好在代码层做校验和兜底。建议流程在提示词里给出明确的字段说明和示例。使用模型提供的 JSON 输出模式或参数。拿到结果后用json.loads解析做字段校验。解析失败或缺少字段时自动重试一次。import json def parse_model_json(text: str) - dict: try: return json.loads(text) except json.JSONDecodeError: raise ValueError(f模型输出不是合法 JSON: {text[:200]})这样可以避免模型偶尔输出多余说明导致业务崩坏。6.3 数据与权限安全使用云端 API 时要避免把用户隐私、账号明文、高敏感业务数据直接放进提示词。常见做法是脱敏后再发送手机号、身份证、密钥等替换成占位符。日志中不打印完整 prompt 和完整输出。涉及核心数据时优先使用私有化部署。API Key 不要硬编码在代码里用环境变量或配置中心管理。这一点在金融、政务、医疗场景尤其重要。合规要求严格时你的技术方案不仅要能用还要能证明数据流向是安全的。6.4 评估迭代与成本预算上线前一定要准备评估集不要靠一两个例子判断模型效果。评估集可以从真实历史数据中抽 100 条到 500 条覆盖常见场景和边界情况。评估维度建议准确率抽取结果或分类结果是否正确。格式率输出是否为合法 JSON/XML。鲁棒性掺杂噪声、错别字后是否依然稳定。延迟接口响应时间是否满足业务要求。成本每月 token 消耗是否在预算内。每次切换模型版本都重新跑一遍相同评估集才能判断这次升级是变好还是变坏。7. 总结与学习路线7.1 本文核心收获一句话版本K3 代表了前沿探索DeepSeek 代表了极致推理GLM 代表了场景落地Qwen 代表了经济与开源。具体到项目里你要做的是按场景建模而不是按名气选型。从实操角度看我们完成了这几件事掌握了 OpenAI 兼容接口的统一调用方式。完成了 DeepSeek API、GLM 兼容接入和 Qwen 本地部署的最小链路。理解了 Embedding 与 RAG 的基本流程。整理了请求限流、JSON 解析、多模型路由等工程化方案。7.2 下一步学习方向如果你接下来想深入可以按这个路线推进从 API 调用走向提示词设计学会用 few-shot 示例约束输出格式。学习 RAG 链路把公司内部文档接进大模型。尝试微调小模型用 LoRA 等方式让 Qwen 更懂你的业务术语。搭建一套多模型评估脚本让选型从“感觉”变成“数据”。大模型领域变化很快今天的主流可能过两个月就被新版本替代。保持测试习惯、形成自己的评估集比记住某个模型的名字更有价值。建议你直接用本文的代码跑一遍把四个模型放到自己的业务数据里实测一次再下结论。