先问一个问题：你的团队每个月为 LLM API 付多少钱？

很多做 AI 应用开发的公司，最近半年都卡在同一道坎上：模型调用量上去了，账单也上去了。尤其是从 GPT 系列接口起步的团队，API 费用几乎成了除人力之外最大的成本项。所以当“美国企业偷偷换上中国大模型”“便宜 90%”这类消息出现时，技术圈的关注点其实非常务实：国产大模型现在到底能不能平替？替换成本有多高？换了之后效果会掉多少？

这篇文章不讨论地缘话题，也不做情绪判断，只从工程师视角拆解整条迁移链路：国产大模型为什么能把成本压下来，主流模型怎么选，OpenAI 兼容 API 如何平滑切换，本地部署和云端 API 怎么测算成本，迁移过程中有哪些坑。读完你至少能回答三个问题：我的项目适不适合换？换了能省多少？怎么换才不翻车？

1. 背景：从“能用”到“用得起”的成本拐点

1.1 为什么“便宜 90%”会成为技术选型关键词

过去两年，大模型应用的落地路径基本是：先接 OpenAI 的 API 跑通原型，再根据账单和业务规模考虑要不要换成更便宜的方案。这套路径的问题在于，OpenAI 的闭源模型定价长期偏高，而且调用量越大，成本越不可控。一个日均十万次调用的中等规模应用，单月 API 费用轻松达到数万美元级别。对于创业团队和中小型出海企业来说，这是一笔很难忽视的开支。

国产大模型的定价策略则激进得多。以 DeepSeek、通义千问、智谱 GLM、Kimi 为代表的一批模型，在公开评测和实际业务测试中已经能逼近甚至追平闭源第一梯队，但 API 价格往往低一个数量级。再叠加开源权重可以自部署的因素，“便宜 90%”实际上不是一个夸张的广告词，而是成本结构改变后的真实结果。

1.2 这不是简单的价格战，而是技术路线竞争

很多开发者误以为国产大模型便宜是因为“能力不行，只能低价卖”。这个判断并不准确。便宜背后是几项关键工程创新叠加的结果：混合专家架构（MoE）降低了单次推理的计算量，注意力机制优化压缩了 KV Cache 的显存占用，开源推理引擎（vLLM、SGLang）把 GPU 利用率拉高了一大截。

换句话说，同样一张 GPU 卡，部署国产开源模型能服务的并发请求数更多，单次请求消耗的算力更少，成本自然降下来了。这是技术红利带来的结构性降价，而不是单纯的补贴烧钱。

2. 国产大模型为什么能把成本打下来

2.1 架构层面的关键创新：MoE 与注意力优化

先解释一个经常被混淆的概念：模型参数量不等于推理计算量。

传统的稠密模型（Dense Model）每次处理一个 token 时，所有参数都要参与计算。比如一个 70B 的模型，无论问题简单还是复杂，计算开销都是固定的。而混合专家架构（Mixture of Experts，MoE）把模型拆成多个“专家”子网络，每次输入只由路由网络激活其中一小部分专家。

以 DeepSeek-V3 为例，公开技术报告显示其总参数量达到 671B，但单次推理只激活约 37B 参数。这意味着在保持大模型知识容量的同时，实际计算量大幅下降。对于 API 服务商来说，计算成本直接决定定价底线；对于自部署团队来说，则意味着更低的显存需求和更高的并发能力。

注意力机制方面，MLA（Multi-head Latent Attention）通过低秩压缩的方式大幅减少 KV Cache 的显存占用。KV Cache 是推理过程中缓存历史 token 的键值向量，上下文越长占用的显存越多。MLA 把 KV 压缩到低维潜空间，使得长上下文场景下的显存压力显著降低，这也是很多国产模型敢把上下文长度做到 128K 甚至更长的原因之一。

2.2 训练与推理工程的系统级优化

模型架构只是第一步，真正把成本打下来的是工程能力。

训练阶段，FP8 混合精度训练、大规模分布式并行策略、CPU 与 GPU 混合调度等技术，大幅降低了训练集群的成本和时间。这一点对模型厂商很关键，因为训练成本最终会摊销到 API 价格里。

