从依赖走到自主：AI中文大模型笔记

大概从2023年开始，我就在思考一个很现实的问题：我们做的产品，核心能力是不是都依赖GPT？

查了一圈发现，OpenAI那边的API响应时间从500ms涨到了2-3s，偶尔还超时。

为什么写这篇文章？

大概从2023年开始，我就在思考一个很现实的问题：我们做的产品，核心能力是不是都依赖GPT？这就像开餐厅，但菜品配方都在别人手里，哪天GPT涨价、限流、或者直接不服务中文，那怎么办？

这篇文章不是要吹嘘国产模型有多牛，也不是要贬低GPT。我想分享的是过去一年里，我们团队从完全依赖GPT，到逐步迁移到国产大模型，再到建立自主可控的AI能力体系的全过程。中间踩过的坑、吃过的亏，希望能给你一些参考。

背景：焦虑的开始

最早触发这个想法的是一个很普通的周五下午。我们做的一个智能客服产品，用户突然反馈回答质量明显下降。查了一圈发现，OpenAI那边的API响应时间从500ms涨到了2-3s，偶尔还超时。更要命的是，当月成本直接翻倍。

这还不是最糟的。后面又遇到两个事：

1. 敏感内容限制：用户问了一些合规领域的问题，GPT直接拒答，但这些问题其实完全合法
2. 中文理解偏差：一些中文特有的表达，比如"这个需求有点那个"，GPT经常理解不了语境

这时候开始认真考虑：是不是该看看国产模型了？

需求：我们要什么？

不是盲目追求国产化，我们先梳理了实际需求：

核心需求

• 稳定性：API响应时间 < 1s，可用性 > 99.5%
• 中文理解能力：能准确理解中文语境、俚语、行业黑话
• 合规性：数据不出境，符合国内监管要求
• 成本可控：单位成本比GPT低至少30%
• 可迁移性：现有Prompt架构尽量不用大改

次要需求

• 长上下文支持（至少32K）
• 支持Function Calling
• 有完善的开发文档和SDK

实现：逐步迁移

我们不是一次性全部切换，而是分了三个阶段。

第一阶段：并行测试（3个月）

先找了几款当时热门的国产模型：

测试流程大概是这样：

第二阶段：小流量灰度（2个月）

选定了两款主力和一款备用后，开始逐步切量。用了A/B测试的思路：

• 10%流量切到新模型
• 监控关键指标：响应时间、错误率、用户满意度
• 出问题随时切回GPT

这期间遇到的一个大坑：Prompt不兼容。同样的Prompt，GPT能正常工作，但国产模型经常理解偏。比如：

# GPT能理解
prompt = "帮我分析一下这个bug的原因，并给出解决方案"

# 国产模型理解不准确
# 改为
prompt = """
请按照以下步骤回答问题：
1. 分析bug的可能原因（至少3个）
2. 对每个原因给出判断依据
3. 给出推荐的解决方案及实施步骤

问题：xxx
"""

教训：国产模型更喜欢结构化的Prompt，需要把要求说得更明确。

第三阶段：全量切换（1个月）

灰度稳定后，开始全量切换。这阶段主要解决的是基础设施问题：

• 多模型适配层：封装统一的API接口，方便切换不同模型
• 熔断降级机制：某个模型出问题时自动切换
• 成本监控：实时监控各模型的调用量和成本

踩坑：那些意想不到的问题

坑一：上下文长度不一致

GPT-4是128K，但很多国产模型当时只有32K。我们的文档分析功能直接崩了。

解决方案：做了一个分片+摘要的两级架构

def long_document_analysis(text, model):
    # 第一层：分片摘要
    chunks = split_text(text, chunk_size=10000)
    summaries = []
    for chunk in chunks:
        summary = model.generate(
            prompt=f"摘要这段内容（200字以内）：{chunk}"
        )
        summaries.append(summary)

    # 第二层：综合分析
    combined_summary = "\n".join(summaries)
    final_analysis = model.generate(
        prompt=f"基于以下摘要，分析全文：{combined_summary}"
    )

    return final_analysis

