大模型API实战：从Token计费到上下文管理，看懂DeepSeek与GLM之争

最近 AI 圈流行一句话：“DeepSeek 又端大号碗筷还无限续杯，最后还把路过的 GLM 给撑死了。”我一开始看到也愣了一下，以为是某个段子手在玩抽象，后来把这句话拆开，和实际的大模型 API 调用经验放在一起对照，才发现段子里每一个词都能对应到真实的技术概念。

这句话表面上在调侃模型服务商竞争，实际上触及了几个很关键的技术点：长上下文、按 Token 计费、多轮会话管理、模型推理成本，以及国内大模型厂商之间的价格和服务博弈。本文就用这个梗当引子，把它翻译成一篇听得懂、能上手试的教程。读完你会明白“大号碗筷”到底是什么，“无限续杯”的成本在哪里，以及为什么网上会把 GLM 和“撑死”放在一起说。

1. 这句话到底在说什么：AI圈的“大碗饭”梗拆解

1.1 从用户视角理解这个段子

如果一个用户只看产品层面，这句话的意思其实很直接：DeepSeek 这个模型服务“给得多、不限制次数”，上下文窗口很大，用户能一直问下去，看起来就是“大碗筷、无限续杯”。

这里有个容易被忽略的细节：普通应用里“续杯”往往是按次数限制的，比如每天免费提问 50 次，超过就要付费或者等第二天。但大模型 API 的计费逻辑不太一样。它按 Token 计费，也就是按“处理了多少文本量”计费，不是按“问了多少轮”计费。只要你的额度足够、上下文长度没有超限，连续对话确实可以一直往后接，就像在一家不限时的餐厅里不断续杯。

所以“无限续杯”并不是一个完全虚构的说法。它的前提是 Token 预算管够。真正的问题是，这个“续杯”并不免费，而且随着对话轮数变多，每一轮要处理的 Token 数量会越来越大，费用会加速增长。这也是后面要重点展开的技术点。

1.2 技术视角下的“大号碗筷”

“大号碗筷”对应的技术名词是上下文窗口。上下文窗口决定了模型一次能“看到”多少文本。早期很多模型只能处理 4K 或者 8K Token，稍微长一点的文档就装不下。后来各家模型开始卷上下文长度，从 32K、64K 到 128K、256K，个别模型甚至开始宣传 1M Token 级别的能力。

DeepSeek 在较长一段时间里主推超长上下文能力，很多公开版本都能直接支持 128K 或更高。128K Token 是什么概念？中文文本一个汉字大约对应 1 到 2 个 Token，英文单词大约 1 到 1.5 个 Token。128K 的上下文窗口，已经可以一次性放入一整本几万字的小说，或者几十页的技术文档。对普通用户来说，这就很接近“大号碗筷”的直觉体验：你给它多少，它都能装下，起码在窗口范围内不轻易“溢出”。

1.3 为什么偏偏是 GLM“被撑死”

梗的末尾是“把路过的 GLM 给撑死了”。这里的 GLM 一般指智谱 AI 的 GLM 系列大模型，是国内用户规模和知名度都比较高的开源及 API 模型之一。

从技术竞争角度看，“被撑死”是一种戏谑说法。它不是指 GLM 真的停止服务，而是指在 DeepSeek 以低价、大上下文、开源权重等方式持续“上强度”之后，其他模型供应商会感受到明显的性价比压力。尤其在国内市场，模型能力接近的前提下，用户会用脚投票，哪家便宜、哪家开放、哪家上下文给得足，流量就会往哪边跑。

从公开报道来看，2024 年之后国内大模型市场确实出现过一轮明显的“API 价格战”，不少模型厂商都宣布过降价或推出免费模型。GLM 系列也做过多次价格调整。把这种行业现象包装成一个段子，就变成了“DeepSeek 不断续杯，GLM 被撑死了”。所以这句话的本质不是某个模型真的崩了，而是一场围绕成本、上下文和模型服务的激烈竞争。

2. 先把这几个概念弄清楚，再看段子就不晕了

2.1 Token 到底是什么

Token 是大模型处理文本的基本单位。简单理解，模型不是按“字”读文本，而是按“Token”切分文本。英文里一个词可能被切成一个或几个 Token，中文里一个汉字在多数分词器下可能对应 1 到 2 个 Token。

