2025年，国产大模型已经发展得相当不错了。

从文心一言、通义千问，到豆包、Kimi、DeepSeek，国产大模型的能力越来越强，在很多场景下已经能和GPT-4o相媲美，而且价格更便宜，访问更稳定。

我们团队最近在做一个基于大模型的应用，一开始用的是GPT-4o，后来因为成本和合规的原因，切换到了国产大模型。切换的过程中，踩了不少坑，也积累了一些实战经验。

这篇文章，我想分享一下使用国产大模型的踩坑总结和实战经验，希望能帮到正在做类似事情的朋友。

为什么选择国产大模型

先说说我们为什么从GPT切换到国产大模型。

第一个原因是成本。GPT-4o的API价格不便宜，我们的应用调用量很大，每个月的API费用很高。国产大模型的价格通常只有GPT的几分之一甚至十分之一，切换之后成本降了很多。

第二个原因是合规。我们的应用涉及一些国内的业务数据，把数据传到境外的API有合规风险。国产大模型的数据都在国内，合规性更好。

第三个原因是访问稳定性。GPT的API在国内访问有时候不稳定，会出现超时或者连接失败的情况。国产大模型的服务器在国内，访问速度快，稳定性好。

第四个原因是中文能力。国产大模型在中文理解和生成方面，其实比GPT更有优势。尤其是在中文的语境、文化、习惯方面，国产大模型理解得更到位。

当然，国产大模型也有不足，比如复杂推理能力、多语言能力、工具调用的稳定性等方面，和GPT还有差距。但对于大多数中文应用场景来说，国产大模型已经足够用了。

坑一：不同模型的能力差异很大

第一个大坑，是不同国产大模型之间的能力差异很大。

我们一开始以为，大模型之间的能力应该差不多，换一个模型应该很简单。但实际用下来发现，不同模型在不同任务上的表现差异非常大。

比如，文心一言在中文写作和文案生成方面表现很好，但在代码生成方面弱一些。通义千问在多模态和长文本方面不错，但在复杂推理方面一般。豆包在对话和创意生成方面很出色，但在结构化输出方面不够稳定。Kimi在长文本处理方面是强项，但在短文本的精确任务上表现一般。DeepSeek在代码和数学推理方面很强，但在中文创意写作方面不如其他模型。

所以，不要指望一个模型搞定所有任务。我们的做法是，根据不同的任务，选择最合适的模型。比如：

  • 文案生成、内容创作：用文心一言或豆包。
  • 长文档处理、RAG：用Kimi或通义千问。
  • 代码生成、技术问答：用DeepSeek。
  • 通用对话、客服：用豆包或通义千问。

我们做了一个模型路由层，根据任务类型自动选择最合适的模型。这样，既能保证效果，又能控制成本。

经验：在选型之前，一定要用自己的真实业务数据做评测。不要看官方的宣传和排行榜，要用自己的测试用例，逐个模型测试，找到最适合自己场景的模型。

坑二：Prompt不能直接复用

第二个大坑，是为GPT写的Prompt，不能直接复用到国产大模型上。

我们一开始以为，Prompt是通用的，换个模型应该也能用。但实际用下来发现，同样的Prompt，在GPT上效果很好，在国产大模型上效果就差很多。

原因是，不同模型的训练数据、指令微调方式、对齐方式都不一样，对Prompt的理解和响应也不一样。有些模型喜欢详细的指令，有些喜欢简洁的；有些对few-shot示例敏感，有些对系统提示敏感。

我们的做法是，为每个模型单独优化Prompt。具体来说：

第一，了解每个模型的"脾气"。比如，有些模型对角色设定很敏感，在Prompt里明确说"你是一个XX专家"，效果会好很多。有些模型对输出格式的要求需要更明确，要在Prompt里详细说明输出的结构。

第二，用每个模型自己的示例。在做few-shot的时候，用这个模型自己生成的好例子作为示例，比用通用的例子效果好。

第三，迭代优化。Prompt不是写一次就完事的，要根据模型的输出不断调整。我们的做法是，准备一批测试用例，每次改完Prompt，跑一遍测试，看效果有没有提升。

第四，有些模型支持结构化输出（比如JSON模式），要善用这个功能。在需要结构化输出的场景，开启JSON模式，比在Prompt里要求输出JSON稳定得多。

经验：切换模型的时候，一定要重新优化Prompt，不要直接复用。把Prompt优化当成模型适配的一部分，投入足够的时间。

坑三：长文本处理的差异

第三个坑，是长文本处理。

国产大模型在长文本方面进步很快，很多模型都支持128K甚至200K的上下文窗口。但实际用下来，长文本处理的效果差异很大。

我们遇到的问题包括：

