Tomasz Tunguz 在 Theory Ventures 的博客里用一组很直白的数字解释了 AI 行业的成本结构：Anthropic 约 5000 名员工，2026 年模型推理和训练支出约 100 亿美元。摊到每个员工身上，就是每人每年约 200 万美元的算力成本。
这个数字刺眼，不是因为“人贵”，而是因为 AI 公司的核心成本已经从传统软件公司的工资、云服务器、销售费用，转向了训练和推理所需的 GPU、数据中心、电力与调度能力。对工程团队来说，这意味着一个现实变化：模型调用不再只是 API 账单，它正在变成产品毛利、组织扩张和融资节奏的硬约束。
200 万美元/人不是人力成本，而是组织密度指标
把 100 亿美元除以 5000 人，得到 200 万美元/人/年。这个算法很简单，但它揭示的是 AI 公司和 SaaS 公司之间的结构差异。
传统 SaaS 公司扩张时，新增员工通常带来更多研发、销售、交付或客户成功能力。云成本会增长，但多数情况下不会以“每招一个人，背后还要配一大块模型算力预算”的方式增长。
AI 基础模型公司不同。员工数量只是表面指标，真正重的是这些员工围绕模型迭代、训练实验、推理服务、评测、安全、客户集成所驱动的算力消耗。一个研究员提出的新训练方向，一个产品团队上线的新高频 agent 功能，一个企业客户的大规模调用，都可能把成本推到 GPU 集群和推理队列上。
所以“每人 200 万美元”更像一个组织密度指标：它衡量的不是员工个人消耗，而是一家公司围绕每个员工配置了多重的计算资本。
推理成本会把产品成功变成成本压力
训练成本容易被看见：大模型训练需要集群、长周期实验和昂贵硬件。更容易被低估的是推理成本。
当模型产品真正被使用时，每次对话、代码生成、文档分析、检索增强、agent 工具调用都会消耗 token、上下文窗口、缓存、向量检索和外部工具执行资源。产品越成功，推理成本越快从“研发费用”变成“收入成本”。
这和传统软件有一个明显区别：传统 SaaS 的边际服务成本通常较低，新增一个用户不一定显著增加基础设施压力。但 LLM 应用里，用户越活跃，模型调用越多；上下文越长，成本越高；agent 步骤越多，延迟和账单一起上升。
工程上要警惕几个常见坑：
- 把所有请求都打到最大模型，导致简单任务也按复杂任务计费。
- 默认保留超长上下文，让历史消息吞掉预算。
- agent 无限制循环调用工具，用户只看到“思考中”，账单已经增长。
- 缺少按客户、功能、模型、环境拆分的成本标签，月底只能看总账。
可以这样实践：把“每次请求毛利”算清楚
下面这个小脚本不是来源中的数据，而是一个可以落地的 FinOps 练习：把 LLM 产品的收入、token 成本、请求量和员工规模放在一起，快速估算单位经济模型。
把价格、token、请求量改成你自己的业务数据即可运行。
# llm_unit_economics.py
from dataclasses import dataclass
@dataclass
class ModelPrice:
input_per_million: float
output_per_million: float
@dataclass
class Usage:
monthly_requests: int
avg_input_tokens: int
avg_output_tokens: int
monthly_revenue: float
employees: int
annual_compute_budget: float
def monthly_inference_cost(price: ModelPrice, usage: Usage) -> float:
input_cost = (
usage.monthly_requests
* usage.avg_input_tokens
/ 1_000_000
* price.input_per_million
)
output_cost = (
usage.monthly_requests
* usage.avg_output_tokens
/ 1_000_000
* price.output_per_million
)
return input_cost + output_cost
def main():
# 示例价格是假设值。运行前请替换为你实际使用模型的价格。
price = ModelPrice(input_per_million=3.0, output_per_million=15.0)
usage = Usage(
monthly_requests=2_000_000,
avg_input_tokens=1_200,
avg_output_tokens=500,
monthly_revenue=250_000,
employees=40,
annual_compute_budget=3_000_000,
)
inference = monthly_inference_cost(price, usage)
gross_margin_after_inference = (usage.monthly_revenue - inference) / usage.monthly_revenue
compute_per_employee = usage.annual_compute_budget / usage.employees
print(f"Monthly inference cost: ${inference:,.0f}")
print(f"Gross margin after inference: {gross_margin_after_inference:.1%}")
print(f"Annual compute budget per employee: ${compute_per_employee:,.0f}")
if gross_margin_after_inference < 0.6:
print("Warning: inference cost is eating too much margin. Consider routing, caching, or pricing changes.")
if __name__ == "__main__":
main()
运行：
python llm_unit_economics.py
这个脚本刻意简单，但它能逼团队回答几个具体问题：
- 一个付费客户每月到底触发多少次模型调用？
- 平均输入和输出 token 是否被上下文膨胀拉高？
- 免费额度、试用用户、内部测试流量是否也算进成本？
- 当前定价是否覆盖推理成本，还是只覆盖了传统 SaaS 成本？
工程团队需要把模型路由做成基础设施
如果算力是核心成本，那么模型路由就不能只是业务代码里的 if else。它应该成为一层可观测、可配置、可回滚的基础设施。
可以这样实践：给不同任务分配不同模型，默认走便宜路径，只在需要时升级到更强模型。
# model-routing.yaml
routes:
summarize_short_text:
max_input_tokens: 4000
model: small-fast-model
cache_ttl_seconds: 86400
classify_ticket:
max_input_tokens: 2000
model: small-fast-model
cache_ttl_seconds: 3600
generate_code_patch:
max_input_tokens: 32000
model: frontier-model
require_user_plan: pro
max_tool_calls: 8
legal_contract_review:
max_input_tokens: 64000
model: frontier-model
require_audit_log: true
max_tool_calls: 4
budgets:
default_team_monthly_usd: 5000
alert_at_percent: 80
hard_stop_at_percent: 100
配套的服务端逻辑可以保持克制：读取配置、记录标签、超过预算就降级或拒绝。下面是一个最小化示例，展示思路而不是绑定某个厂商 API。
# router_demo.py
import yaml
from pathlib import Path
config = yaml.safe_load(Path("model-routing.yaml").read_text())
def choose_model(task: str, input_tokens: int, user_plan: str = "free") -> str:
route = config["routes"][task]
if input_tokens > route["max_input_tokens"]:
raise ValueError(f"Input too large for task {task}")
required_plan = route.get("require_user_plan")
if required_plan and user_plan != required_plan:
return "small-fast-model"
return route["model"]
print(choose_model("classify_ticket", input_tokens=800))
print(choose_model("generate_code_patch", input_tokens=12000, user_plan="free"))
print(choose_model("generate_code_patch", input_tokens=12000, user_plan="pro"))
运行前安装依赖：
python -m pip install pyyaml
python router_demo.py
真正上线时，还要补上这些能力：
- 按
customer_id、feature、model、environment打成本标签。 - 对 agent 设置最大步骤数、最大工具调用数和超时。
- 对重复输入做缓存，尤其是分类、摘要、结构化抽取。
- 对长上下文做裁剪、摘要或检索增强，不要无限拼历史消息。
- 把成本告警接到值班系统，而不是月底财务报表。
采用建议：不要只问“模型强不强”，要问“毛利剩多少”
Anthropic 这组数字给行业的提醒很直接：AI 公司不是简单地“软件公司加一个模型 API”。当训练和推理支出达到百亿美元级别，算力就是战略资源，也是产品约束。
对创业公司和企业内部 AI 团队来说，比较稳妥的做法是：
- 在功能设计阶段就估算 token、调用次数和缓存命中率。
- 把模型选择、上下文长度、agent 步数做成配置，而不是写死。
- 用小模型处理高频简单任务，把强模型留给高价值复杂任务。
- 每周看按功能拆分的推理成本，不只看总 API 账单。
- 定价时把推理成本放进毛利模型，不要等规模起来后再补。
AI 应用的竞争不只发生在模型能力上，也发生在成本曲线上。谁能用更少的 token、更稳的路由、更高的缓存命中率完成同样的任务，谁就能把产品成功转化为利润，而不是把增长直接烧进算力账单里。