LLM API 成本怎么算：把 token 账算清楚
做 LLM 应用，最常被问的一句话是"这个功能每天要花多少钱"。答案取决于一个变量：每次请求消耗多少 token。这篇把这笔账拆开算一遍，顺便讲讲哪几个地方最容易算错。
小火龙实验室
AI科普
把复杂的AI知识讲得让人类能听懂
大模型调用怎么拆成本：说说模型级联
很多团队一谈降本，第一反应是换小模型，再不然就是砍预算。这两个办法都偏粗暴。另一种更可控的玩法叫模型级联（Model Cascade）：让便宜模型先上，便宜模型"不自信"的时候，再交给贵的处理。
1 个 token ≈ 多少字：LLM 计费里的隐形单位
如果你算过 AI API 的账单，会发现计量单位不是"字"也不是"词"，而是 token。工程师常见的第一个问题：一个 token 是不是等于一个字？不完全是。
它明明读完了几万字，为什么关键信息还是漏了：lost in the middle
你大概见过这种场景：把一份 30 页的需求文档整个喂给大模型，让它总结并列出验收标准。它洋洋洒洒回你一页，结构漂亮，语料库里的术语一个不少——但恰好漏掉了第 14 页那句"退款必须在订单创建后 48 小时内发起"。
给AI系统做回归测试：LLM评测的工程实践
传统系统改了一个函数，跑一遍单测，全绿就提交。LLM 应用里这套办法失效：输出是随机的，同一个问题，这次返回"好的"，下次返回"好的没错"。改了一版 prompt，怎么知道没把别的东西改坏？答案和软件工程一样：搞一套回归测试集。
请求不等齐才出发：推理服务里的连续批处理
上周有读者问：为什么同样一张 GPU，别人跑的请求量是你们的三倍？模型一样，量化一样，卡也一样。差距往往不在模型，在调度。
大模型的首字为什么总是最慢？
下次把长文档发给大模型时，留意一个不算稀奇但很少被解释的体验：第一个字"打"出来要等好几秒，等它出现之后，后面的字反而越吐越快。这不是网络抖了，是模型本身两阶段的分工造成的：prefill 和 decode。
结构化输出不是"求模型听话"，是推理器在解码时的约束工程
很多生产团队遇到同一个问题：模型答得挺流畅，但返回的 JSON 偶尔会缺个括号、多个逗号、字段名打错，下游解析一报错，整条流水线就断。于是有人把锅甩给"模型不稳定"，也有人试图靠 prompt 反复叮嘱"一定要输出合法 JSON"。
同一个 Prompt，为什么这次跑对了上次跑错了：LLM 推理的非确定性与工程对策
在生产环境里，最折磨人的 bug 往往不是报错，而是"时灵时不灵"：同一个 prompt，连发五次，两次答对，三次答错。这背后不是玄学，而是 LLM 推理里几个可以量化的机制。