版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。一、「一天多少钱」这道题考官在听什么面试官问「这个功能上线后一天大概花多少钱」多半不是想听一个精确到分的数字。他自己也清楚单价会调整、用量会波动。他想听的是你有没有把这件事拆开过以及你知不知道自己在哪里不知道。传统技术岗转过来的候选人最容易在这里吃亏。写代码的能力不缺业务理解也不缺缺的是「把一次模型调用当成一次计费事件来看」的习惯。这个习惯不需要算法背景只需要在写第一版的时候就认真读一遍响应里的usage字段。1.1 三个隐性评分点第一个是拆得开。费用由输入、输出、缓存命中、重试四块构成能不能分开说决定了他判断你是「听过」还是「算过」。第二个是量过。真实项目里token 数不是猜出来的是把messages拼好之后数出来的或者从上一轮响应的usage里读出来的。说得出字段名的人通常真的调过。第三个是有边界意识。max_tokens是上限不是预估、缓存会过期、失败重试会重复消耗输入这三件事只要提到一件可信度立刻不同。1.2 为什么「不贵」是坏答案「不贵」这两个字的信息量是零而且会把话题引到一个你控制不了的方向面试官接着问「那大概多少」你还是得算只是气势弱了一截。常见回答面试官听到的意思更稳的接法「不贵一次就几分钱」没有量过随口给「我先说假设一天多少提问、一次会话几轮再按四块拆」「按 token 算的看用量」知道名词不知道结构「输入和输出是两条价输入里还要分缓存命中和未命中」「看模型模型不同价格不同」只停在选型层「单价以官方定价页为准我讲算法你给个单价我就能报数」「我们量过大概这个范围」有工程习惯接一句「依据是日志里的 usage 汇总我按 95 分位取的输出长度」最后一行那句「95 分位」很关键。成本不是平均值问题长尾才是。同一批请求里少数超长输出会把日成本抬得很明显按平均值算出来的数在真实账单面前总是偏低。1.3 一个能直接用开场句「我先把假设摆出来一天大约多少条提问、一次会话平均几轮、检索片段多长然后按输入、输出、缓存、重试四块算最后给一个区间而不是一个点。」这句话说完评分点基本都摆到桌面上了。后面哪怕数字估偏方法分也拿到了。二、第一行输入 token 与输出 token 分开列2.1 输入不只是用户那句话新手最常见的低估是拿用户提问的长度当输入长度。真实的一次请求输入至少由四块拼成系统提示角色设定、输出格式约束、拒答规则工具定义函数名、参数 schema、描述。这块最容易被漏掉而它往往比系统提示还长检索片段RAG 场景里每轮拼进去的文档块长度随召回条数变化对话历史前面所有轮次的提问和回答原样重发。判断自己有没有漏把发给模型的messages里所有content加起来再单独加上tools数组序列化后的长度。两笔都算才算完。这一条在真实项目里经常反过来咬人。工具定义是结构化 JSON字段名、类型、描述中英混排token 效率比自然语言差一个接了十来个工具的应用光工具定义就可能顶掉几千 token而且每一轮都要重发。所以被问到「输入为什么这么大」先答「工具定义占了多少」比答「用户问得长」更接近真相。2.2 两家字段名不同结构是同一套输入、输出、缓存这三类信息两家都会在响应里返回只是叫法不一样。下表是本文核验到的字段名核验方式见附表 A。含义OpenAI Chat CompletionsOpenAI ResponsesAnthropic Messages输入总量prompt_tokensinput_tokensinput_tokens输出总量completion_tokensoutput_tokensoutput_tokens总 tokentotal_tokenstotal_tokens无同名字段需自行相加命中缓存的输入prompt_tokens_details.cached_tokensinput_tokens_details.cached_tokenscache_read_input_tokens写入缓存的输入prompt_tokens_details.cache_write_tokensinput_tokens_details.cache_write_tokenscache_creation_input_tokens推理消耗的 tokencompletion_tokens_details.reasoning_tokensoutput_tokens_details.reasoning_tokensoutput_tokens_details把这张表记住一半就够用了输入一个字段、输出一个字段、缓存两个字段。有这四项四行草稿就能写三行。⚠️代码待验证一次请求里把「输入 / 输出 / 缓存」三类数各取一遍明细字段可能是 None取值前要判空。fromopenaiimportOpenAIimportanthropic oaOpenAI()roa.chat.completions.create(model你的模型名,messages[{role:system,content:SYS},{role:user,content:q}],)ur.usage cachedu.prompt_tokens_details.cached_tokensifu.prompt_tokens_detailselse0reasonu.completion_tokens_details.reasoning_tokensifu.completion_tokens_detailselse0print(f输入{u.prompt_tokens}命中缓存{cached}/ 输出{u.completion_tokens}推理{reason})clanthropic.Anthropic()mcl.messages.create(model你的模型名,max_tokens512,system[{type:text,text:SYS,cache_control:{type:ephemeral}}],messages[{role:user,content:q}],)print(f输入{m.usage.input_tokens}写缓存{m.usage.cache_creation_input_tokens}/ f读缓存{m.usage.cache_read_input_tokens}/ 输出{m.usage.output_tokens})上面这段里cache_control的写法、以及各参数是否还能这么传请以官方 reference 为准截至 2026-10-20 核验。响应里的结构大致长这样数值是假设用来看字段层级{usage:{prompt_tokens:2060,completion_tokens:200,total_tokens:2260,prompt_tokens_details:{cached_tokens:800,cache_write_tokens:0},completion_tokens_details:{reasoning_tokens:0}}}2.3 输出为什么一定要单列三个原因一条比一条硬。单价不同。输出单价普遍高于输入具体倍数以官方定价页为准截至 2026-10-20 核验。你按输入价乘总 token结果一定偏低。推理 token 也算输出。官方 SDK 的字段注释里写得很直接推理消耗的 token 仍然计入用于计费的输出 token 总数。也就是说一个「只输出两行字」的答案背后可能花掉几千 token 的思考量。输出的总数字段才是计费口径。Anthropic 的output_tokens_details注释里写明output_tokens仍然是「inclusive, authoritative total used for billing」明细对象只是给可观测性用的拆分。别拿明细去算钱拿总数。这一节的判据只有一句话报价时先说「输入多少、输出多少」再乘单价。顺序反了后面全错。三、第二行多轮对话里上下文是累积的3.1 第 N 轮比第 1 轮贵在哪模型没有记忆。所谓「多轮对话」是客户端每一轮都把之前的提问和回答重新拼进messages再发一次。于是第 N 轮的输入里除了固定的系统提示和检索片段还多了一份越来越长的历史。设系统提示与工具定义合计 S检索片段 R每轮用户输入 u每轮输出 o那么第 N 轮输入 ≈ S R N·u (N−1)·oN 轮输入总量 ≈ N·(SR) N(N1)/2·u N(N−1)/2·o看第二行就能明白问题在哪总量里有一项是 N²。轮数翻四倍输入总量大致涨十几倍而用户感知到的只是「聊得久了点」。这是成本估算里最容易漏掉的一层也是面试里最能体现「真的跑过」的一层。3.2 跑一遍看数字长什么样下面这个脚本只算 token 账不含任何单价避免把「单价」和「用量」混在一起。python work/2026-10-20-03_成本草稿.py--sys800--rag1200--user60--out200--rounds5在本机实际跑出来的结果输入参数是假设值用来演示结构第 1 轮输入 2060其中历史 0 输出 200 第 2 轮输入 2320其中历史 260 输出 200 第 3 轮输入 2580其中历史 520 输出 200 第 5 轮输入 3100其中历史 1040 输出 200 5 轮输入合计 12900输出合计 1000总计 13900 第 5 轮输入 / 第 1 轮输入 1.50 倍这组数字里有两件事值得盯住。第一件是固定部分有多大。2060 里系统提示 800 加检索片段 1200 就占了 2000历史只占零头。也就是说轮数少的时候成本几乎全由「每轮都要重发的固定前缀」决定而这块恰好是缓存能救的部分。反过来历史占比越高说明会话越长这时候该考虑的就不是缓存而是截断和摘要。第二件是叠加效应的形状。拿单轮 2060 乘 5 得 10300而实际输入合计 12900差 2600低估约两成半如果只算「输入 × 轮数」而忘了输出那 1000缺口更大。轮数越往上缺口张得越快20 轮的会话里误差会大到没法用嘴圆回来。换句话说多轮场景的成本曲线不是一条直线是一条向右上弯的曲线。面试时能说清「它为什么弯」比背一个具体数字有用得多。3.3 三种控量手法的代价轮数压不住的时候通常有三条路每条都有明确的代价。滑动窗口截断。只保留最近 k 轮。代价是模型会忘记更早的约定比如用户第 2 轮说的「不要用表格」第 8 轮就失效了。适合问答型工具不适合任务型会话。摘要压缩。把早期历史压成一段摘要再放进去。代价是多一次模型调用这次调用的费用要算进总账而且摘要会丢细节。适合长会话但摘要提示词本身也是一笔固定的输入成本。每轮重取检索。不传历史只传检索结果。代价是代词消解会崩「它」指什么模型不知道。适合单轮查询不适合追问。判据可以很土如果用户在第 3 轮之后提出「重新来」说明上下文其实没被用上那就该截断如果用户频繁用「刚才那个」就必须留历史改从输出长度和模型档位省钱。四、第三行缓存命中与未命中是两条价4.1 同一段系统提示只有第一轮是未命中这是全场最值钱的一句话。系统提示、工具定义、固定的 few-shot 示例在多轮里逐字不变第一次请求时它们要被当作输入处理并写入缓存从第二轮开始同一段前缀按「缓存读取」计价。状态触发时机计费口径在哪看未命中首次出现、缓存过期、前缀被改动按输入单价cached_tokens为 0 或很小写入首次建立缓存条目通常高于输入单价cache_write_tokens/cache_creation_input_tokens命中前缀逐字一致且在有效期内明显低于输入单价cached_tokens/cache_read_input_tokens写入溢价和命中折扣的具体数字两个厂商、每个模型都不一样而且会调整本文不写死。一律以官方定价页为准截至 2026-10-20 核验算的时候把它当成两个独立单价代进去就行。4.2 缓存不是自动的也不是永久的官方口径里有几个细节直接决定你在面试里能不能接住追问以下为官方域名检索与官方仓库源文件核验结果页面直连情况见附表 A输入要够长才进入缓存机制。OpenAI 的公开说明是提示词超过 1024 token 才自动生效按 128 token 为增量匹配「最长公共前缀」。缓存有生命周期。OpenAI 的说明是 5 到 10 分钟不活动后通常被清理最迟在最后一次使用后一小时内移除Anthropic 的定价口径按 5 分钟 TTL 计另有更长 TTL 的选项。前缀必须逐字一致。工具定义改了描述、schema 顺序调了、系统提示多了一个空格都可能让命中中断。官方在缓存诊断里给的原因之一就是「工具变了」。由此得到一条可执行判据把稳定的内容放最前面并按固定顺序序列化把每轮变化的内容检索片段、用户输入放最后。顺序反了缓存等于没有。这里有个真实取舍要说清楚把检索片段放在系统提示之前命中率会更差但有时效果更好因为模型更容易把检索内容当成主要依据。成本与效果在这一处是冲突的没有统一答案。能说清「我知道这里在拿什么换什么」比给一个标准答案更像做过事的人。4.3 面试里怎么说这一条差的说法是「有缓存会便宜一点」。好的说法是「同一段系统提示只有第一轮是未命中之后每轮按命中价但检索片段每轮都变命中只能覆盖到它之前的部分。所以我的优化动作是把工具定义和固定指令钉死在最前面并且保证序列化顺序不变。」这段话里有机制、有边界、有动作三样都在。面试官再追问「命中率怎么保证」你也有东西可答。五、第四行max_tokens是上限不是预估5.1 官方原文怎么说Anthropic 的max_tokens参数在官方 SDK 里的说明是The maximum number of tokens to generate before stopping.Note that our models may stopbeforereaching this maximum. This parameter only specifies the absolute maximum number of tokens to generate.OpenAI 的对应参数max_completion_tokens的说明是An upper bound for the number of tokens that can be generated for a completion, including visible output tokens and reasoning tokens.两句话说的是同一件事这是天花板不是预期值。顺带一提OpenAI 的max_tokens在官方 SDK 里标注为 deprecated不推荐继续使用新代码应改用max_completion_tokens。这一点在面试里被问到「你怎么设输出上限」时是加分细节。5.2 拿上限乘单价会错多少假设你把max_tokens设成 1024实际平均输出 200 token按上限算就把输出成本放大了五倍。反过来设得太小也不行推理消耗的 token 计入这个上限上限压到 256长一点的答案会在中途被截断。判断有没有被截断看结束原因就行。OpenAI 的finish_reason里length表示撞到了长度上限Anthropic 对应的是stop_reason为max_tokens。这两个值出现得频繁说明你的上限或者提示词里的长度约束需要调。所以第四行要写两个数平均输出长度用来算钱和max_tokens设置值用来说明你怎么控制最坏情况。两者写在一起才叫「上限是上限预估是预估」。5.3 余量留给谁余量不是留给「模型话多」是留给工程现实。三件事会让实际请求数高于用户提问数重试超时、限流、网络断开后重发输入会再算一遍工具循环一次问答里模型可能连续调用两三次工具每次都是一次完整请求而且上下文越滚越长流式中断前端断线重连如果没有做幂等等于白付一次。⚠️代码待验证defdaily_cost(n_user,rounds,sys_t,rag_t,user_t,out_avg,retry_ratio,p_in,p_out,p_cache):四行草稿合成一个函数单价由调用方从官方定价页填入。reqn_user*rounds*(1retry_ratio)# 请求数含重试avg_hist(rounds-1)/2*(user_tout_avg)# 平均历史长度in_tsys_trag_tuser_tavg_hist miss_tsys_trag_t# 固定前缀首轮未命中hit_tin_t-miss_t# 其余部分按命中价cost(miss_t/1e6*p_inhit_t/1e6*p_cacheout_avg/1e6*p_out)*reqreturn{请求数:round(req),单次输入:round(in_t),日成本:round(cost,2)}这个函数刻意没有给单价默认值也没有把缓存写入费用摊进去。写入只在建立缓存的那一次发生量小但单价高报数时提一句「另有一次性写入成本」比漏掉更稳。成本草稿脚本与配套资料本章那个把四行草稿跑成数字的脚本、以及本文用到的字段对照都放在资料包里扫码即可获取六、四行草稿写出来是什么样6.1 一张纸上的四行行写什么依据常见错误第 1 行单次请求输入 A系统 B 工具 C 检索 D 历史 E输出 Fusage的输入/输出字段只算用户提问长度第 2 行会话N 轮输入合计约…第 N 轮是首轮的…倍N·(SR) N²/2·(uo)用首轮乘轮数第 3 行缓存固定前缀 X 按未命中一次、命中 N−1 次检索段不命中cached_tokens实测占比默认全量命中第 4 行输出按平均 F 计max_tokens设 M 兜底请求数乘 1.1–1.3 留重试日志里的输出长度分布用 M 乘单价四行写完通常不到半张 A4。它的价值不在于精确而在于每一行都能被追问且都有对应的字段或日志。6.2 现场说的顺序先说假设再说四行最后给区间。这个顺序不是礼节是防守假设摆在前面面试官要反驳就会先反驳假设比如「我们一天只有两百次提问」而不是直接判你算错。你也顺势可以说「那按两百次日成本大概在这个区间」。区间怎么给把输出长度按平均值和 95 分位各算一次两个数就是区间的上下沿。这个做法在工程上叫敏感性分析说起来很朴素——成本对什么最敏感就先说那个。绝大多数场景里最敏感的是轮数和输出长度不是单价。如果对方说「你就按现在这套参数算」那更好办把本文那个脚本的参数换成他给的数跑一遍把输出念出来。数字准不准是次要的过程可视才是主要的——他会看到你不是在背结论而是在算。6.3 三种追问怎么接追问他想确认什么怎么答「太贵了怎么降」你有没有成本结构感先分「结构性能降」和「参数性能降」截断历史、缩小检索条数、把固定前缀钉死吃缓存是结构性的换小模型、压max_tokens、缩短输出格式是参数性的。先说结构性因为它不改效果「缓存命中率怎么保证」你知不知道缓存会失效前缀逐字稳定、顺序固定、变化内容后置上线后看缓存字段占比掉下来就查工具定义和提示词有没有被改「用户量翻十倍呢」你会不会算规模输入随轮数是平方项、随用户数是一次项所以量级放大主要看会话长度分布十倍用户如果会话变短总成本可能不到十倍第三问是陷阱题。很多人条件反射答「那就十倍」实际要拆的是「用户数」和「单会话 token」两个乘数而后者往往才是主导项。七、会算之后账为什么还是对不上7.1 四个常见原因原因表现处理请求数被低估账单里的请求数明显多于业务日志里的提问数把重试、工具循环、健康检查都计入缓存没按预期命中输入费用接近全量未命中检查前缀是否被动态内容打断输出长度长尾平均值算得挺好月度账偏高按 95 分位再算一遍单价口径变了同一个模型两个月单价不同账单按「模型 时间」双维度打标第四条最容易被忽略。厂商会调整单价、调整缓存折扣、推出新档位你的估算表如果写死了数字半年后就是错的。所以正确的做法是把单价做成配置把算法写成公式单价变了只改一处。还有一个笨办法值得坚持每周把日志里的usage汇总一次和账单对一遍差得多的那一周去翻变更记录。做上三个月你对自家业务的单位成本会有肌肉记忆面试时说出来就是具体的不是「大概不贵」。7.2 面试前能自己做的四件事第一把两家 SDK 里usage相关的类型定义文件读一遍。字段名和注释都在里面比二手教程可靠而且读源码这件事本身就是信号。第二写一个只算 token、不算钱的脚本把「单轮 / 多轮 / 缓存」三种情况各跑一遍。本文那个脚本四十来行够用了。第三找自己做过的一个功能把一次请求按系统提示、工具定义、检索片段、历史四块拆开估一遍估出来的数字和直觉差多少记下来——面试时这就是你的例子。第四准备一句兜底话「具体单价我不敢报因为会调整但我知道在哪查、怎么代进公式十分钟能给一个区间。」这句话不露怯反而显得靠谱。岗位能力自查清单与配套资料本文的四行草稿模板、字段对照表和自查清单都放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处本文位置核验方式Chat Completions 的usage含prompt_tokens、completion_tokens、total_tokens及两组明细openai/openai-python 仓库src/openai/types/completion_usage.py第 2 章本机 curl 直连raw.githubusercontent.comHTTP 200 取到原文Responses API 的usage含input_tokens、output_tokens、input_tokens_details.cached_tokens、output_tokens_details.reasoning_tokens同仓库src/openai/types/responses/response_usage.py第 2 章同上推理与预测类 token 仍计入用于计费的输出总数同仓库completion_usage.py中rejected_prediction_tokens注释第 2 章同上max_tokens标注 deprecatedmax_completion_tokens为「上界含可见输出与推理 token」同仓库src/openai/types/chat/completion_create_params.py第 5 章同上AnthropicUsage含input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokensanthropics/anthropic-sdk-python 仓库src/anthropic/types/usage.py第 2、4 章本机 curl 直连raw.githubusercontent.comHTTP 200output_tokens是计费的权威总数明细仅供可观测同上output_tokens_details注释第 2 章同上cache_creation按 5 分钟与 1 小时两种 TTL 拆分计数同仓库src/anthropic/types/cache_creation.py第 4 章同上max_tokens原文「may stop before reaching this maximum … absolute maximum」同仓库src/anthropic/types/message_create_params.py第 5 章同上思考消耗的 token 计入max_tokens上限同上thinking参数注释第 5 章同上缓存写入价高于基础输入价、缓存读取价明显低于基础输入价Anthropic 官方公告与定价页第 4 章www.anthropic.com/pricing本机直连 HTTP 200具体比例与单价以官方定价页为准截至 2026-10-20 核验提示词需超过 1024 token 才自动进入缓存按 128 token 增量匹配最长公共前缀缓存 5–10 分钟不活动后通常清理最迟 1 小时移除OpenAI 官方文章《Prompt Caching in the API》第 4 章该页本机直连返回 403改用官方域名检索核验摘要含官方原文缓存折扣随模型不同且估算时要计入缓存写入费用与长上下文费率OpenAI 官方文章2026 年缓存更新说明中文版同文第 4、7 章同上官方域名检索核验未直连抓取Anthropic Messages API reference 正文platform.claude.com/docs/en/api/messages第 2、4、5 章改用官方 SDK 源文件替代未取到本机访问跳转至区域不可用提示改用官方 SDK 仓库源文件核验具体单价每百万 token 价格两家官方定价页全文因此不写具体数字待验证本机无 API key也未取到稳定可引用的数字故全文不写具体单价四行草稿脚本输出2060 / 2320 / 2580 / 31005 轮合计 12900本机脚本work/2026-10-20-03_成本草稿.py日志work/2026-10-20-03_成本草稿.log第 3 章本机实测输入参数为假设值仅用于演示结构官方文档站直连情况platform.openai.com403、platform.claude.com跳转区域提示本机 curl 实测附表 A本机实测当次结果附表 B术语速查表术语一句话解释在本文哪里用到token模型处理文本的最小计费单位中文一个字通常对应一到两个全文输入 token你发过去的内容折算的 token含系统提示、工具定义、检索片段、历史第 2 章输出 token模型生成的内容折算的 token含推理过程第 2 章上下文累积多轮对话时把历史整体重发导致输入随轮数增长第 3 章提示词缓存把重复出现的长前缀存起来复用命中部分单独计价第 4 章缓存写入第一次把前缀写进缓存单价通常高于普通输入第 4 章缓存命中复用同一段前缀单价明显低于普通输入第 4 章TTL缓存条目的存活时间过期后重新按未命中计第 4 章max_tokens输出长度的天花板不是预期长度第 5 章推理 token模型内部思考消耗的 token计入输出与上限第 2、5 章重试余量为超时、限流、断线重发预留的请求数系数第 5 章95 分位把一批数值排序后第 95% 位置的值用来估计长尾第 1、6 章写在最后这篇用到的资料写这篇文章时把相关的官方文档和源码又翻了一遍顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告 经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。
