大模型基础概念

等级 L1 · 每天 30 分钟 · 场景:选模型→四、模型怎么选,控成本→五、成本是怎么算的

一句话：后端不需要懂 Transformer 内部结构，但必须懂 token、上下文窗口、幻觉、成本这四件事——因为它们直接决定你的接口会不会超时、会不会超预算、会不会给用户返回编造的答案。

学习地图

你遇到的问题	看哪一节
「这段文本算多少钱」	一、token / 五、成本
「为什么长文档喂不进去」「为什么聊着聊着它忘了前面」	二、上下文窗口
「它给的 API 根本不存在」	三、幻觉
「该用哪个模型」	四、模型怎么选
「账单为什么这么高」	五、成本是怎么算的

不讲的东西：Transformer 结构、注意力机制、训练流程。知道它是「根据上文预测下一个 token 的概率分布」就够用了——这一句解释了后面所有现象。

一、token：计费和限长的基本单位

模型不认字符，也不认单词，认的是 token——一段被切碎的文本单元。中文大致 1 个汉字 ≈ 1~~2 token，英文大致 1 个单词 ≈ 1~~1.5 token，代码因为符号多通常更费。

为什么后端必须懂这个：

计费按 token 算，不按字符也不按请求数
长度限制按 token 算，「这篇文档有多少字」和「能不能塞进去」不是一回事
输入和输出分开计价，输出通常贵 5 倍左右

不要用 tiktoken 估 Claude 的 token 数

这是最常见的踩坑。tiktoken 是 OpenAI 的分词器，用它估 Claude 的 token 数会低估约 15~20%，代码和非英文内容上偏得更多。成本预算按它算，上线就爆。

正确做法是调各家自己的计数接口。Claude 用 count_tokens：

from anthropic import Anthropic
 
client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-5",
    messages=[{"role": "user", "content": open("doc.md").read()}],
)
print(resp.input_tokens)

同一家的不同模型分词也可能不同——换模型后要重新测一遍，不能沿用旧数字，更不能套一个固定倍率。

二、上下文窗口：模型能「看见」多少

上下文窗口 = 一次请求里输入 + 输出加起来的 token 上限。

两个常被搞混的概念：

	是什么	典型值
上下文窗口	一次请求总共能装多少	1M（Claude Opus 5 / Sonnet 5）、200K（Haiku 4.5）
最大输出	单次回复最多能生成多少	128K（Opus 5 / Sonnet 5）、64K（Haiku 4.5）

上下文窗口大不等于能一次输出很长。长输出必须用流式——非流式请求在输出量大时会撞上 HTTP 超时，这是后端接 LLM 最先踩的坑之一。

模型没有记忆，会话是你自己维护的

API 是无状态的。所谓”多轮对话”，是你每次把完整历史重新发一遍。这意味着：

对话越长，每次请求越贵（历史是重复计费的输入）
历史撑爆窗口就会报错或被截断——这就是「聊着聊着它忘了前面」的真相
长会话要主动做压缩/摘要，或者用服务端的上下文管理能力

对后端来说这其实是好消息：无状态意味着可以水平扩，会话状态放 Redis 就行，跟你熟悉的那套一样。

三、幻觉：为什么它会一本正经地编

模型在做的事是「预测下一个 token 最可能是什么」，不是「查资料」。所以当它不知道时，不会说「我不知道」，而是生成一个看起来最合理的答案——编造的 API、不存在的配置项、语法正确但功能虚构的代码。

后端要记住三条：

越具体的事实越容易编：版本号、参数名、配置项、报错码——这些必须验证
越冷门的领域越容易编：小众框架、内部系统、新发布的东西
它不会主动示弱：编造的答案和真实的答案，语气上完全一样

怎么防

给上下文：把真实的文档、代码、报错贴进去，它就不用猜了（这也是 RAG 的核心动机）
要求引用：让它指出结论来自你给的哪一段
验证成本低的直接验：API 是否存在、配置项是否合法，跑一下比读十遍靠谱
要求它标注不确定：「不确定的地方明确说出来，不要猜」——有效，但不能全指望

不要靠「你确定吗」来验证——追问只会让它换一种说法，不会让它变得更准。

四、模型怎么选

同一家通常有三档，按能力/成本排：

档位	用来干什么	Claude 对应	参考价（输入/输出，每百万 token）
旗舰	复杂推理、长任务、Agent、难代码	Claude Opus 5	$5 /$ 25
均衡	日常绝大多数活	Claude Sonnet 5	$3 /$ 15
轻量	分类、抽取、格式化等简单高频任务	Claude Haiku 4.5	$1 /$ 5

价格与型号更新很快，上表是写作时的快照，以官方定价页为准。这里要记的是结构：三档、输出比输入贵约 5 倍、档位之间差几倍。

