推理引擎选型是 LLM 服务化里最容易被低估的架构决策。同样的模型、同样的 GPU，换一个引擎吞吐可能差 2-3 倍；但反过来，厂商 benchmark 里好看的引擎，落到你的真实负载上可能反而更慢。这篇文章把 vLLM、SGLang、TensorRT-LLM、TGI 四个主流引擎放在一起对比，从调度机制、前缀缓存、结构化输出、量化、MoE 支持五个维度拆，最后给选型决策表和生产踩坑记录。

这是「每日一题」专栏的第十篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了 秒杀系统，今天按轮换回到 AI/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。这篇文章拆解它背后的原理、训练细节和部署方式。

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

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

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

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

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

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