先从一个有意思的现象聊起身边不少做 AI 应用的朋友最近聊着聊着都会蹦出一句“现在 AI 智能桶是真便宜价格战都快把成本打成白菜价了”。这里说的“桶”其实就是大模型 API 计费的基本单位 token——因为 token 的发音和“桶”相近加上群里聊天打字一快大家索性就叫它“智能桶”。围绕这个“桶”展开的价格战从早期动辄 26 美元级别每百万 token一路拼到如今 0.5 美元级别跨度之大让不少做 AI 产品的人既兴奋又困惑为什么会降得这么快对开发者和技术团队来说这到底意味着什么本文不打算写行业分析稿而是从工程视角拆解这个大话题帮大家理解 token 计价方式、价格变低的底层原因以及技术团队如何借势降本。文章会先讲清楚 token 和计费相关的核心概念再深入分析价格战背后的技术驱动因素然后给出成本量化测算、多模型选型与降本工程方案最后附上常见的坑和最佳实践。无论你是刚接触大模型 API 的新手还是已经在做 AI 应用落地的后端开发这篇文章都会给你一套能直接参考的思考框架和 Python 示例代码。1. 背景与核心概念1.1 “智能桶”到底是什么要理解价格战首先要理解计费单位。大模型在处理文本时并不是按“字数”来理解的而是会把输入文本切分成一个个 token。token 可以粗略理解为“词元”它可能是一个完整的单词、一个汉字、一个标点也可能是一个被切分出来的子词单元。不同模型的 tokenizer分词器不同切分规则也不一样。举个例子英文句子 “Hello, world!” 可能被切分成[Hello, ,, world, !]而中文句子“你好世界”在多数中文友好的模型中通常会按字或按词切分成[你, 好, , 世, 界]。大模型计费时输入 token 和输出 token 分别计价每一次 API 调用的费用就是两者费用之和。这里“智能桶”的叫法虽然带点调侃但很生动模型每次处理请求就像一个水桶在“装”token装的量越大、单价越贵成本就越高。价格战打的正是“每桶单价”。1.2 大模型 API 的价格构成大模型 API 的定价通常包含两部分计费项说明典型计价方式输入 token用户发送给模型的提示词内容每百万 token 多少美元或人民币输出 token模型生成回复的内容每百万 token 多少美元或人民币不同模型、不同厂商、不同版本的输入输出价格差异很大。一般来说输出 token 的价格会明显高于输入 token 的价格因为生成过程的计算量更大。此外上下文长度、是否是长上下文版本、是否启用推理增强功能也会影响最终价格。有些平台还提供“批量接口”允许开发者提交一批非实时请求以更低折扣执行适合离线任务。1.3 价格战引发的连锁效应价格下降绝不只是“省了钱”这么简单。当每百万 token 的价格从 26 美元级别降到 0.5 美元级别开发者能够承受的调用量和产品形态会发生质变。过去不敢做的功能现在可以做了全量文档问答不用再费尽心思做复杂的摘要压缩直接把文档分段喂给模型。多轮对话深度推理可以在一次任务中多次调用模型让模型逐步分析问题。批量数据处理把积压的历史文本全部跑一遍模型用于分类、打标、抽取。Agent 思路落地agent 需要模型多次自我观察、规划、调用工具单次任务成本一高就没法商用降价后这条路才真正走通。所以价格战表面上是一场“价格拼杀”本质上是在给上层应用创新松绑。2. 价格战背后的技术驱动因素2.1 模型架构与训练效率提升大模型价格下降的第一推动力是模型本身变强了。同样的效果原来需要几千亿参数的模型才能实现现在通过更好的架构设计、数据配比、训练策略几百亿参数的模型就能达到接近的水平。参数量下降推理时的计算量自然减少单位成本随之降低。近年来很多厂商在注意力机制、激活函数、稀疏专家模型等方面做了大量优化这些改进一方面提升了模型效果另一方面显著压低了推理成本。2.2 推理引擎与部署优化模型训练只是第一步真正让价格降下来的是推理环节的工程优化。这里涉及几个关键方向KV Cache 优化大模型生成时需要缓存历史 token 的 Key-Value 信息优化缓存策略可以减少重复计算和显存占用。连续批处理Continuous Batching把多个请求动态拼到一个批次里推理而不是等一个请求完全结束再处理下一个大幅提升 GPU 利用率。量化技术把模型权重从 FP16 压缩到 INT8 甚至 INT4在精度损失可控的前提下减少显存占用和计算量。投机采样Speculative Decoding用小模型先草拟若干 token再用大模型一次验证从而加速生成过程。这些技术在开源社区和云厂商的推动下越来越成熟。过去只有头部大厂玩得转的推理优化现在很多开源项目也能做到不错的效果比如 vLLM、SGLang 等项目已经成为部署领域的常用选择。2.3 开源模型与生态竞争开源模型在这轮价格战中扮演了重要角色。当某个团队把效果不错、可以本地部署、推理成本可控的开源模型放出来之后云厂商如果想继续在 API 市场保持竞争力就必须把自家付费 API 的价格压到接近甚至低于开源模型的部署成本线。于是我们看到了一个循环开源模型提供价格锚点云厂商跟进降价反过来又推动更多开发者尝试调 API规模上来之后再进一步摊薄基础设施成本。2.4 规模化带来的成本摊薄大模型 API 的边际成本有一个特点随着调用量增加单位成本会持续下降。原因在于 GPU 集群可以更充分地共享、推理引擎可以针对热门的模型结构做极致定制、电力与带宽采购也能拿到更优价格。这种规模效应在头部厂商那里尤其明显。价格战中的低价不只是“烧钱换市场”背后其实有实打实的成本结构变化。3. 计费口径与成本量化3.1 先算清一次调用到底花多少钱避免“看起来便宜用起来肉疼”的最好方式是动手写一个成本估算工具。这样你就可以在调用任何 API 之前先快速估算一次业务请求大概会花多少钱。下面我们用 Python 写一个简单的成本估算脚本。请先确认本地环境操作系统Windows / macOS / Linux 均可。Python 版本建议 3.9 及以上。依赖不需要安装第三方库使用标准库即可。# 文件路径cost_estimator.py # 用途根据输入/输出 token 数量和单价估算一次 API 调用的成本 def estimate_cost( input_tokens: int, output_tokens: int, input_price_per_million: float, output_price_per_million: float, currency: str USD, ) - float: 估算单次调用成本 :param input_tokens: 输入 token 数 :param output_tokens: 输出 token 数 :param input_price_per_million: 每百万输入 token 价格 :param output_price_per_million: 每百万输出 token 价格 :param currency: 币种符号 :return: 单次调用成本 cost ( input_tokens / 1_000_000 * input_price_per_million output_tokens / 1_000_000 * output_price_per_million ) return round(cost, 8) if __name__ __main__: # 示例某个模型输入价格 0.5 美元/百万 token输出价格 1.5 美元/百万 token price estimate_cost( input_tokens2000, output_tokens800, input_price_per_million0.5, output_price_per_million1.5, ) print(f单次调用成本{price} 美元)运行结果如下单次调用成本0.0022 美元也就是说如果有一天你的应用需要每天调用 10 万次这种规模的请求按这个价格算一天的成本大约是 220 美元。看起来每次调用很便宜但规模一上来成本立刻变得可观。这里的关键是每次调用之前先想清楚业务需要的输入长度和输出长度。3.2 把 token 数估算落到业务里去看到这里你可能会有疑问我在写代码的时候怎么知道一段文本有多少 token你可以使用模型对应的 tokenizer 库来统计也可以在请求之前根据业务经验做近似估算。常见的经验法则是英文文本1 个 token 大约对应 3.5 到 4 个字符。中文文本1 个汉字大约对应 1 到 1.5 个 token不同模型差异较大。如果你只是做初步成本评估可以用下面的简化函数# 文件路径token_approx.py # 用途粗略估算文本 token 数 def approx_tokens(text: str, language: str zh) - int: 粗略估算 token 数 :param text: 输入文本 :param language: zh 或 en :return: 预估 token 数 if language zh: # 中文场景按 1 个汉字约 1.2 个 token 估算 return int(len(text) * 1.2) # 英文场景按 1 个 token 约 3.8 个字符估算 return int(len(text) / 3.8) if __name__ __main__: text 欢迎阅读 CSDN 技术博客本文讲解大模型 token 成本优化。 print(approx_tokens(text))需要注意这只是一个工程估算值真实 token 数以模型 tokenizer 统计为准。但在做技术选型决策时这种粗粒度估算已经足够帮你判断成本量级。3.3 不同模型的价格对比思路不要直接照搬别人文章里的价格表做选型决策。原因很简单API 价格变动频繁各家计价规则也越来越复杂。有的按输入输出分别计价有的提供包月套餐有的在夜间或低峰期打折还有的按 Batch 接口单独计价。更稳妥的做法是建立一个自己的“模型成本对比表”把应用中可能用到的模型罗列出来分别记录输入价格、输出价格、上下文长度、限流策略、响应速度、效果评分然后结合真实业务请求占比计算加权成本。模型输入价格美元/百万 token输出价格美元/百万 token上下文长度适用场景轻量模型较低较低较短分类、抽取、关键词生成均衡模型中等中等中长通用对话、内容生成高端模型较高较高长复杂推理、代码生成这里不建议写死具体模型名和价格因为市场变化太快。关键是掌握这套对比思路上官网查最新价格填入自己的表格再算综合成本。4. 工程降本方案从单价思维到总成本思维4.1 模型分级不是所有任务都用最强模型技术团队最容易犯的错是让所有请求都走同一个“最强模型”。可实际情况是很多任务压根不需要顶级推理能力。举个真实例子一个用户提问“订单状态怎么查”这种简单问答用轻量模型就能很好完成另一个用户提问“请根据这三份财务报表分析公司现金流风险”这种高难度推理才需要调用最强模型。分级策略可以这样设计第一级规则匹配或小模型即可处理的固定问答。第二级轻量模型负责意图识别、实体抽取、简单对话。第三级均衡模型负责多数通用内容生成。第四级高端模型只在复杂推理、长文档深层问答、代码生成等场景启用。实现时可以在请求入口处加一个 Router根据任务类型、提示词长度、业务方传入的难度标记动态选择模型。4.2 响应缓存让重复请求不再花钱在 AI 应用里很多请求其实非常相似甚至完全一样。比如用户连续刷新页面导致同一个问题被发送两次又比如不同用户查询同一份产品说明的特定段落。对这些重复请求做缓存能省下大量成本。下面给出一个基于磁盘缓存的简单示例核心思路是以提示词内容作为 key先查缓存命中就直接返回不调 API未命中再调 API然后把结果写入缓存。# 文件路径llm_cache.py # 用途基于本地 JSON 文件的轻量缓存示例 import hashlib import json import os CACHE_DIR ./llm_cache def _cache_path(key: str) - str: return os.path.join(CACHE_DIR, f{key}.json) def get_cache(prompt: str) - dict | None: key hashlib.sha256(prompt.encode(utf-8)).hexdigest() path _cache_path(key) if os.path.exists(path): with open(path, r, encodingutf-8) as f: return json.load(f) return None def set_cache(prompt: str, response: dict) - None: os.makedirs(CACHE_DIR, exist_okTrue) key hashlib.sha256(prompt.encode(utf-8)).hexdigest() path _cache_path(key) with open(path, w, encodingutf-8) as f: json.dump(response, f, ensure_asciiFalse, indent2) # 模拟一次业务调用 def call_llm_with_cache(prompt: str, mock_llm_func): cached get_cache(prompt) if cached: print(命中缓存直接返回结果) return cached response mock_llm_func(prompt) set_cache(prompt, response) print(未命中缓存已调用模型并写入缓存) return response def mock_llm(prompt: str) - dict: # 正常情况下这里会调用真实大模型 API return {answer: f这是对“{prompt}”的模拟回答} if __name__ __main__: p 如何重置密码 call_llm_with_cache(p, mock_llm) call_llm_with_cache(p, mock_llm)上面这个示例是纯文件缓存方便演示。在生产环境中更推荐用 Redis 等分布式缓存并设置合理的过期时间。缓存策略要注意缓存 key 不仅要包含用户提示词还要包含模型名称、参数配置避免不同配置之间串结果。对含敏感信息的内容缓存前要做脱敏处理或直接禁用缓存。缓存只适用于确定性较强的任务。如果你的业务需要模型每次都给出不同创意文案就不适合缓存。4.3 请求合并与批处理摊薄单价大模型的多个输入请求可以合并成一个请求让模型一次性处理多条数据。这种方式在语义上等价于多次单条调用但在部分平台上批量接口价格远低于实时接口。批处理适合以下场景离线文本分类。历史工单自动打标。文档摘要批量生成。数据清洗与信息抽取。如果你使用的平台不提供专门的 Batch API也可以自己在应用层把多个小任务拼进一个提示词里让模型按固定格式返回再由代码拆分结果。下面是一个简单示例# 文件路径batch_inference.py # 用途将多个分类任务合并为一次模型调用 import json tasks [ {id: 1, text: 这款手机续航表现如何}, {id: 2, text: 今天天气适合户外运动吗}, {id: 3, text: 帮我推荐一款适合程序员的机械键盘}, ] prompt 请对以下文本逐一分类分类只能是购物咨询、天气问答、产品推荐。输出 JSON 数组每项包含 id 和 category。\n\n for task in tasks: prompt f{task[id]}. {task[text]}\n print(合并后的 Prompt) print(prompt) # 假设这里调用模型得到如下结果 mock_result [ {id: 1, category: 购物咨询}, {id: 2, category: 天气问答}, {id: 3, category: 产品推荐}, ] print(模型返回结果) print(json.dumps(mock_result, ensure_asciiFalse, indent2))这种方式能显著减少请求次数但要注意提示词总长度仍然会计入输入 token任务数太多时反而可能更贵。所以合并任务之前要先粗略估算总 token 数确保合并带来的收益大于额外 token 消耗。4.4 多模型路由降本实战这里给一个完整的 Python 示例把前面几张思路综合起来实现一个最简单的多模型路由。# 文件路径model_router.py # 用途根据任务难度选择不同模型模拟不同模型的价格差异 class ModelRouter: def __init__(self): self.models { light: { name: light-model, input_price: 0.3, # 美元/百万 token output_price: 0.8, # 美元/百万 token }, balanced: { name: balanced-model, input_price: 1.0, output_price: 2.5, }, powerful: { name: powerful-model, input_price: 5.0, output_price: 15.0, }, } def route(self, task_type: str, prompt: str) - str: 根据任务类型选择一个模型 # 简单任务走轻量模型 if task_type in (simple_q_a, classification, keyword_extract): return self.models[light][name] # 中等长度内容生成走均衡模型 if task_type in (chat, content_generate, summary): return self.models[balanced][name] # 复杂推理、代码生成、长文档分析走高端模型 if task_type in (complex_reasoning, code_generate, long_doc_analysis): return self.models[powerful][name] # 默认走均衡模型 return self.models[balanced][name] def estimate_route_cost(self, task_type: str, input_tokens: int, output_tokens: int) - dict: 估算某个任务在对应模型上的成本 model_name self.route(task_type, ) config {m[name]: m for m in self.models.values()}[model_name] cost ( input_tokens / 1_000_000 * config[input_price] output_tokens / 1_000_000 * config[output_price] ) return { model: model_name, input_tokens: input_tokens, output_tokens: output_tokens, cost_usd: round(cost, 6), } if __name__ __main__: router ModelRouter() tasks [ (simple_q_a, 300, 50), (chat, 1200, 400), (complex_reasoning, 3000, 1200), ] for task_type, input_tok, output_tok in tasks: result router.estimate_route_cost(task_type, input_tok, output_tok) print(result)运行输出{model: light-model, input_tokens: 300, output_tokens: 50, cost_usd: 0.00013} {model: balanced-model, input_tokens: 1200, output_tokens: 400, cost_usd: 0.0022} {model: powerful-model, input_tokens: 3000, output_tokens: 1200, cost_usd: 0.033}这个示例把“模型分级 成本估算”融合到了一起。实际项目中你还需要接入真实 API在 route 函数中增加更多判断逻辑比如检查上下文长度是否超出模型限制以及判断是否需要启用流式输出。5. 多模型接入与切换策略5.1 为什么要做模型无关设计价格战最大的特点是变化快。今天你选定的低价模型可能三个月后就不再是最优选择今天的高价模型也许过段时间就降价了。因此代码层面一定要避免把某个厂商的 SDK 写死到业务逻辑里。推荐的做法是在所有业务代码和具体模型 SDK 之间加一层接口。业务代码只依赖接口底层切换模型时上层代码不需要大面积改动。# 文件路径llm_interface.py # 用途定义一个统一的 LLM 调用接口 from abc import ABC, abstractmethod class BaseLLM(ABC): abstractmethod def chat(self, messages: list[dict], temperature: float 0.7) - str: 统一聊天补全接口 messages 格式示例 [ {role: system, content: 你是一个智能助手}, {role: user, content: 你好} ] pass abstractmethod def count_tokens(self, text: str) - int: 统计文本 token 数 pass任何具体模型实现只需要继承这个基类并实现统一方法。切换模型时新增一个实现类然后通过工厂或配置中心选择具体实例。5.2 一个简单的工厂实现# 文件路径llm_factory.py # 用途通过工厂方法创建模型实例 from llm_interface import BaseLLM class MockLLM(BaseLLM): 模拟实现用于本地测试 def chat(self, messages: list[dict], temperature: float 0.7) - str: last_message messages[-1][content] return f模拟回答{last_message} def count_tokens(self, text: str) - int: # 模拟 token 统计 return len(text) class LLMFactory: _implementations { mock: MockLLM, } classmethod def register(cls, name: str, impl_class): cls._implementations[name] impl_class classmethod def create(cls, name: str) - BaseLLM: impl_class cls._implementations.get(name) if impl_class is None: raise ValueError(f不支持的模型实现: {name}) return impl_class() if __name__ __main__: llm LLMFactory.create(mock) result llm.chat( [{role: user, content: 请介绍大模型 API 成本优化思路}] ) print(result)这个设计的好处是当你决定切换模型时只需要新增一个实现类并在工厂中注册业务代码的调用方式完全不变。5.3 配置驱动的模型切换在真实项目中不建议把模型选择和价格参数硬编码在代码里。更合理的方式是通过环境变量或配置中心动态下发。# 文件路径config_demo.py # 用途通过环境变量配置默认模型 import os DEFAULT_MODEL os.getenv(DEFAULT_MODEL, balanced) API_BASE_URL os.getenv(API_BASE_URL, https://api.example.com) API_KEY os.getenv(API_KEY, ) print(f当前默认模型{DEFAULT_MODEL}) print(fAPI 地址{API_BASE_URL})这样运维人员可以在不发布新版本的情况下通过修改环境变量完成模型切换。如果你的团队已经在使用配置中心比如 Apollo、Nacos也可以把模型选择、价格参数、限流阈值统一放进去管理。6. 常见问题与排查思路6.1 API 调用超时问题现象常见原因解决思路请求长时间无响应网络链路问题检查网络尝试切换区域节点请求超时提示词过长或模型推理过慢缩短输入长度启用流式输出偶发超时服务端限流实现指数退避重试建议统一封装一个带超时和重试的调用函数。重试时要注意不是所有错误都适合重试比如鉴权失败、参数错误这类问题重试也没用而限流、超时这类临时性问题才适合重试。# 文件路径retry_demo.py # 用途带超时与重试的调用示例 import time def call_api_with_retry(func, max_retries: int 3, timeout: int 10): 简单的重试封装 for attempt in range(max_retries): try: return func(timeout) except TimeoutError: if attempt max_retries - 1: raise # 指数退避第一次等 1 秒第二次等 2 秒 time.sleep(2 ** attempt) except Exception as e: # 遇到不可重试异常直接抛出 raise e def mock_request(timeout: int): # 模拟一个偶尔超时的请求 import random if random.random() 0.5: raise TimeoutError(模拟超时) return success if __name__ __main__: try: result call_api_with_retry(mock_request) print(调用结果, result) except TimeoutError: print(多次重试后仍然超时)6.2 上下文长度超限问题现象常见原因解决思路报错提示超过上下文长度输入内容太大做文本截断、分段处理长文档回答遗漏内容分块策略不合理增加重叠片段或改用长上下文模型成本异常升高频繁拼接长历史做历史消息压缩与裁剪处理长文档时最简单的工程策略是“分块 摘要 检索”。不要试图把所有内容一次性塞进提示词而是先把文档切块用检索方式找到最相关的片段再把这些片段和用户问题一起发送给模型。6.3 token 统计不准问题现象常见原因解决思路预估 token 数与账单不符使用经验公式估算改用模型官方 tokenizer中英文混合文本误差大分词规则复杂以实际 tokenizer 统计为准同一个词不同模型计数不同不同模型分词器不同按具体模型分别统计如果你发现成本估算和实际账单差距较大第一件事就是检查 token 统计方式。不同模型的 tokenizer 差异很大同一个模型的不同版本也可能有差异。成本敏感的场景建议在服务端统一记录每次请求的 prompt_tokens 和 completion_tokens。6.4 长上下文场景下成本失控很多开发者看到长上下文模型很开心觉得什么都能塞进去。但长上下文的代价是你每一次多轮对话都会把历史记录重新计算一遍输入 token 会随着对话轮数不断累积成本直线上升。比较好的做法是对历史消息做滑动窗口裁剪。定期对历史对话做摘要下一轮对话只传摘要。判断用户问题是否需要历史信息不需要时只传当前问题。7. 最佳实践与工程建议7.1 建立可观测的成本监控很多团队在接入大模型 API 时只关注功能是否可用忽略了成本监控。等到月底账单出来才发现成本超支这时候再去优化已经有点晚了。建议在调用层统一埋点记录以下关键信息调用时间。模型名称。输入 token 数。输出 token 数。单次调用耗时。任务类型。业务方标识。把这些日志统一采集到监控系统里按天和按任务类型聚合才能清楚知道钱花在哪了。7.2 设计降级与熔断机制大模型 API 毕竟是外部依赖随时可能出现限流、故障或者新版本发布导致临时不可用。生产环境必须设计降级机制。建议按以下优先级做降级缓存兜底命中缓存直接返回历史结果。轻量模型兜底切到更便宜但可用的模型。固定话术兜底返回预设文案提示用户稍后重试。这样可以避免因为模型服务不可用导致整个业务链路直接崩溃。7.3 提示词工程也是降本手段提示词越长输入 token 越多。很多人习惯把一大堆背景说明、示例、约束条件堆在系统提示词里其中不少内容其实可以精简。提示词优化对成本的帮助非常直接假设你的系统提示词从 1000 token 压到 300 token每次请求的输入成本就省了 70%。如果每天调用量很大这是一笔非常可观的数字。当然提示词也不能为了省 token 而牺牲效果。比较好的做法是先写完整提示词保证效果再逐步精简通过自动化测试验证精简后的效果没有明显退化。7.4 关注模型更新节奏价格战环境下的模型版本迭代非常快。不要因为“之前用得好”就一直停留在旧版本。建议保持关注官方文档的更新定期用你自己的测试集重新评估最新模型判断是否值得切换。切换时注意新模型的 tokenizer 可能不同需要重新测试 token 数。新模型的行为可能变化需要有回归测试集。新模型的价格与限流策略可能不同要及时更新监控告警阈值。7.5 本地部署的权衡当 API 调用量非常大时本地部署开源模型可能比调用 API 更划算。但这需要考虑几个问题你需要有 GPU 资源或者可靠的云 GPU 租用渠道。你需要维护推理引擎解决并发、扩容、故障恢复等问题。你仍需要关注版本更新和数据标注质量问题。隐私敏感数据如果必须本地处理本地部署几乎是唯一选择。我的建议是先用量化工具算清楚 API 总成本和本地部署的 TCO总拥有成本再做决策。不要把本地部署看成天然更便宜的方案很多时候加上运维人力和 GPU 成本反而比 API 更贵。8. 总结与下一步学习路线从 26 美元到 0.5 美元这个大模型 API 价格变化的过程表面上是价格战实际上是模型算法、推理引擎、开源生态和规模效应共同作用的结果。对开发者来说真正的收获不是“终于用得起模型了”而是可以重新评估哪些 AI 应用形态现在值得尝试。本文核心要点可以归纳为这几条理解 token 计费原理先算清楚单次成本和总成本再动手。不要所有请求都走最强模型建立模型分级策略。缓存、批处理、请求合并是见效最快的降本手段。代码层面保持模型无关方便随时切换更划算的模型。生产环境必须考虑超时、限流、降级和成本监控。接下来如果你想继续深入建议按这个顺序学习熟悉主流大模型 API 的调用方式和参数差异掌握流式输出与批量接口。学习提示词工程优化系统提示词和上下文管理。学习 vLLM 或 SGLang 等开源推理引擎理解模型部署成本。掌握 Agent 应用中的多模型协作和任务路由设计。完善成本监控体系把 token 消耗和业务指标关联起来。工具和价格会不断变化但“成本意识 工程化思维 快速验证”这套方法不会过时。如果你也在做 AI 应用开发不妨先用文中的成本估算脚本跑一下自己的业务数据看看目前最大的成本黑洞在哪里然后针对性地做一轮优化。相信你会在下一份账单上看到变化。