选型的实际做法

别一上来就选最贵的，也别为了省钱选最便宜的。 按任务分流：

分类、意图识别、格式转换、提取字段 → 轻量档就够，这类任务量大，省下来的是真金白银
写业务代码、做技术方案、多步推理 → 旗舰档，这里省钱等于降质量
其余 → 均衡档起步，跑不动再往上换

先用好模型跑通，再往下降级测——反过来（先用便宜的调半天效果不行）会浪费更多时间。

「思考」和 effort：新一代模型的成本旋钮

新模型普遍支持自适应思考：模型自己决定要不要多想、想多久。想的过程也计费，所以它是一个真实的成本变量。

配套的 effort 参数（低/中/高等档位）控制整体投入：简单任务调低省钱省延迟，难任务调高换质量。这是除了换模型之外最有效的成本旋钮，很多人不知道它的存在，一律用默认值。

五、成本是怎么算的

单次成本 = 输入 token × 输入单价 + 输出 token × 输出单价

看着简单，实际算的时候三个地方容易漏：

多轮对话的历史是重复计费的输入——第 10 轮请求要把前 9 轮全发一遍
系统提示词每次都发——一个 2000 token 的系统提示，调用一万次就是 2000 万 token
思考过程算输出——开了思考的请求，输出 token 会明显高于你看到的回复长度

Prompt caching：后端最该先上的优化

如果多次请求共享一段很长的前缀（系统提示、文档、few-shot 示例），可以把这段缓存住。命中缓存的部分按约 0.1 倍计价——便宜 90%。

代价是写缓存要付溢价（5 分钟有效期约 1.25 倍，1 小时约 2 倍），所以：

缓存有效期	写入溢价	几次请求回本
5 分钟	1.25×	2 次（1.25 + 0.1 < 2）
1 小时	2×	3 次（2 + 0.2 < 3）

关键限制：缓存是前缀匹配。 前缀里任何一个字节变了，后面全部失效。这直接决定了你的提示词怎么拼：

❌ 把 当前时间: 2026-08-05 14:23:01 拼进系统提示开头 —— 每次请求前缀都不同，缓存 100% 失效
❌ 把用户 ID、请求 ID 放在前面 —— 同上，而且不同用户之间无法共享
✅ 稳定的放前面，易变的放后面：固定系统提示 → 固定文档 → 变化的用户问题

这条规则和 CDN 缓存、HTTP 缓存的直觉完全一致——变化的内容不要污染稳定的前缀。

怎么确认缓存真的生效了

响应里会带用量字段。以 Claude 为例：

resp.usage.cache_read_input_tokens      # 命中缓存的 token（约 0.1 倍价）
resp.usage.cache_creation_input_tokens  # 写入缓存的 token（约 1.25 倍价）
resp.usage.input_tokens                 # 未命中、全价计费的部分

如果重复请求下 cache_read_input_tokens 一直是 0，说明有东西在悄悄破坏前缀——时间戳、随机 ID、没排序的 JSON 序列化、每次都变的工具列表，都是常见元凶。这是上线后第一个该加的监控。

常见追问

temperature 该设多少？ 传统答案是「要稳定设 0，要多样设高」。但要注意：部分新模型已经不接受采样参数了（传了直接报 400），改为用提示词和 effort 来控制。写代码前先确认目标模型支不支持，别照抄老教程。另外 temperature=0 从来就不保证输出完全一致，别把它当幂等开关用。
上下文窗口 1M 是不是就不用 RAG 了？ 不是。三个原因：贵（每次都塞满 1M 的输入成本极高）、慢（输入越长首字延迟越高）、准（相关信息淹没在无关内容里，效果反而下降）。窗口大降低了 RAG 的门槛，但没取消它的价值——该检索还是要检索，只是切块可以粗一些。
为什么同样的问题，两次回答不一样？ 生成本身带随机性。要稳定输出：用结构化输出约束格式、降低随机性参数（如果模型支持）、把要求写死在提示词里。但永远不要假设两次调用返回完全相同的字符串——解析逻辑必须容错。
本地部署的开源模型能替代吗？ 数据不能出内网时是唯一选择，成本上量大后也可能更划算。代价是：能力通常落后一代、要自己搞 GPU 和推理服务、要自己做扩缩容。先用商用 API 把需求验证通，确认价值再评估自建——反过来很容易在基建上耗掉几个月然后发现需求不成立。
token 能压缩吗？ 能，而且效果显著：删掉提示词里的客套话和冗余说明、长文档先摘要再送、多轮对话定期压缩历史、把不变的部分做成缓存前缀。先做 prompt caching——它通常是投入产出比最高的一步。

Interview Wiki

探索