推理阶段，vLLM 的 PagedAttention、continuous batching（连续批处理）、投机解码（speculative decoding）等优化，让 GPU 利用率从闭源时代早期的百分之二三十提升到百分之七八十。国产开源模型可以直接接入这些推理引擎，不需要像闭源 API 那样承担平台运营和利润分成。

换句话说，选择国产开源模型 + 自部署，本质上是用工程能力换取成本弹性：算力紧张时买 API，算力充足时自部署，两条路都能走。

2.3 开源策略带来的生态成本优势

闭源模型按 token 收费，本质上是按“使用量”收租。开源模型则不同，权重可以下载，推理可以自己跑，增量请求的边际成本几乎为零。一个日调用量波动很大的业务，如果用闭源 API，高峰期要照单全付；如果用自部署开源模型，只需要按峰值预留 GPU 资源，或者混合使用按量付费的云 GPU，成本弹性完全不同。

美国企业愿意“偷偷换”中国大模型，除了价格因素，还有一个很容易被忽略的原因：开源权重允许模型部署在自己的云环境里，数据不需要发送给第三方。对数据敏感的企业来说，这一点有时候比价格更重要。

3. 主流国产大模型选型指南

3.1 通用对话与推理方向：DeepSeek 系列

DeepSeek 是讨论国产大模型时绕不开的名字。DeepSeek-V3 在通用任务、代码生成、数学推理等方向表现稳定，DeepSeek-R1 则专注于推理链（reasoning chain）生成，适合数学题、逻辑推断、复杂代码调试等场景。

使用上，DeepSeek 的 API 提供了 OpenAI 兼容接口，迁移成本低；开源权重也已经放出，可以在自有 GPU 环境部署。如果你需要的是一个“各方面都不偏科，且能自己做主”的通用底座，DeepSeek 是优先级很高的候选。

3.2 全能开源系列：通义千问 Qwen

通义千问 Qwen 系列是国内开源生态最完整的模型家族之一。Qwen2.5 系列覆盖 0.5B 到 72B 多个尺寸，配套有专门的 Coder（代码）和 Math（数学）版本。这意味着你可以按场景选模型，而不是“一个模型打天下”。

Qwen 系列在 Ollama、vLLM、HuggingFace 等生态中的适配度很高，社区资料多，踩坑容易找到解决方案。对于想从中小模型开始做本地部署验证的团队，Qwen 的尺寸梯度是最友好的。

3.3 长文本与 Agent 方向：Kimi 与 GLM

月之暗面的 Kimi 在长文本理解和处理上有自己的积累，后来开源的 Kimi K2 模型在 Agent 任务和工具调用上也有不错的表现。如果你的应用需要处理超长文档、多轮工具调用、复杂 Agent 链路，可以重点评估这一类模型。

智谱的 GLM 系列同样值得关注。GLM-4 系列在中文理解、内容生成、对话体验方面有自己的特色，API 服务稳定，教育、内容创作、智能客服类项目使用较多。

模型系列	能力特点	开源情况	适合场景
DeepSeek-V3 / R1	综合能力强，推理链突出	开源	通用对话、代码、数学推理
通义千问 Qwen2.5	尺寸完整，配套 Coder/Math	开源	全场景覆盖、本地部署
Kimi / Kimi K2	长文本、Agent 工具调用	部分开源	长文档、复杂 Agent
智谱 GLM-4	中文理解好，API 稳定	部分开源	客服、内容生成

3.4 选型建议：不要只盯着榜单

模型选型最容易犯的错误是只看公开榜单分数。实际业务环境里，提示词遵循度、函数调用成功率、输出格式稳定性、响应延迟、上下文窗口利用率，这些指标往往比基准测试分数更重要。

建议的做法是：先准备 200 到 500 条真实业务问题，形成评测集，覆盖正常请求、边界输入、对抗输入三类场景；然后在候选模型上离线跑一遍，记录正确率、失败率、平均延迟、平均输出 token 数；最后用“错误率 × 单价”来综合评估。价格低但错误率高的模型，实际成本往往更高。

