2026 LLM云成本优化完整指南 (GPU+Token)

说真的，2026年的云账单已经变了样。生成式AI（GenAI）和大语言模型（LLM）几乎是一夜之间，从"创新预算"挪到了"主成本中心"。Gartner在2026年Q1的报告里讲得很直白：超过47%的企业表示其AI/ML相关云支出在过去12个月内翻了一倍，而这些钱里将近一半，都被"未优化的推理调用"和"闲置的GPU实例"吞掉了。

我自己经手的几个项目里，最夸张的一个团队，仅仅是把一个老的system prompt换了写法，再加上Prompt Caching，月度Token账单当月就掉了58%。所以这事真的值得认真盘一盘。

本指南聚焦在2026年的最新定价模型、新一代加速器（NVIDIA H200、B100、AWS Trainium2、Google TPU v5p、Azure Maia 100），以及主流托管服务（Amazon Bedrock、Azure OpenAI、Google Vertex AI），给出一套可立即落地的LLM云成本优化方法论。不是空谈理论，全是踩过坑之后留下的可执行步骤。

一、LLM云成本的四大支出维度

动手优化之前，得先把"AI成本"拆开来看。不拆开你就只会盯着总数发呆。LLM工作负载的支出通常分布在四个维度：

训练/微调成本：GPU/TPU实例小时费、分布式训练网络与存储开销。
推理成本：按Token或按调用计费的托管API，或自建GPU推理集群的实例费。
数据与检索成本：向量数据库（Pinecone、OpenSearch、pgvector）、特征存储、对象存储与跨区域流量。
辅助成本：监控、日志、Prompt版本管理、Guardrail/合规过滤等。

根据FinOps Foundation 2026年发布的《State of FinOps for AI》报告，推理成本在生产环境中通常占据LLM总账单的60%-75%。说白了，绝大多数公司的钱不是烧在训练上，是烧在"上线之后每天24小时不停跑"的推理上。所以本指南的绝大部分篇幅，都会落在推理优化。

二、GPU实例选型与定价对比（2026 Q2）

2026年初，AWS、Azure、GCP几乎是前后脚同时推出了新一代加速器实例。下表汇总了主流GPU/AI实例的按需价格（us-east-1或同等区域，2026年5月）：

主流加速器实例对比

云厂商	实例类型	加速器	显存	按需价（USD/小时）	3年RI/承诺折扣
AWS	p5e.48xlarge	8× H200	1128 GB	$84.50	≈55%
AWS	trn2.48xlarge	16× Trainium2	1536 GB	$32.10	≈40%
Azure	ND-H200 v5	8× H200	1128 GB	$88.20	≈52%
Azure	ND-Maia 100	8× Maia 100	768 GB	$36.40	≈45%
GCP	a4-highgpu-8g	8× B100	1280 GB	$91.60	≈50%
GCP	v5p-8 (TPU)	8× TPU v5p	768 GB HBM	$28.80	≈45%

选型上有几个我反复跟团队强调的原则：

训练长序列模型（128K+ context）：优先H200/B100，HBM3e带宽是H100的1.4倍，长上下文吃带宽，吃得很凶。
纯训练且模型结构相对受限可接受：Trainium2、TPU v5p性价比比H200高30%-45%。但要承担一次性的编译/适配成本，团队没人写过XLA的话，慎入。
推理优先选用L4/L40S或Inferentia2：A10G/L4在7B-13B模型上单Token成本，比H100便宜大概60%。把H200留给那些它真正值回票价的旗舰任务。

三、Token经济学：托管API的真实账单

不打算自建集群的团队，托管推理服务基本是首选。下表汇总2026年5月主流模型的Token定价（输入/输出，单位：USD/百万Token）：

平台	模型	输入	输出	批处理折扣	缓存命中价
Amazon Bedrock	Claude Opus 4.7	$15.00	$75.00	50% off	$1.50
Amazon Bedrock	Claude Sonnet 4.6	$3.00	$15.00	50% off	$0.30
Amazon Bedrock	Claude Haiku 4.5	$1.00	$5.00	50% off	$0.10
Azure OpenAI	GPT-5	$10.00	$30.00	50% off	$1.25
Vertex AI	Gemini 2.5 Pro	$2.50	$10.00	50% off	$0.30

3.1 模型路由：用Haiku/Flash承接简单请求

实战经验告诉我，生产环境中60%-80%的请求根本不需要旗舰模型。建个轻量分类器，把简单意图（FAQ、分类、抽取）路由到Haiku/Flash层，立即就能削掉50%-70%的Token账单。这一步几乎没有副作用，强烈建议第一周就做。

import anthropic

client = anthropic.Anthropic()

