75 篇博文 含有标签「LLM」

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

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

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 传输这笔账怎么算、两级调度怎么设计，最后给一个可运行的模拟器和一份踩坑清单。

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 时代的代码验证拆成四层，讲清每一层做什么、在哪一层容易翻车。

系统提示词（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。这篇文章拆解它背后的原理、训练细节和部署方式。

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

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

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

「这个模型写代码不错」和「这个 Agent 能完成 20 轮工具调用把事办成」是两回事。单轮评测测的是「会不会答」，Agent 评测测的是「会不会把事情办成」——后者涉及状态、工具副作用、长程规划，评测的复杂度直接上了一个数量级。

上一篇LLM 评测工程化讲了单轮文本评测的偏见与校准，这篇聚焦 Agent 场景：评测什么、拿什么当标准答案、怎么写评测骨架、怎么避免评测本身成为成本黑洞。面向已经在跑 Agent 生产流量的后端工程师，不讲科普。

这是「每日一题」专栏的第七篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了分布式 ID 生成器，今天回到 AI/LLM 方向，聊一个让你在长上下文推理时 OOM 的元凶。

很多后端工程师第一次接触 LLM 推理都会困惑：为什么 prefill 快如闪电，decode 却一个字一个字地蹦？为什么 8B 模型的 fp16 权重才 16GB，vLLM 却要求 40GB 以上显存？答案都指向同一个东西：KV Cache。它既是 decode 速度的根基，也是推理服务显存和带宽的最大开销。这篇文章从显存账本算起，讲清楚 KV Cache 为什么是推理性能的隐形瓶颈，PagedAttention 如何用「虚拟内存」的思路解决碎片化，以及 GQA、MLA、量化、prefix caching 各自省掉了什么、代价是什么。文末附一个可运行的 numpy 最小实现和生产环境踩坑清单。

前两篇分别聊了向量数据库选型（向量数据库选型对比）和检索链路的分块/重排序（RAG 检索优化深度拆解），但都把 Embedding 模型当成了黑盒——喂进去文本，吐出来一串浮点向量。这篇把盒子拆开，聚焦一个高级后端工程师做规模化 RAG 时迟早会撞上的问题：向量又大又多，存储和检索延迟怎么砍？

先算笔账。一个 100 万 chunk 的语料库，用 1536 维 float32 的 Embedding（比如 text-embedding-3-small），单是向量本体就是：

1,000,000 × 1536 × 4 字节 ≈ 6.1 GB

这还没算 HNSW 图索引的开销（通常再乘 1.2 到 1.5 倍）。规模涨到 1000 万 chunk，向量本体就 61GB，单机内存放不下，得上分布式。但真相是：绝大多数检索场景根本用不到 1536 维的全精度浮点。今天聊的三件事——对比学习怎么训出 Embedding、Matryoshka 怎么一个模型任意维度截断、量化怎么把向量压 8 到 32 倍——就是把这笔账砍下来的三条路。