4. 成本测算：把账算明白再迁移

4.1 云端 API 计费模型

大模型 API 的计费方式和传统接口不同，常见维度包括：

• 输入 token 价格：用户请求内容按 token 计费，通常低于输出价格。
• 输出 token 价格：模型生成内容的价格，通常是输入的 2 到 4 倍。
• 缓存命中价格：如果输入命中上下文缓存，价格会大幅降低，适合频繁调用相同系统提示词的场景。
• 上下文长度：部分服务商按输入长度阶梯计价，超长上下文更贵。

不同服务商的计费单位不同，有的按百万 token 计价，有的按千 token 计价。迁移前一定要把单位统一，否则比较价格时容易差三个数量级。

4.2 本地部署成本构成

本地部署不是“免费”的，成本结构变成了固定成本加运维成本：

• GPU 采购或云 GPU 租用费用。
• 服务器电费与机房托管费用。
• 推理引擎部署与调优的人力成本。
• 模型更新、安全补丁、监控告警的运维成本。

判断是否应该自部署，核心看两个指标：日均调用量和并发峰值。如果日均调用量低于几万次，自部署的 GPU 资源大概率是闲置的，买 API 反而更划算；如果日调用量达到百万级，自部署的边际成本优势才会真正体现。

4.3 用 Python 写一个成本测算脚本

下面这个脚本模拟了云 API 和自部署两种方案的月度成本，参数可以按实际价格替换。

# 文件路径: cost_estimation.py
def estimate_cloud_cost(
    daily_calls: int,
    input_tokens_per_call: int,
    output_tokens_per_call: int,
    input_price_per_million: float,
    output_price_per_million: float,
    cache_hit_rate: float = 0.0,
    cache_hit_price_per_million: float = 0.0,
    days: int = 30,
) -> dict:
    """估算云 API 月度成本。

    参数中的价格按‘每百万 token 多少钱’填写，
    具体数值请以各服务商官方定价页为准。
    """
    total_input = daily_calls * input_tokens_per_call * days
    total_output = daily_calls * output_tokens_per_call * days

    # 未命中缓存的输入
    normal_input = total_input * (1 - cache_hit_rate)
    # 命中缓存的输入
    cached_input = total_input * cache_hit_rate

    cost_input_normal = normal_input / 1_000_000 * input_price_per_million
    cost_input_cached = cached_input / 1_000_000 * cache_hit_price_per_million
    cost_output = total_output / 1_000_000 * output_price_per_million

    return {
        "monthly_input_tokens": total_input,
        "monthly_output_tokens": total_output,
        "monthly_cost_usd": round(
            cost_input_normal + cost_input_cached + cost_output, 2
        ),
    }


def estimate_selfhost_monthly_cost(
    gpu_rent: float,
    expected_daily_tokens: int,
    throughput_tokens_per_second: float,
    ops_labor: float = 0.0,
    days: int = 30,
) -> dict:
    """估算自部署 GPU 方案的成本。

    gpu_rent: 单张/单台 GPU 的月租或折旧费用。
    throughput_tokens_per_second: 单实例实际吞吐，需用压测数据填写。
    """
    monthly_seconds = days * 24 * 3600
    max_monthly_tokens = throughput_tokens_per_second * monthly_seconds
    usage_rate = min(1.0, expected_daily_tokens * days / max_monthly_tokens)
    cost = gpu_rent * usage_rate + ops_labor

    return {
        "estimated_usage_rate": round(usage_rate, 3),
        "monthly_cost_usd": round(cost, 2),
    }


if __name__ == "__main__":
    # 示例：某个客服场景，按实际价格替换
    cloud = estimate_cloud_cost(
        daily_calls=100000,
        input_tokens_per_call=600,
        output_tokens_per_call=150,
        input_price_per_million=0.5,    # 示例值
        output_price_per_million=1.5,   # 示例值
        cache_hit_rate=0.3,
        cache_hit_price_per_million=0.1,
    )
    print("云 API 方案:", cloud)

    local = estimate_selfhost_monthly_cost(
        gpu_rent=800.0,
        expected_daily_tokens=75000000,
        throughput_tokens_per_second=1500,
        ops_labor=200.0,
    )
    print("自部署方案:", local)