def route_and_answer(user_message: str) -> str:
    classifier = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=10,
        system="判断用户问题复杂度。仅输出 simple 或 complex。",
        messages=[{"role": "user", "content": user_message}],
    )
    complexity = classifier.content[0].text.strip().lower()

    model = (
        "claude-haiku-4-5-20251001"
        if "simple" in complexity
        else "claude-sonnet-4-6"
    )
    resp = client.messages.create(
        model=model,
        max_tokens=1024,
        messages=[{"role": "user", "content": user_message}],
    )
    return resp.content[0].text

3.2 Prompt Caching：把系统提示与RAG上下文缓存起来

2026年，所有主流平台都支持提示缓存，命中价格普遍低至原价的10%。对于带长system prompt（>2K Token）或大型RAG上下文的应用，启用缓存通常可以削减30%-90%的输入Token费用。

（提醒一句：缓存的key是"前缀完全一致"，所以system prompt里千万别加时间戳、随机ID这种每次都变的内容，否则命中率会直接归零。我见过不止一个团队因为这个细节，缓存功能开了等于没开。）

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT_8K_TOKENS,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": RAG_CONTEXT_20K_TOKENS,
                    "cache_control": {"type": "ephemeral"},
                },
                {"type": "text", "text": user_question},
            ],
        }
    ],
)
print(response.usage)

记得监控 cache_read_input_tokens 与 cache_creation_input_tokens。理想命中率应该在70%以上，达不到就回头查prompt模板。

3.3 批处理API：非实时任务一律走Batch

对于离线总结、嵌入生成、标注、数据清洗等非实时任务，使用Batch API直接拿50%折扣。AWS Bedrock、Azure OpenAI、Vertex AI都提供24小时SLA的批量端点。说真的，能等的任务就别让它实时跑，没必要。

import json, boto3

bedrock = boto3.client("bedrock")

records = [
    {"recordId": f"r{i}", "modelInput": {"messages": [{"role": "user", "content": q}]}}
    for i, q in enumerate(questions)
]
with open("input.jsonl", "w") as f:
    for r in records:
        f.write(json.dumps(r) + "\n")

bedrock.create_model_invocation_job(
    jobName="summarize-batch-20260511",
    modelId="anthropic.claude-sonnet-4-6",
    inputDataConfig={"s3InputDataConfig": {"s3Uri": "s3://my-bucket/input.jsonl"}},
    outputDataConfig={"s3OutputDataConfig": {"s3Uri": "s3://my-bucket/output/"}},
    roleArn="arn:aws:iam::123456789012:role/BedrockBatchRole",
)

四、自建推理集群的省钱套路

一个粗略但实用的判断标准：如果月度Token账单超过$30,000，自建推理集群通常能在6-9个月内回本。低于这个数，老实用托管API，TCO会更低。

4.1 推理引擎选型

vLLM 0.7+：PagedAttention + Speculative Decoding，吞吐量是HuggingFace TGI的2-3倍。是我个人的默认起点。
TensorRT-LLM 0.18：在NVIDIA实例上单卡吞吐最高，但调优复杂，没有专职AI infra工程师别碰。
SGLang：结构化输出与RadixAttention对Agent场景特别友好，函数调用密集型的工作流可以试试。

4.2 量化与蒸馏

FP8/INT4量化可以把显存占用降低4-8倍，让13B模型直接跑在L4单卡上，单Token成本下降60%-75%。Llama 3.3 70B在B100 + FP8下，每百万输出Token成本能压到$0.40以下——这个数字在两年前简直不敢想。

4.3 自动伸缩与冷启动

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama70b
spec:
  scaleTargetRef:
    name: vllm-deployment
  minReplicaCount: 0
  maxReplicaCount: 12
  cooldownPeriod: 180
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: vllm_pending_requests
      threshold: "4"
      query: sum(vllm:num_requests_waiting)

关键点：用一个预热Pod（保留1副本）避免冷启动80秒的模型加载灾难；同时把模型权重缓存到本地NVMe，别每次都从S3拉——这条踩过坑的人都懂。

4.4 Spot/Preemptible GPU

可中断的批量推理与离线生成，Spot GPU折扣高达70%-85%：

AWS EC2 Spot for p5e：节省约72%。
GCP Spot VM A4：节省约80%。
Azure Spot ND-H200：节省约75%。

配合Karpenter或GKE Autopilot的多实例池策略，Spot被回收的时候可以无感切换到On-Demand。但同步在线API还是要谨慎，下面FAQ会单独说。

五、向量数据库与RAG成本控制

向量数据库是RAG架构里最常被忽视的成本黑洞。很多团队把推理压下来之后才发现，账单里那个"OpenSearch"字段悄悄翻了一倍。2026年的主流报价大致是这样的：