Token 决定了三件事：一次能处理多长文本、一次回答消耗多少资源、一次调用要付多少钱。如果把大模型比作餐厅，Token 就是菜品的计量单位。你点了一大桌菜，最后结账时不是按盘数算，而是按总重量或者总份量算。这也解释了为什么“无限续杯”只是看起来美好：每一轮对话新增的内容会持续消耗 Token。

2.2 上下文窗口与多轮对话的关系

上下文窗口决定了模型“记得”多少内容。你不论问多少轮，模型并不是天生记得你，而是每次请求时把之前的对话历史一起发过去。所以“记忆”的本质是“重新阅读”。

举个例子：

• 第 1 轮：你发 100 个 Token 的问题，模型回复 50 个 Token。
• 第 2 轮：请求里会带上第 1 轮的 150 个 Token，再加上新的问题。
• 第 10 轮：请求里可能会带有前 9 轮的所有内容，变成几千个 Token。

这就是“无限续杯”的代价。对话越往后，模型每次回复前需要阅读的东西越多，消耗越贵。如果不管上下文长度，最终会遇到两类问题：一是上下文超出模型窗口限制，报错；二是费用快速膨胀。后面会给出具体代码演示这一点。

2.3 开源模型、免费额度与低价 API

DeepSeek 在用户讨论中经常和“开源”绑定，很多版本都公开了模型权重，也提供了对外 API。开源意味着开发者和企业可以自己下载模型部署，不一定非要走云端 API，自由度更高。这也是“大号碗筷”的一部分：不仅官方给你“端饭”，你还可以把“厨房”搬回家自己开火。

GLM 系列同样有开源版本，也有云端 API。两家都属于国内用户最容易接触到的模型供应商。在聊天机器人、RAG、Agent、代码生成等场景里，经常被拿来对比。段子里说“GLM 被撑死”，更多是调侃它们在同一个赛道上正面竞争，而不是说某个模型能力差。

3. 为什么 DeepSeek 的“碗”能越端越大

3.1 MoE 架构降低单次推理成本

DeepSeek 之所以能长期给人“便宜量大”的印象，除了市场策略，还有一个重要原因是技术架构上的优化。最常被提到的是 MoE（Mixture of Experts，混合专家模型）。

MoE 的思路是：不把一个大模型的所有参数都用在每一次推理里，而是把网络拆成多个专家子网络。每次处理输入时，模型只激活其中一部分专家，而不是全部参数都参与计算。这有点像一家大型餐厅，菜单很厚，但你这次点餐只需要厨房里的几位厨师参与，不需要所有厨师同时动手。

这样就显著降低了每次请求的计算量。计算量降下来，单次推理成本就低，服务商才有底气把 API 价格定得更低，或者在相同成本下提供更长的上下文和更大的并发。

DeepSeek-V2 时期对外公开的技术报告中提到过 DeepSeekMoE、MLA（Multi-head Latent Attention）等结构设计，这些设计的目标之一是减少推理阶段的显存占用和计算开销。显存是关键资源，尤其在做长上下文时，保存中间状态会吃掉大量显存。MLA 这类优化相当于把“临时保存的调料”压缩了，让同一块显存能容纳更多内容，自然就能把“碗”做得更大。

3.2 长上下文里的显存压力

模型处理长文本时，并不是只看一遍就完事。Transformer 模型在生成过程中需要维护一个叫 KV Cache 的缓存结构，用来保存已经算过的历史信息，避免每生成一个新 Token 都要重新算一遍之前所有内容。

KV Cache 的大小和文本长度强相关。上下文越长，缓存越大，显存占用越高。如果服务商不做任何优化，长上下文能力会非常贵，普通用户根本用不起。所以一款模型能支持 128K 甚至更高上下文，背后一定做了不少工程优化，比如缓存压缩、注意力机制优化、显存管理优化、前缀缓存复用等。

一个重要概念是前缀缓存命中。如果大量用户请求的公共前缀相同，比如同一套提示词、同一个系统消息，服务商可以在缓存层复用这部分计算结果，后续请求就不再重复计算前面的内容，成本大幅下降。对用户来说，如果你反复使用同一套 instructions 或者同一份长文档前缀，费用可能会比第一次调用低很多。这也是实践里降低“续杯成本”的常用手段。

3.3 成本控制是“无限续杯”的底气