这个脚本不是精确报价工具，它的价值在于帮你建立测算框架。实际决策时，还需要加上网络带宽费用、对象存储费用、模型更新频率、版本兼容成本等隐性开销。

5. 平替迁移实战：OpenAI 兼容 API

5.1 兼容协议的底层逻辑

国产大模型 API 之所以能“平替”，最大功臣是 OpenAI 兼容协议。所谓 OpenAI 兼容，是指服务商对外开放的接口路径、请求格式、响应结构都模仿 OpenAI 的 /v1/chat/completions ，甚至直接用 OpenAI 的 SDK 也能调用。

这意味着你的业务代码不需要大规模重写，只需要修改客户端初始化参数： base_url 、 api_key 、 model 。下面演示一个最小迁移示例。

5.2 最小改造示例

先看原始 OpenAI 调用代码：

# 文件路径: llm_client.py
from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.openai.com/v1",
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "你是一名资深后端工程师。"},
        {"role": "user", "content": "请用一句话解释什么是 MoE。"},
    ],
    temperature=0.3,
)

print(resp.choices[0].message.content)

切换到国产模型服务商后：

# 文件路径: llm_client.py
from openai import OpenAI

# 以 DeepSeek 为例，其他服务商的 base_url 请查官方文档
client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "你是一名资深后端工程师。"},
        {"role": "user", "content": "请用一句话解释什么是 MoE。"},
    ],
    temperature=0.3,
)

print(resp.choices[0].message.content)

如果使用的是阿里云百炼平台，则把 base_url 换成：

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
    model="qwen-plus",
)

注意： base_url 是否带 /v1 后缀，不同服务商要求不同，以官方文档为准。最好的做法是把这些配置放进环境变量或配置中心，不要硬编码在代码里。

5.3 细节差异：不是改个 URL 就完事

虽然接口协议兼容，但模型行为有差异，迁移时容易踩到下面几个点。

模型名映射 ：不同服务商的模型名不一致，需要建立一层模型路由映射，避免把 gpt-4o-mini 这种名字散落在业务代码里。

温度参数范围 ：OpenAI 的 temperature 范围是 0 到 2，部分国产模型建议范围不同。比如 DeepSeek 官方建议代码/数学任务用 0.0，通用对话用 1.3，实际使用时要按模型文档调整。

max_tokens 与上下文窗口 ：不同模型对单次生成最大 token 数的限制不同，某些模型对消息总长度有隐性约束。迁移后建议做一次压力测试，确认超长上下文会不会触发截断。

输出格式稳定性 ：OpenAI 的 response_format={"type": "json_object"} 在很多国产模型上也有实现，但成功率未必一致。如果业务强依赖 JSON 输出，建议使用函数调用（function calling）而不是纯提示词约束，并在测试阶段统计 JSON 解析失败率。

下面是一个函数调用示例：

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.deepseek.com",
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称"}
                },
                "required": ["city"],
            },
        },
    }
]

resp = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
    tools=tools,
    tool_choice="auto",
)

print(resp.choices[0].message.tool_calls)

函数调用是 Agent 类应用的核心能力，迁移前务必在评测集里单独统计工具调用正确率，因为不同模型对工具描述的解析能力差异很大。

6. 本地部署实战：Ollama 与 vLLM

如果业务数据敏感，或者调用量达到一定规模，可以考虑本地部署开源模型。这里演示两条路线：Ollama 适合开发机快速验证，vLLM 适合生产环境。

6.1 Ollama 快速体验

Ollama 是目前最简单的本地模型运行工具，安装后几条命令就能跑起来。

# 安装完成后，拉取一个 7B 模型
ollama pull qwen2.5:7b

# 启动服务
ollama serve

启动后，Ollama 默认监听 http://localhost:11434 ，并且提供了 OpenAI 兼容接口。可以用 OpenAI SDK 直接调用：

from openai import OpenAI

client = OpenAI(
    api_key="ollama",  # Ollama 本地服务不校验 key，随意填
    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)