方案	1亿向量(1536维)月度成本	P99延迟
Pinecone Serverless	$680	50ms
OpenSearch Serverless	$1,200	80ms
pgvector on RDS (db.r7g.4xl)	$1,050	120ms
Qdrant Cloud	$540	40ms
自建Qdrant + io2 EBS	$380	35ms

三条优化要点：

降维与量化：1536维 → 768维 + INT8量化，存储与查询成本下降60%，召回损失通常小于2%。投入产出比惊人。
分层存储：把30天前的低频向量从SSD迁到S3 Glacier IR，查询时按需加载。
缓存层：Redis缓存热门Query的Top-K结果，命中之后整个向量检索调用都省了。

六、FinOps监控：把AI成本纳入Showback

没有可观测性，就没有优化。这话有点老生常谈，但是真的——你不知道钱花在哪，谈何砍它。建议至少建立三层指标：

每请求成本：input_tokens × 单价 + output_tokens × 单价，按trace_id写入日志。
每团队/每功能成本：通过 X-Team-Id、X-Feature header或Bedrock Application Inference Profile打标签。
每业务价值成本：把AI成本和转化率、用户留存等业务指标关联，算出真实ROI。

from opentelemetry import trace
from opentelemetry.metrics import get_meter

meter = get_meter("llm.cost")
input_tokens_counter = meter.create_counter("llm.tokens.input")
output_tokens_counter = meter.create_counter("llm.tokens.output")
cost_counter = meter.create_counter("llm.cost.usd")

PRICING = {
    "claude-sonnet-4-6": {"in": 3.0/1e6, "out": 15.0/1e6},
    "claude-haiku-4-5-20251001": {"in": 1.0/1e6, "out": 5.0/1e6},
}

def record_usage(model: str, usage, team: str, feature: str):
    p = PRICING[model]
    cost = usage.input_tokens * p["in"] + usage.output_tokens * p["out"]
    attrs = {"model": model, "team": team, "feature": feature}
    input_tokens_counter.add(usage.input_tokens, attrs)
    output_tokens_counter.add(usage.output_tokens, attrs)
    cost_counter.add(cost, attrs)

把这些指标接到Grafana或Datadog，给每个功能配上月度预算告警（我一般在用量打到预算70%的时候就让PagerDuty叫醒owner，别等爆了才修）。

七、30天落地路线图

第1周：盘点所有LLM调用，按模型、团队、功能打标；接入Token级监控。
第2周：开启Prompt Caching；对长system prompt与RAG上下文按缓存命中率重排。
第3周：上线模型路由层；把简单意图迁到Haiku/Flash；非实时任务切换到Batch API。
第4周：评估是否启动自建推理集群；对向量数据库做量化与分层；设置FinOps预算告警。

按这个节奏推进，30天内把LLM云成本砍掉40%-65%是相当现实的目标，而且对业务指标几乎没有影响。我在三个不同行业的团队里都跑通过，模式可复用。

FAQ：常见问题

Q1：Bedrock、Azure OpenAI、Vertex AI该选哪个？

纯成本角度，Vertex AI的Gemini Flash在大多数场景下单价最低。Bedrock胜在模型多样性（同时拥有Anthropic、Meta、Mistral、Amazon Nova）和与AWS生态的深度集成。Azure OpenAI更适合已经重度使用GPT系列、且锁定Microsoft云的企业。我的建议是：至少接两家以避免厂商锁定，未来谈判的时候你也有筹码。

Q2：什么时候应该从托管API迁移到自建集群？

经验阈值是月度Token账单超过$30,000，并且流量相对稳定（峰谷比小于5:1）。如果流量波动剧烈、或者团队压根没有GPU运维能力，托管API的TCO通常仍然更划算——别为了省钱把团队拖死。

Q3：Prompt Caching真的能省90%吗？

能省90%是缓存命中部分的输入Token价格折扣，并不等于整体账单降90%。如果你的应用每次都改system prompt或RAG上下文，缓存几乎不起作用。理想场景是：固定system prompt + 半固定上下文 + 变化的用户问题，这种情况下整体输入Token成本能下降60%-80%，已经非常香了。

Q4：用Spot GPU做推理靠谱吗？

对于批量离线推理和异步任务非常靠谱，省下70%以上是日常操作。但面向用户的同步API我个人不建议直接放在Spot上——一次Spot回收就是一批失败请求。要用的话，至少配上On-Demand底座 + 多AZ多实例池 + 优雅降级策略。

Q5：如何把AI成本分摊到具体业务团队？

三层做法：(1) 在API网关层用header强制注入 team_id、feature_id；(2) 利用Bedrock Application Inference Profile或Azure OpenAI的Customer Managed Keys分租户；(3) 用OpenTelemetry把Token用量与成本作为指标导出，按标签在Grafana里做Showback仪表盘。做完这三步，财务和产品就再也不会问你"这个月钱是谁花的"了。