从服务商角度来说，只有把单次 Token 的成本压下来，才敢宣传“长上下文”“便宜”“大碗”。行业里的价格战并不是纯亏本赚吆喝，而是建立在每 Token 成本的持续下降之上。

模型蒸馏、模型量化、MoE 架构、推理加速框架、更合理的调度策略，都会影响最终成本。作为使用者，我们不需要完全懂底层细节，但必须知道一件事：模型服务的“便宜大碗”是有工程底座的，并不只是因为某家公司愿意烧钱。

4. “无限续杯”的现实约束：Token 成本与上下文管理

4.1 多轮对话的 Token 增长模型

“无限续杯”从产品体验上很好，但从工程实现上必须控制历史消息。假设每一轮用户输入平均 300 Token，模型回复平均 500 Token，那么：

• 第 1 轮请求的输入大约 300 Token。
• 第 2 轮请求的输入会发生什么？如果客户端把第 1 轮的输入和输出都追加进 messages，第 2 轮的输入就大约是 300 + 500 + 300 = 1100 Token。
• 第 3 轮可能就到 1900 Token。
• 第 10 轮可能已经接近一万 Token。

也就是说，Input Token 会随轮次线性增长。如果不做任何处理，到了第 50 轮、第 100 轮，请求体积会变得非常夸张。用 API 时，输入和输出往往分别按不同价格计费，频繁长对话会让账单增长得很快。

4.2 上下文超限是最常见的“续杯翻车”现场

绝大多数模型都有最大上下文限制。当你累积的对话历史超过这个限制时，服务端会返回类似“maximum context length exceeded”的错误。这个错误在长对话场景里非常常见，不是你的代码写错了，而是 messages 已经超过了模型能接受的范围。

解决办法大致有四类：

• 裁剪历史：只保留最近 N 轮消息，丢弃过旧内容。
• 摘要历史：用一个模型把旧对话压缩成总结，再作为系统消息带入后续请求。
• 滑动窗口：每次只送最近一轮或最近几轮上下文。
• RAG：把长文档先切片检索，只把相关片段放进提示词，而不是一股脑全塞进去。

在实际项目里，这几种方法经常组合使用。比如每轮对话后保存完整记录，但每次调用模型时只截取最近 3000 Token，再加上一个由历史对话生成的摘要，兼顾记忆和成本。

4.3 “续杯”策略的选择

不同业务需要不同的“续杯”策略。

• 闲聊机器人：保留最近 10 到 20 轮即可，太老的历史价值很低。
• 客服工单系统：需要保留完整会话，但可以只让模型看关键信息，比如客户诉求、处理结果、备注。
• 长文档分析：不应该把整个文档都塞进对话历史，更好的做法是先用 RAG 检索，再让模型基于检索结果回答。
• Agent 场景：工具调用记录会迅速膨胀，最好在每轮调用结束后只保留工具结果的核心字段。

一句话总结：续杯可以，但不能无脑续。上下文管理是长对话应用的核心工程问题。

5. 实战：用 OpenAI 兼容接口同时体验 DeepSeek 和 GLM

5.1 准备环境

DeepSeek 和 GLM 的对外 API 都提供 OpenAI 兼容格式。这意味着你不需要学习两套完全不同 SDK，可以直接使用 openai Python 包，通过不同的 base_url 和 API Key 访问不同模型。这是目前国内很多模型厂商都采取的做法，降低了开发迁移成本。

建议环境：

• Python 3.9 及以上版本。
• 安装 openai 库，版本建议使用较新的 1.x，本文代码按 1.x 写法演示。
• 准备 DeepSeek API Key 和智谱 GLM API Key。

执行安装：

pip install openai

如果还没有 API Key，可以在对应平台的控制台创建。注意不要硬编码到代码里，建议通过环境变量注入。

创建项目目录：

mkdir llm-compat-demo cd llm-compat-demo touch demo.py

5.2 调用 DeepSeek 模型

以 DeepSeek 为例，OpenAI 兼容调用代码如下。这里将 API Key 放在环境变量 DEEPSEEK_API_KEY 中。

# 文件路径：llm-compat-demo/deepseek_demo.py import os from openai import OpenAI client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) def chat(model: str, messages: list): resp = client.chat.completions.create( model=model, messages=messages, temperature=0.7, max_tokens=1024 ) return resp if __name__ == "__main__": messages = [ {"role": "system", "content": "你是一个技术助手，回答尽量简洁。"}, {"role": "user", "content": "请用三句话解释什么是上下文窗口。"} ] resp = chat("deepseek-chat", messages) print(resp.choices[0].message.content)