第一个问题是，"中间遗忘"。很多模型在处理长文本的时候，会忘记中间的内容，只记得开头和结尾。比如，我们把一个几万字的文档放进去，问中间部分的内容，模型经常答非所问。

第二个问题是，上下文窗口的"水分"。有些模型标称支持128K上下文，但实际在超过32K之后，效果就明显下降了。标称的上下文窗口和实际有效的上下文窗口，不是一回事。

第三个问题是，长文本的推理速度慢。上下文越长，推理速度越慢，成本也越高。有些模型在长文本下的速度，比短文本慢好几倍。

我们的解决方案：

第一，不要盲目追求长上下文。能用RAG（检索增强生成）解决的，就不要把所有内容都塞到上下文里。RAG既能降低成本，又能提高准确率。

第二，如果确实需要长上下文，先做测试。用自己的长文本数据，测试模型在不同长度下的效果，找到实际有效的上下文长度。

第三，长文本任务，优先选择在长文本方面有优势的模型（比如Kimi）。

第四，对长文本做预处理。比如，先做摘要，提取关键信息，然后把摘要和关键信息放到上下文里，而不是放全文。

经验：长上下文是国产大模型的卖点，但实际效果要打个问号。在使用之前，一定要用自己的数据测试，不要轻信标称的上下文长度。

坑四：工具调用的稳定性

第四个坑，是工具调用（Function Calling）的稳定性。

我们的应用需要大模型调用外部工具（搜索、数据库查询、API调用等）。GPT的工具调用比较稳定，而国产大模型的工具调用，我们踩了不少坑。

遇到的问题包括：

第一个问题是，参数格式错误。模型有时候会生成不符合JSON Schema的参数，比如少了必填字段、字段类型不对、多了额外的字段。这会导致工具调用失败。

第二个问题是，不调用工具。有时候，明明应该调用工具，但模型直接用自己的知识回答了，没有调用工具。这在需要实时数据或精确数据的场景下，会导致错误。

第三个问题是，多轮工具调用的混乱。在需要多次调用工具的复杂任务中，模型有时候会忘记之前调用的结果，或者重复调用同一个工具，或者调用顺序混乱。

我们的解决方案：

第一，在Prompt里明确工具调用的规则。什么时候该调用工具，什么时候不该调用，调用之后怎么处理结果，都要在Prompt里说清楚。

第二，对工具调用的参数做校验。在调用工具之前，先校验参数是否符合Schema，如果不符合，让模型重新生成。

第三，给模型提供工具调用的示例。在Prompt里加入few-shot示例，展示正确的工具调用方式，能提高稳定性。

第四，有些模型支持"强制工具调用"，在必须调用工具的场景，开启这个功能。

第五，复杂的多轮工具调用，考虑用框架（比如LangChain、AutoGen）来管理，而不是完全依赖模型自己规划。

经验：工具调用是大模型应用的核心能力，但国产大模型在这方面还不够稳定。要做好容错和校验，不要完全依赖模型的工具调用能力。

坑五：API的稳定性和限流

第五个坑，是API的稳定性和限流。

国产大模型的API，整体稳定性还可以，但在高峰期或者模型更新的时候，会出现一些问题。

我们遇到的问题包括：

第一个问题是，偶尔的超时和5xx错误。虽然不多，但在高并发的时候，会影响用户体验。

第二个问题是，限流。每个模型都有QPS和TPM（每分钟token数）的限制。在高峰期，很容易触达限流，导致请求被拒绝。

第三个问题是，模型更新的影响。厂商有时候会静默更新模型，更新之后，模型的行为可能会变化，导致之前优化好的Prompt效果下降。

第四个问题是，不同区域的访问速度差异。虽然都是国内，但不同地区、不同运营商的访问速度可能有差异。

我们的解决方案：

第一，做好重试和降级。对超时和5xx错误，做自动重试（带退避）。如果某个模型不可用，自动切换到备用模型。

第二，合理规划限流。了解每个模型的限流策略，做好请求排队和削峰。在高并发场景，提前申请提高限流额度。

第三，多模型备份。不要只依赖一个模型，准备至少两个备用模型。主模型出问题的时候，自动切换到备用模型。

第四，监控模型行为变化。定期跑测试用例，监控模型的输出质量。如果发现模型行为有变化，及时调整Prompt。

第五，考虑用统一的API网关。把多个模型的API封装成统一的接口，在网关层做负载均衡、限流、重试、降级，这样业务代码不需要关心底层用的是哪个模型。

经验：大模型API不是100%可靠的，要在架构上做好容错和降级。不要把所有鸡蛋放在一个篮子里，多模型备份是必须的。

坑六：成本核算和优化

第六个坑，是成本。

