跳到主要内容

Token 即金钱:LLM 用量计量与计费系统的工程实践

· 阅读需 11 分钟

聊 LLM 应用的工程,大家津津乐道的是推理优化、RAG、Agent 编排,但真正决定一个 ToB/ToC 产品能不能赚钱的,往往是没人愿意写的计量与计费。模型调用不像 MySQL 查询——没有免费的 EXPLAIN,每一次 API 调用都是真金白银的流出;而一旦你开始对用户收费、对开发者分成,计费就从「省钱工具」升级成「信任地基」:计量错了,不是亏钱就是信任崩塌。

这篇文章从后端工程师视角,把「一次模型调用 → 一条 usage 事件 → 一张账单 → 一笔分账」的完整链路拆开:usage 从哪来、按什么价、怎么记、怎么算、怎么对账。基于真实平台(以 DeepSeek 2026-08 官方计价为例)的实操经验,有 schema、有代码、有坑。

PD 分离架构:prefill 和 decode 拆到不同节点,Kimi 多扛了 75% 请求

· 阅读需 10 分钟

PD 分离(Prefill/Decode Disaggregation)是这两年推理集群改造里回报最高的一步。DeepSeek-V3 技术报告在部署章节明确写了 "separates the prefilling and decoding stages";Kimi 的 Mooncake 平台靠它多扛了 75% 的真实流量;vLLM、SGLang、NVIDIA Dynamo 都把它做成了一等公民。

但这项技术有个反直觉的点:它几乎不提升峰值吞吐,买的是延迟的可控性。vLLM 官方文档第一句就是 "Disaggregated prefill DOES NOT improve throughput"。本文拆解它为什么成立、KV cache 传输这笔账怎么算、两级调度怎么设计,最后给一个可运行的模拟器和一份踩坑清单。

LLM 生成代码的评审与验证:从「AI 写的能跑」到「敢合入生产」的工程化流程

· 阅读需 6 分钟

AI 生成代码的比例正在快速攀升,但绝大多数团队的评审流程还停留在「AI 写完 → 人看一眼 diff → 合入」。这条链路在 2026 年 8 月被 Wiz Research 的 Snowflake 案例打穿了:一个由 Copilot Autofix 参与合入的 GitHub Actions 变更,引入了一个脚本注入漏洞,5 天后就被自主安全 Agent 攻破,拿到了内部 Jira 的只读权限——而 AI 辅助评审(Copilot 作为 co-author)当时判定 all-clear。

这不是孤例。HN 上「How do you review and validate LLM generated code?」的讨论里,一线工程师的共识很朴素:AI 写代码的节奏变了,但「验证代码」的严谨度不能跟着降级,反而要升级。本文把 AI 时代的代码验证拆成四层,讲清每一层做什么、在哪一层容易翻车。

Gisting 上下文压缩:把 6000 token 系统提示词压成 1500 个 gist token,推理成本直降 14%

· 阅读需 6 分钟

系统提示词(system prompt)正在成为 LLM 推理成本里最容易被忽略的部分。一个正经的 Agent 通常要背几十条指令、工具 schema、few-shot 示例和安全约束,动辄几千 token。每次请求都要编码这些 token,decode 时每个生成 token 又要对它们做 attention——长度是线性成本,而吞吐是用户的账单。

2026 年 8 月 19 日,Shopify Engineering 公开了他们在生产环境落地的一项技术:gisting。他们把自己的 GraphQL Agent 系统提示词从约 6000 token 压到约 1500 个 gist token(4:1 压缩),在预测质量不掉的前提下,把 350 RPM 流量下的 TTFT 从 438ms 降到 354ms(-19%)、端到端延迟从 6.8s 降到 4.2s(-38%)、吞吐从 20.2 QPS 提到 23.4 QPS(+16%),最终少用了 14% 的 GPU。这篇文章拆解它背后的原理、训练细节和部署方式。

面试题:设计一个秒杀系统,怎么扛住瞬时洪峰、又怎么防超卖?

· 阅读需 10 分钟

这是「每日一题」专栏的第九篇。每天一道面试题,后端 + AI 混合路线,从原理到代码一次讲清。上一篇讲了 分布式事务,今天按轮换到系统设计方向,聊一道电商场景出镜率最高、也最考验工程功底的题:设计一个秒杀系统。

LLM 流式响应后端工程:SSE、背压、超时与取消传播的实战细节

· 阅读需 10 分钟

流式输出(streaming)已经是 LLM 应用的默认形态——用户等不了非流式的 TTFB,ChatGPT 系的打字机效果也成了产品预期。但对后端工程师来说,SSE 协议本身只有半小时的学习成本,真正的工程难点在异步管道的生命周期管理:客户端慢了怎么办?上游断了怎么办?用户关页面了,上游还在生成、还在烧钱,怎么办?这篇文章聊的就是这些。

语音 Agent 与流式 ASR:延迟预算、打断与低延迟全链路工程

· 阅读需 7 分钟

语音 Agent 和文本 Agent 的体验差距,往往不在模型智商,而在延迟和打断。文本场景用户等 3 秒没问题;语音场景超过 800ms 不说话,用户就会开始重复提问。而「打断」——用户中途插话——是语音交互里最高频、也最容易做砸的环节。

这篇讲语音 Agent 工程化:端到端延迟预算怎么拆、流式 ASR 的架构选择、打断(barge-in)与全双工设计。面向要自建语音链路而不是只调云 API 的工程师。上一篇多模态 VLM 工程指南讲了视觉侧,这篇补上听觉侧。

K8s 上的 GPU 调度:从 Device Plugin 到 Kueue/Volcano 的推理集群资源管理

· 阅读需 9 分钟

推理集群的利用率为什么普遍只有 30%-50%?大多数时候不是模型不够强,而是调度层把 GPU 当成了「特别大号的 CPU」。这张卡该不该给、给多少、和谁共享、抢占了谁——每一步都决定你是多跑一倍任务,还是天天看着显存碎片和排队干瞪眼。

上一篇Linux VRAM overcommit 与显存超卖讲了单机层面的显存管理,这篇往上一层:K8s 集群里 GPU 是怎么被调度、切分和排队的。面向要搭推理集群的 SRE / 平台工程师,从 Device Plugin 讲到 Kueue、Volcano,附可直接抄的 YAML。

面试题:分布式事务怎么做?2PC、TCC、Saga 各解决什么问题、又各有什么坑?

· 阅读需 8 分钟

这是「每日一题」专栏的第八篇。每天一道面试题,后端 + AI 混合路线,从原理到代码一次讲清。上一篇讲了 KV Cache 与长上下文推理,今天回到后端/分布式方向,聊聊分布式系统里最经典、也最容易被问住的话题:分布式事务。