说明几点：

• base_url 是官方提供的接口地址，具体以 DeepSeek 最新文档为准。
• model 参数中的 deepseek-chat 是当前常见的通用对话模型名，不同时期的可用模型名可能不同，建议通过官方文档确认。
• max_tokens 控制本次输出最大 Token 数。如果设置太短，回答可能被截断。

运行前设置环境变量：

export DEEPSEEK_API_KEY="你的-api-key" python deepseek_demo.py

如果 Key 无效，会返回 401 错误；如果余额不足或并发超限，会返回 429 或类似错误。

5.3 使用同一个 SDK 调用 GLM

智谱 GLM 的接口同样兼容 OpenAI 格式。你可以把上面的代码稍作修改，换成对应的 Key 和 base_url。

# 文件路径：llm-compat-demo/glm_demo.py import os from openai import OpenAI client = OpenAI( api_key=os.getenv("ZHIPU_API_KEY"), base_url="https://open.bigmodel.cn/api/paas/v4" ) def chat(model: str, messages: list): resp = client.chat.completions.create( model=model, messages=messages, temperature=0.7, max_tokens=1024 ) return resp if __name__ == "__main__": messages = [ {"role": "system", "content": "你是一个技术助手，回答尽量简洁。"}, {"role": "user", "content": "请用三句话解释什么是 Agent。"} ] # 请按当前可用的模型名替换 resp = chat("glm-4-air", messages) print(resp.choices[0].message.content)

需要注意，GLM 的可用模型名比较多，不同时间点开放的模型也不一样。如果你看到 Model Not Exist 之类的错误，不要纠结于示例里的模型名，直接去官方文档查最新的模型 ID。

5.4 算账：统计每一次调用的 Token 成本

要真正理解“续杯”的成本，不能只盯着回答内容，还要看 usage 字段。OpenAI 兼容接口通常返回 prompt_tokens 和 completion_tokens，分别表示本次请求里输入和输出消耗的 Token 数。

下面写一个简单的成本估算函数，费用单价由你手动传入。这是因为不同模型、不同时段、不同套餐的单价都可能变化，写死价格很容易误导读者。

# 文件路径：llm-compat-demo/cost_estimate.py def estimate_cost( prompt_tokens: int, completion_tokens: int, prompt_price_per_million: float, completion_price_per_million: float ) -> float: """ 输入 token 数和单价，估算一次调用的费用。 单价单位为：元 / 百万 tokens。 """ cost = ( prompt_tokens / 1_000_000 * prompt_price_per_million + completion_tokens / 1_000_000 * completion_price_per_million ) return round(cost, 6) if __name__ == "__main__": # 这里的单价只是示例，请替换成当前实际价格 prompt_tokens = 4821 completion_tokens = 327 prompt_price = 1.0 completion_price = 2.0 cost = estimate_cost(prompt_tokens, completion_tokens, prompt_price, completion_price) print(f"本次调用估算费用：{cost} 元")

这个函数看起来很简单，但它是成本管理的基础。真实项目里可以把每次调用的 usage 记录到日志、数据库或监控系统，定时统计每个用户、每个场景、每个模型的费用。

5.5 实战多轮对话：直观感受“续杯”

下面这个脚本模拟一个无限问答循环。它会记录每一次请求消耗的 Prompt Tokens，并演示在上下文过长时裁剪历史消息，避免触发上下文超限。

# 文件路径：llm-compat-demo/multi_turn_demo.py import os from openai import OpenAI client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) messages = [] model = "deepseek-chat" max_prompt_tokens = 12000 print("开始多轮对话，输入 exit 退出。") while True: user_input = input("\n你> ") if user_input.strip().lower() in ("exit", "quit"): break messages.append({"role": "user", "content": user_input}) resp = client.chat.completions.create( model=model, messages=messages, temperature=0.7, max_tokens=1024 ) answer = resp.choices[0].message.content print(f"AI> {answer}") messages.append({"role": "assistant", "content": answer}) prompt_tokens = resp.usage.prompt_tokens completion_tokens = resp.usage.completion_tokens print(f"[统计] 本次输入 tokens={prompt_tokens}, 本次输出 tokens={completion_tokens}") if prompt_tokens > max_prompt_tokens: # 裁剪历史：只保留最近 6 条消息，避免上下文超限 messages = messages[-6:] print("[提醒] 上下文超过阈值，已裁剪历史消息")