Ollama 的优点是零配置、上手快，适合在开发机上验证模型效果；缺点是并发能力和高级调度能力较弱，不适合高并发生产环境。

6.2 vLLM 生产级部署

vLLM 是当前生产环境最常用的开源推理引擎之一，支持 PagedAttention、continuous batching、量化模型加载等特性。以部署 Qwen2.5 7B 为例：

# 安装 vLLM（建议在 Python 3.10+ 环境）
pip install vllm

# 启动推理服务
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --served-model-name qwen2.5-7b \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9

启动后，服务默认提供 OpenAI 兼容接口：

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
)

resp = client.chat.completions.create(
    model="qwen2.5-7b",
    messages=[{"role": "user", "content": "用 Python 写一个快速排序。"}],
)

print(resp.choices[0].message.content)

--max-model-len 控制最大上下文长度， --gpu-memory-utilization 控制显存使用比例。这两个参数需要根据 GPU 显存和业务需求调整，设置过大容易 OOM，设置过小浪费资源。

6.3 硬件需求与量化方案

一个常见的困惑是：本地部署大模型到底需要什么配置？这取决于模型大小和量化方式。

先看显存估算。模型的权重显存大约等于参数量乘以每个参数占用的字节数：

• FP16/BF16 精度：每个参数约 2 字节。
• INT8 量化：每个参数约 1 字节。
• INT4 量化：每个参数约 0.5 到 0.6 字节。

以 7B 模型为例：

• FP16：约 14GB 权重，加上 KV Cache 和运行开销，建议 24GB 显存。
• INT4 量化：约 4GB 权重，8GB 显存也能跑。

对于 32B 及以上模型，FP16 权重就需要 64GB 以上显存，单卡基本跑不动，通常需要多卡并行或量化。常见量化格式包括 GGUF（Ollama 常用，支持 CPU 推理）、AWQ/GPTQ（GPU 推理效率高）、FP8（新兴格式）。

回到常见的“5600G + 32G 内存可以部署本地大模型吗”的问题。可以明确回答：能跑，但很吃力。5600G 属于核显 CPU 平台，没有独立 GPU 加速，只能靠 CPU 推理。32G 内存可以运行 INT4 量化后的 7B 模型，但生成速度往往只有每秒几到十几个 token，远达不到生产可用水平。适合用来学习、测试、跑 prompt 实验，不适合作为线上服务。

7. 迁移评估与灰度发布

7.1 离线评估：先跑分再切换

迁移之前，一定要有一份可量化的评估报告。建议包含以下几个维度：

评估维度	说明	通过标准
任务准确率	在业务评测集上的正确比例	与原模型差距在可接受范围
输出格式合规率	JSON/XML 等结构化输出解析成功率	建议 ≥ 99%
延迟	TTFT 和平均生成速度	符合业务 SLA
成本	每万次调用的综合费用	降幅达到预期
安全合规	敏感内容过滤、数据脱敏	符合企业安全规范

评测集建议包含历史线上请求的采样，尤其是之前出过 badcase 的样本，这样才能确认新模型在“补短板”上是否有效。

7.2 灰度切换策略

即使评估表现不错，也不要一次性切全量流量。推荐按功能模块灰度：

1. 选择流量占比小的低风险模块（如内部工具、后台辅助功能）先行切换。
2. 观察延迟、错误率、用户反馈、成本变化。
3. 稳定运行 3 到 7 天后，逐步扩大流量比例。
4. 如果异常率超过阈值，自动切回原模型。

灰度切换需要两个前提：一是代码层做了模型路由抽象，可以用配置中心动态切换模型；二是日志中记录了每次请求的模型标识，方便复盘。

7.3 回滚预案

回滚不是“把 base_url 改回去”那么简单。模型切换后，提示词和输出格式可能已经被新模型适配，直接回滚可能导致格式化问题。因此建议：

• 保留原模型的提示词版本，切换时使用配置管理，不要覆盖式修改。
• 新建一个 Prompt 兼容层，根据模型标识加载不同提示词。
• 对生产环境变更做好备份，遵循最小权限和测试验证原则。