坑二：Function Calling支持差异

GPT的Function Calling很成熟，但国产模型要么不支持，要么支持不完善。我们用的那个智能客服产品，需要调用CRM系统查询用户信息，直接被卡住了。

临时方案：用Prompt模拟Function Calling

def mock_function_calling(query, available_functions):
    functions_info = "\n".join([
        f"{f['name']}: {f['description']}" 
        for f in available_functions
    ])

    prompt = f"""
    用户问题：{query}

    可用工具：
    {functions_info}

    请判断需要调用哪个工具，返回JSON格式：
    {{"function": "工具名", "arguments": "参数"}}
    """

    response = model.generate(prompt)
    return json.loads(response)

注意：这个方案不稳定，后来有模型支持原生Function Calling后立刻换了。

坑三：API限流策略不同

GPT的限流是按Token算，国产模型有的按请求次数算，有的并发数限制很低。高峰期直接被打爆。

优化方案：

1. 做了请求队列，错峰调用
2. 增加了本地缓存层，重复问题直接命中缓存
3. 引入多模型，分散压力

结果：还满意吗？

数据对比

下图把响应时间、Token 成本和月度总支出放在同一视角下，便于评估迁移的综合收益。

响应时间和成本均下降约三分之一到一半，可用性小幅提升，用户满意度仅下降 2%，整体 trade-off 可接受。

结论：成本和性能有明显提升，用户满意度略有下降但可以接受。

意外收获

1. 数据不出境：客户对合规性更放心了，签了几家之前不敢接的国企客户
2. 中文能力增强：一些中文特有的场景，比如成语、网络用语，理解得比GPT好
3. 议价能力：现在有几家模型厂商在竞争，我们有了更多选择和议价空间

现在的架构

最终的架构大概是这个样子：

• 模型A：主力模型，处理80%的常规请求
• 模型B：专门处理技术类问题
• 模型C：长上下文模型
• GPT-4备用：兜底，保证关键时刻不掉链子

给你的一些建议

如果你也在考虑要不要迁移，这里有一些建议：

1. 不要盲目追求国产化

先搞清楚自己的需求。如果你的产品主要服务海外用户，或者核心场景GPT做得特别好，那就别硬换。

2. 分阶段、分场景迁移

不是所有场景都适合国产模型。我们的策略是：

• 对中文理解要求高的场景 → 优先国产模型
• 对逻辑推理要求高的场景 → 可以继续用GPT
• 边缘场景、低频场景 → 国产模型练手

3. 做好测试和监控

千万别一上来就全量切换。务必做好：

• A/B测试框架
• 实时监控大盘
• 快速回滚机制

4. 提前做好Prompt工程

国产模型和GPT在Prompt理解上有差异。提前做适配，能省很多时间。

5. 建立多模型能力

不要把鸡蛋放在一个篮子里。我们有3个主力模型 + 1个备用，这样才有抗风险能力。

结语

写了这么多，其实想表达的就一个意思：国产模型已经能干活了，虽然还有差距，但差距在缩小。

对我们这样的创业团队来说，最重要的是：选择权回到了自己手里。不用再看别人的脸色，也不用担心哪天服务被掐断。这种踏实感，是技术带来的，也是我们自主可控能力的体现。

当然，这不是终点。模型在快速迭代，今天的差距可能明天就没了。关键是要保持学习、保持尝试，找到最适合自己团队的方案。

如果你也在做类似的迁移，欢迎交流踩过的坑和经验。毕竟，国产模型这条路，我们都是刚开始走。

写于 2026年7月17日，深圳。

版权声明: 本文首发于 指尖魔法屋-从依赖走到自主：AI中文大模型笔记（https://blog.thinkmoon.cn/post/416-ai-chinese-llm-dependency-autonomous-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！