运行之后，你会看到 prompt_tokens 大多数情况下会随着轮次增加而增长。当它超过设置的阈值时，脚本会裁掉最早的消息，从而把上下文控制在一个安全范围。

这个例子已经足够说明问题：产品体验上是“无限续杯”，但 API 逻辑里是一杯一杯现做的，每一杯都要算钱。所以工程上必须自己管理杯子大小。

5.6 多模型路由：避免某一个模型被“撑死”

段子里说“GLM 被撑死”，但在真实系统里，把所有流量压到任何一个单一模型上都非常危险。更稳妥的做法是做一个模型路由层，根据任务类型、成本预算、模型状态自动选择调用哪个模型。

下面是一个简化版路由示例，只演示思路，不代表生产级实现。生产环境里还要结合健康检查、超时重试、熔断、负载均衡、预算控制等机制。

# 文件路径：llm-compat-demo/router_demo.py import os from openai import OpenAI def get_client(provider: str): if provider == "deepseek": return OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) if provider == "glm": return OpenAI( api_key=os.getenv("ZHIPU_API_KEY"), base_url="https://open.bigmodel.cn/api/paas/v4" ) raise ValueError(f"不支持的 provider: {provider}") def route_query(query: str): # 这里用非常简单的关键词规则做演示 if "代码" in query or "debug" in query.lower(): return "deepseek", "deepseek-chat" return "glm", "glm-4-air" if __name__ == "__main__": while True: query = input("问题> ") if query.strip().lower() == "exit": break provider, model = route_query(query) client = get_client(provider) resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": query}] ) print(f"[{provider}/{model}]") print(resp.choices[0].message.content)

这种路由只是一个雏形。更合理的做法是把规则换成模型分数、成本预算、响应时间等指标。比如默认用便宜模型，遇到复杂问题时升级到更大更强的模型；某个模型连续报错超过 N 次，就自动切换到备用模型；每日费用达到阈值后，自动把非核心流量切到低成本模型。

这就是从“段子里的竞争”落到工程实践的方式：不要把豆子全放在一个碗里。

6. 常见问题与排查思路

在实际调用 DeepSeek 或 GLM 这类 OpenAI 兼容接口时，最容易遇到的问题有下面几类。

下面展开几个高频问题的排查步骤。

6.1 401 认证失败

问题现象是调用接口时报 401。常见原因是环境变量没有注入成功。

排查顺序：

1. 先打印 os.getenv("DEEPSEEK_API_KEY")，确认 Key 是否为空。
2. 检查程序运行环境是否真的设置了环境变量。
3. 确认 Key 没有多余空格或换行。
4. 检查账号是否欠费或 Key 是否被禁用。

不要直接把 Key 硬编码在代码里。一旦代码上传到公开仓库，Key 就会泄露，可能造成额度被盗刷。

6.2 上下文超限

多轮对话跑着跑着突然报上下文超限，这是最常见的“续杯翻车”现场。

建议在每次调用后记录 usage.prompt_tokens。如果它已经接近模型上限的 70%，就应该触发历史压缩。不要等到报错才去处理，因为报错时，历史可能已经超过了模型的处理能力。

压缩方案可以选择：

• 只保留最近 N 轮消息，例如最近 10 轮。
• 由大模型对历史对话生成摘要，把摘要放进 system 消息。
• 对超长文档做切片检索，只把相关 chunk 放入 prompt。

6.3 限流与重试

大模型 API 通常会有 QPS 限制。如果你的应用有突发流量，很容易收到 429。

解决方案：

• 客户端加指数退避重试。
• 把请求通过消息队列削峰。
• 申请更高并发配额。
• 在多个模型之间做负载均衡，分散请求。

重试时要注意幂等性。如果用户触发了一次生成，不能因为网络重试就重复扣费。最好在业务层做请求 ID 或结果去重。

6.4 模型名不适应

很多模型服务商会不断发布新模型、下线旧模型。几个月前能用的模型名，可能现在已经不能用了。遇到 Model Not Found 时，先不要改代码里的其他逻辑，直接去官方文档或控制台确认当前可用的模型列表。

