LLM 小游戏如何估算成本：先数调用次数

给每日谜题游戏接上 LLM，到底是便宜得可以忽略，还是玩家一多就烧不起？作者给出的答案是：先看生成发生在哪里。每天生成一道题供所有人使用，与每个玩家、每次交互都重新生成，成本结构完全不同。

这篇文章用一组假设价格拆开了这笔账，也把质量审核和等待时间放进了架构选择。它没有真实项目的账单，但提供了一个适合动手前使用的估算框架：先数调用，再算 token，最后补上重试、审核和上下文增长。

同一个模型，为什么能算出完全不同的账单

作者设想了一个「Riddle of the Day」项目：每天一道短谜题，附带提示和答案校验。它可以有三种实现方式。

方案 A 是每天生成一次。定时任务写好当天的谜题和提示，存入数据库或静态文件，所有玩家读取同一份内容。每天的基础调用量是 1 次，再加重试和检查。玩家增加，不会直接增加这部分模型费用。

方案 B 是每位玩家生成一次。每个人拿到个性化谜题，调用量随活跃玩家数线性增长。

方案 C 是每次交互都生成。猜错后临时写提示，或者让模型判断自由文本答案，调用量变成「玩家数 × 人均交互次数」。玩家越投入，模型账单也可能越高。

下面这个公式用于估算每天的模型调用费用：

cost_per_day = calls_per_day × (input_tokens × input_price + output_tokens × output_price)

要注意 calls_per_day：它由产品交互和生成架构决定。价格单位也必须统一，公式里按每 token 计价，而供应商通常按每百万 token 报价。

作者假设输入价格为每百万 token 1 美元，输出为每百万 token 4 美元，每次输入 800 token、输出 300 token。单次费用就是：

800 × $1/1M + 300 × $4/1M = $0.0008 + $0.0012 = $0.002

这些数字是演示用的，不是任何供应商的实际报价。

原文还给出了同一模型、同一提示词可能出现 5,000 倍成本差距的结论，但所提供的正文没有列出对应的玩家数和交互次数，无法复核这个倍数。可以确认的是：固定生成与按人、按交互生成，确实有不同的增长曲线。

预生成省下的，还有审核机会和等待时间

基础公式算出来的是偏乐观的费用。真实流程还会增加几类支出：

• 输出格式错误、提示泄露答案或题目太简单，都可能触发重新生成。
• 用第二次模型调用检查第一次输出，可能让调用量翻倍。
• 面向用户的自由文本通常还需要安全检查。
• 多轮交互如果反复发送历史对话，输入 token 会逐轮增长。
• 人工审核也有成本。作者认为，对每天一道题的方案，它通常是最贵、也最有价值的一项。

其中，质量问题比单次调用价格更难处理。

每天只发布一道题，就有机会先生成多个候选，再检查答案是否唯一、提示是否泄题，最后交给人批准。实时生成则需要把每次输出直接交给玩家，错误提示可能在审核之前就影响游戏体验。

因此，作者倾向于方案 A：模型负责起草，内容经过审核后再发布，只有能明确改善体验的地方才使用实时生成。这是作者的设计判断，原文没有提供不同方案的质量对照实验。

延迟也沿着同一条边界变化。预生成内容可以从缓存读取；按玩家或按交互生成，则把模型调用放进用户等待的路径。提示等上几秒，在游戏里可能就显得卡顿。作者认为流式输出有帮助，提前计算能进一步减少这类等待。

生成频率决定的，不只是账单，还有内容能否在发布前被检查。

我的判断

这套框架最有用的地方，是把讨论从「模型贵不贵」拉回「哪些请求真的需要模型」。如果所有玩家本来就该看到同一道题，每次访问都重新生成，确实很难从这个产品目标里找到理由。

但它是一份架构草算，不是项目总预算。受众增长不会推高方案 A 的基础模型调用量，却仍可能增加数据库、流量和其他服务成本。人工审核也不能藏在便宜的 API 费用后面。

另外，实时输出不等于完全无法检查。作者自己就提到了校验和二次模型评判，只是这些步骤也会增加费用和延迟，不能当作免费的质量保障。

我赞同先考虑预生成，但不把它当作所有 AI 游戏的默认答案。如果个性化就是玩家使用产品的理由，共享同一道题可能省下费用，也削弱了产品价值。原文没有用户留存、满意度或真实账单数据，这部分只能视为经验之谈。

能拿来做什么

• 做每日谜题或固定更新的文字游戏时，可以先让 Node 定时任务生成候选内容，审核后存入数据库或静态文件，前端读取当天已发布的版本。
• 如果个性化是核心功能，就按活跃玩家数估算费用，并限制人均交互次数；需要逐轮生成时，同时控制上下文长度，避免历史对话不断推高输入量。
• 从第一天记录每次调用的输入、输出 token 和重试情况。作者建议，在积累一周真实日志前，给朴素估算乘上安全系数，但没有指定具体倍数。
• 用表格分别估算 10、1,000、100,000 名玩家下的三种方案，并随供应商调价更新价格单元格。原文说五列足够，却没有列出列名，实际建表时需要自行补齐调用量、token 和价格字段。