虽然国产大模型比GPT便宜，但如果调用量大，成本也不低。而且，成本的计算比想象中复杂。

我们踩过的坑：

第一个坑是，只看输入输出的单价，忽略了其他成本。比如，缓存的成本、微调的成本、专用模型的成本等。

第二个坑是，没有做用量监控。一开始，我们没有详细的用量监控，到月底看账单才发现超了预算。

第三个坑是，没有做模型分级。所有请求都用最贵的模型，其实很多简单的请求，用便宜的小模型就够了。

我们的成本优化措施：

第一，模型分级。简单的任务（分类、提取、摘要）用便宜的小模型，复杂的任务才用大模型。我们做了一个智能路由，根据任务的复杂度自动选择模型。

第二，缓存。对相同的请求，缓存结果。尤其是在FAQ、常见问题的场景，缓存命中率很高，能省很多钱。

第三，优化Prompt。减少不必要的token，比如精简系统提示、压缩上下文。token用得少，成本就低。

第四，批量处理。把多个请求合并成批量调用，有些模型批量调用有折扣。

第五，详细的成本监控。按模型、按业务、按用户维度，监控token消耗和费用。设置预算告警，超了及时发现。

第六，考虑微调。如果某个场景的调用量很大，可以考虑用小模型微调，达到接近大模型的效果，但成本低很多。

经验：大模型的成本很容易失控，从一开始就要有成本意识。做好模型分级、缓存、监控，把成本控制在可接受的范围内。

坑七：内容安全和合规

第七个坑，是内容安全和合规。

国产大模型对内容安全的要求比GPT更严格，有时候会出现"过度审核"的情况。

我们遇到的问题包括：

第一个问题是，正常的内容被误判为违规。比如，一些技术文档、医疗健康的内容，可能会被模型拒绝回答。

第二个问题是，审核标准不透明。有时候不知道为什么内容被拒了，也没有明确的申诉渠道。

第三个问题是，不同模型的审核标准不一样。同一个内容，在A模型上能通过，在B模型上就被拒了。

我们的应对策略：

第一，了解每个模型的审核规则。大部分厂商会提供内容安全的文档，仔细阅读，了解哪些内容是敏感的。

第二，对可能被误判的内容，做预处理。比如，对敏感词做替换或脱敏，调整表达方式。

第三，多模型备份。如果一个模型拒绝回答，自动切换到另一个模型。

第四，重要的内容，考虑用微调或者私有化部署，绕过公网模型的内容审核。但私有化部署的成本高，要权衡。

第五，和厂商保持沟通。如果遇到误判，联系厂商的技术支持，反馈问题。有些厂商会根据反馈调整审核策略。

经验：内容安全是国产大模型的特色，也是使用中必须面对的问题。要了解规则，做好预处理和多模型备份，避免因为内容审核影响业务。

实战经验总结

最后，总结几条实战经验：

第一，先评测，再选型。不要看宣传和排行榜，要用自己的业务数据，对多个模型做详细的评测。评测的维度包括：效果、速度、稳定性、成本、合规性。

第二，抽象一层，不要绑定具体模型。在业务代码和模型API之间，加一个抽象层。这样，切换模型、加模型、做降级都很方便，不需要改业务代码。

第三，Prompt工程是核心。同样的模型，Prompt写得好不好，效果天差地别。要投入时间做Prompt优化，为每个模型单独优化Prompt。

第四，做好容错和降级。大模型API不可靠，模型会出错，工具调用会失败。要在架构上做好重试、降级、备份，保证系统的稳定性。

第五，监控一切。监控模型的效果、速度、成本、错误率。有了数据，才能发现问题、优化系统。

第六，持续迭代。大模型技术发展很快，新的模型、新的功能不断出现。要持续关注，定期评测新模型，及时引入更好的模型。

第七，不要追求完美。大模型不是万能的，在一些场景下效果可能不如预期。要接受大模型的局限性，在合适的场景用合适的技术。

写在最后

国产大模型这两年的进步，超出了很多人的预期。从一开始的"能用"，到现在的"好用"，国产大模型已经能支撑很多真实的业务场景了。

当然，和GPT相比，国产大模型还有一些差距，尤其是在复杂推理、工具调用稳定性、多语言能力方面。但在中文场景、成本、合规、访问速度方面，国产大模型有明显的优势。

如果你正在考虑用国产大模型，我的建议是：大胆尝试，小心验证。先用小范围的场景试水，积累经验，然后逐步扩大。踩坑是正常的，踩过坑之后，才能真正用好国产大模型。

希望我的踩坑总结和实战经验，能帮到正在做类似事情的朋友。如果你也有国产大模型的使用经验，欢迎在评论区交流。