这也是为什么建议把模型名放到配置中心或环境变量里，而不是散落在业务代码中。这样后续升级模型时，只需要改配置，不需要改代码。

7. 从梗到工程：最佳实践与建议

7.1 统一封装 OpenAI 兼容接口

既然 DeepSeek、GLM 和许多其他模型都支持 OpenAI 兼容格式，建议在项目中封装一个 ModelProvider 层，把 client 创建、超时设置、重试逻辑、错误映射统一处理。业务代码不要直接调用 openai 客户端，而是调用自己封装好的 ask() 方法。

好处很明显：以后新增模型、切换厂商、调整参数时，只需要改动封装的内部逻辑，业务代码保持不变。

7.2 把成本监控当成一等公民

“无限续杯”听起来美好，实际账单却在悄悄膨胀。生产项目中必须把 Token 用量和成本纳入监控。

推荐每次调用后记录：

• 时间戳
• 模型名
• prompt_tokens
• completion_tokens
• 估算费用
• 用户 ID 或业务场景

有了这些数据，才可以回答几个关键问题：哪个业务最烧钱？哪个用户请求量异常？今天成本比昨天涨了多少？如果预算有限，哪些场景可以降低模型规格？

7.3 用 Prompt Caching 降低长上下文成本

如果请求里经常包含固定的系统提示词、超长文档、工具定义，可以关注服务商是否提供 Prompt Caching。它的核心原理是复用相同前缀的计算结果。

实际使用时要注意：触发缓存通常有前缀长度要求，且不同服务商对缓存命中价格的设计不同。尽量把不变的指令放在 messages 最前面，把变化频繁的内容放在后面，这样前缀缓存命中率会更高。

7.4 不要让任何单一模型成为系统单点

即使是再强的模型，也可能遇到限流、故障、政策调整或版本更新。关键业务至少配置两个可用模型，并设计降级策略。

降级顺序建议：

1. 首选模型正常时使用首选模型。
2. 首选模型超时或报错时，自动切换到备用模型。
3. 两个模型都不可用时，返回缓存结果或提示稍后重试。

这里要注意：不同模型的格式和能力有差异，降级时不一定保证完全相同的回答质量，但对很多业务来说，可用性比单次回答质量更重要。

7.5 注意输入输出安全

大模型应用不是只要能调通 API 就够了。用户输入可能包含恶意提示、隐私数据、违法内容。你还需要做好输入过滤、输出过滤、敏感信息脱敏。

不要把用户原始敏感信息直接拼进对话上下文，尤其不要把 API Key、数据库密码、内部系统日志发给模型。在真实项目中，需要在进入模型之前先做脱敏，在返回用户之前再做合规检查。

7.6 做限流和预算熔断

虽说模型服务商有限流，但你自己的系统也应该有限流，防止单个用户刷爆你的账单。

常见的控制策略：

• 每个用户每天只能调用 N 次。
• 每分钟后端最多向模型转发 M 个请求。
• 每天累计费用达到阈值后自动熔断，停止非核心调用。
• 超长请求先走摘要或 RAG，而不是直接丢给模型。

8. 写在最后：这个段子背后的技术复习清单

回到最开始那句话：“DeepSeek 又端大号碗筷还无限续杯，最后还把路过的 GLM 给撑死了。”

拆开看，它其实涵盖了这些知识点：

• “大号碗筷”对应的是长上下文窗口。
• “无限续杯”对应的是多轮对话中不断增长的 Token。
• “撑死了”对应的是模型竞争压力、价格战和大规模流量冲击。
• “路过的 GLM”对应的则是多模型生态下的真实竞争格局。

顺着这个段子，你把上下文管理、Token 计费、模型调用、成本估算、多模型路由这几个关键技能都过了一遍。如果还想继续深入，下一步可以研究 RAG、Agent 工具调用、模型压测和推理服务部署。这些方向本质上都是在解决同一个问题：如何让 AI 能力更便宜、更稳定、更可控地落地到真实业务里。

下次再看到类似的“大模型段子”，不妨先把它翻译成技术问题，再打开代码跑一遍多轮对话，看看 prompt_tokens 是怎么一点点涨上去的。只有亲手调过 API、看过 usage、算过账单，才能真正理解“无限续杯”背后的代价。