8. 常见问题与排查思路

下面是迁移过程中最常见的几类问题，按现象、原因、解决思路整理。

问题现象	常见原因	解决思路
调用返回 401	base_url 或 api_key 与服务商不匹配	核对官方文档，检查环境变量
返回 model not found	模型名写错或该服务商不支持此模型	拉取服务商模型列表，建立映射层
响应内容被截断	max_tokens 设置过小	按模型上限调大 max_tokens
上下文超限报错	消息总长度超过模型窗口	做上下文裁剪或分段摘要
JSON 解析频繁失败	模型输出格式不稳定	改用函数调用或 response_format
生成速度明显变慢	本地部署显存不足或未启用量化	换小模型、量化、扩容 GPU
并发高时大量超时	推理引擎批处理能力不足或限流	接入 vLLM、调整并发参数、限流降级
迁移后 badcase 增加	提示词未适配新模型	重新设计提示词，扩大评测集迭代

排查这些问题的通用思路是：先看是不是配置层问题，再看是不是模型行为差异，最后看是不是工程链路问题。日志里一定要带上模型名、token 数、延迟、错误码，否则排查时只能靠猜。

9. 最佳实践与工程建议

9.1 设计模型路由与兼容层

不要把模型名、base_url 散落在业务代码里。建议建一个 ModelRouter ，统一管理模型标识、服务商配置、提示词版本和成本统计。这样将来从云端 API 切换到本地部署，或者从 A 模型切换到 B 模型，都只需要改配置。

9.2 密钥管理与安全边界

API Key 不要提交到代码仓库，使用环境变量或配置中心管理；定期轮换密钥；按环境区分生产与测试密钥。涉及生产环境变更时，遵循先测试、再灰度、后全量的原则，并保留操作审计记录。

9.3 数据合规与隐私约束

无论是云端调用还是本地部署，都要明确数据流向。如果业务涉及用户隐私、跨境传输或供应链合规，建议由法务与安全团队专项评估。技术侧能做的事情包括：对敏感字段脱敏后再调用模型、关闭日志中的明文输入输出、对模型提供方做安全准入审查。

9.4 成本治理：用缓存和分级打平账本

迁移完成后，成本治理不能停。三个常用手段：

• 上下文缓存 ：系统提示词和公共上下文尽量复用，利用缓存价格降低输入成本。
• 模型分级 ：简单任务用便宜的小模型，复杂任务才用大模型，而不是所有请求都走最大模型。
• 降级策略 ：模型不可用时降级到静态回复或更小的模型，避免 API 故障直接拖垮业务。

9.5 监控与告警

建议监控四个指标：请求成功率、平均延迟、token 消耗成本、badcase 率。前两个保障可用性，后两个保障成本和效果。建立成本周报机制，让每个业务方都看到模型改造前后的费用变化。

10. 总结与学习路线

回到开头的问题：国产大模型到底能不能平替？答案是“可以，但要靠工程手段平稳落地”。便宜的背后是 MoE 架构、注意力优化、开源推理引擎带来的结构性成本优势；平替的关键是 OpenAI 兼容协议带来的低迁移成本；而能不能长期稳定，取决于你是否有评测集、灰度机制和成本治理体系。

如果你现在正在做选型，建议按这个顺序推进：先搭评测集，再算成本账，然后做 API 平替验证，最后根据调用量决定是否本地部署。过程中重点关注三件事：输出格式稳定性、函数调用正确率、上下文长度限制。这三件事最容易在迁移后暴露问题。

下一步可以继续深入的方向包括：用 vLLM 做高并发推理调优、学习 GGUF/AWQ 等量化方案、研究模型微调来提升特定场景效果、搭建基于大模型的 Agent 应用。大模型技术更新很快，版本和价格都会变，关键是掌握一套可复用的评估和迁移方法论。

如果这篇文章对你有帮助，可以收藏备用，也欢迎在实际迁移中遇到问题时回来对照排查。动手跑一遍成本测算脚本，选一个模型做一次灰度切换，比读十篇选型文章都更有价值。