52 篇博文 含有标签「Engineering」

这是 Function Calling 系列的第三篇。前两篇讲了 Function Calling 诞生的背景和角色、字段与报文处理。本文聚焦一个更底层的问题：怎么让 LLM 输出结构化的、可解析的、格式正确的数据？

「一个 70B 模型、每天 10 万请求、p95 TTFT 小于 1 秒，需要多少张 H100？」如果你问云厂商销售，答案取决于他的季度指标；如果你问架构师，答案应该取决于一张纸上的数学。LLM 推理的性能不是靠 benchmark 榜单「测」出来的，而是可以被两条硬件参数——峰值算力和内存带宽——从第一性原理「算」出来的。

本文沿用 Roofline 模型的分析框架（参考 Sid Babu 2026 年 5 月的同名长文），把 prefill 与 decode 两个阶段的吞吐、延迟写成可计算的代数式，再用 70B 模型在 H100/B200 上的具体数字验证，最后给出一个完整的容量规划实例。看完你会理解三件事：为什么 decode 阶段「大 batch 包治百病」是错的、为什么长上下文是推理成本的真正杀手、以及为什么 FLOPs 越高不代表推理越快。

传统可观测性三板斧——指标、日志、链路——搬进 LLM 应用后很快就失灵了。原因有三个：成本不再是「一台机器多少钱」而是「一个请求烧了多少 token」；故障不再只有 500 错误，还有「返回了 JSON 但字段是错的」「在工具调用里循环了 15 轮」「幻觉编了个不存在的订单号」；确定性不复存在——同一 prompt 两次调用结果不同，你没法靠「重放请求」复现 bug。

这不是换一套 dashboard 的事，而是需要一套面向 LLM 的语义模型：知道哪一次调用花了多少钱、哪个 span 对应哪次工具执行、哪条 Agent 轨迹陷入了循环。本文从 OpenTelemetry GenAI 语义约定出发，拆解指标、追踪、成本归因三个层面，最后给出一条可落地的开源工具链路径。

自回归解码的本质是「一步一个 token」：生成第 t 个 token 必须等前 t-1 个 token 全部算完，而且每个 token 都要跑一遍完整的前向传播。在 decode 阶段，Transformer 的算力利用率通常只有个位数百分比——因为激活很小、瓶颈在显存带宽（memory-bound），GPU 上几 TB/s 的 HBM 带宽被浪费在搬运权重上。这就是投机解码（Speculative Decoding）要解决的核心矛盾：能不能用便宜的计算提前猜出未来几个 token，让大模型一次前向同时验证 K 个猜测？

答案是能，而且无损失。本文拆解投机解码的数学原理、三条主流实现路线（独立草稿模型 / Medusa 多解码头 / EAGLE 特征级草稿）、以及 vLLM 中的生产配置与收益边界。

2026 年的生产应用里，纯文本模型越来越少见——文档解析、截图问答、票据识别、视频审核，几乎每个场景都绕不开「看图」。但把图片塞进 LLM 不是免费的：一张 336×336 的图在 LLaVA 范式下要 576 个 token，比一段 500 字的中文还贵；一次文档问答可能吃掉数千 token 的 prefill。本文从架构、token 成本、数据管线、推理部署、评测五个角度，拆解 VLM 工程落地的关键问题，重点是可复现的数据与可执行的配置。

长上下文是 2026 年推理成本的主战场。模型权重是「一次性」成本——加载一次、人人共享；KV Cache 却是「每次请求」成本——随并发数与上下文长度线性增长。以 Llama-3-70B 为例：fp16 权重约 140GB，而单路 128K 上下文的 KV Cache 在 GQA-8 配置下就要 40GiB，若是 MHA-64 架构则高达 320GiB。权重只装一次，KV 却要为每个并发请求各存一份。这就是为什么「上下文 128K 免费」的口号背后，钱都花在 KV 上。

本文按「架构 → 工程 → 量化 → 驱逐」四层拆解 KV Cache 优化：先算清账，再讲 GQA/MLA 如何从模型侧减量，PagedAttention 与前缀缓存如何复用，FP8/KIVI 如何压缩，最后是 StreamingLLM/H2O/SnapKV 这类「不保留全部」的驱逐方案。数字来自公开论文与可复现的计算，工程建议以 vLLM 为例给出可直接落地的配置。

「模型上线前跑一遍 MMLU 和 HumanEval」——这是 2023 年的做法。到了 2026 年，主流模型的静态基准已经全线饱和：MMLU 分数挤在 85-92 的窄带里，1 个百分点的差异既可能是真实能力差距，也可能是数据集污染或评测噪声。更麻烦的是，生产环境的成败根本不取决于「这题会不会」，而取决于「这个 Agent 在 20 轮工具调用里会不会跑偏」——这是任何静态选择题基准都无法回答的问题。

本文不讨论「哪个模型分数高」，而是拆解评测体系本身：静态基准为什么失真，LLM-as-a-Judge 的偏见从哪来、怎么校准，以及如何把评测从「发版前的手工抽查」变成「CI 里的自动回归门禁」。核心结论来自可验证的公开论文与开源项目。

2026 年 7 月末，两件事把「LLM 路由」推到了聚光灯下：Manifest 发表《Everyone is building LLM routers, we deprecated ours》在 Hacker News 拿到 130+ 分；Techstrong 则断言 LLM 路由器「已经从 niche 基础设施技巧变成主流产品品类」。Cursor 上线了 Cursor Router，Ramp 把内部自用的路由系统开放成产品，Meta 被曝在内部开发代号 SwitchBoard 的成本优化平台，YC S26 还出现了 Tokenless 这样的「自动换模型省钱」创业公司。

一面是产品化的火热，一面是亲自下场者（Manifest，一个 LLM 网关公司）的撤退。这篇文章不站队，而是把路由这件事拆开：它到底怎么工作、能省多少钱、隐性成本在哪，以及什么场景下它依然成立。

过去两年我们花了很多精力在「输入端」——prompt engineering、few-shot、结构化输出。但 Agent 规模化之后，真正的瓶颈转移到了上下文（context）本身：怎么把有限、昂贵、会腐烂的上下文，像内存一样管理起来。Anthropic 在 2025 年 9 月发表的《Effective context engineering for AI agents》把这件事正式命名为 context engineering——一门关于「上下文生命周期」的工程学科。

本文不重复「怎么写好 prompt」，而是把上下文当成一种可度量、可压缩、可缓存、可分层存储的资源，讨论四个核心问题：它为什么会烂（context rot）、怎么主动丢弃（compaction）、怎么变便宜（caching）、以及怎么用外部存储补足它（memory hierarchy）。

本文是 AI Agent 技能拆解系列的一篇。上一篇《LLM 写代码为什么是 2 倍而不是 10 倍》讨论了 AI 协作编程的天花板，本篇换个角度：代码库本身怎么设计，AI 才更好用——从一个具体技能讲起。

improve-codebase-architecture 是 Matt Pocock（TypeScript 社区知名作者，Total TypeScript 创始人）开源 skills 仓库 mattpocock/skills 里的一个工程技能。它做的事可以概括成一句话：

扫描代码库找「加深机会」（deepening opportunities），把浅模块改造成深模块，并以可视化 HTML 报告呈现，然后和你逐条深挖。

这不是又一个"找代码异味"的 Lint 工具。它的理论根基是 John Ousterhout《A Philosophy of Software Design》里的**深模块（deep module）**思想，加上 Michael Feathers《Working Effectively with Legacy Code》里的 seam 概念，最终目标是两个非常具体的度量：可测试性和 AI 可导航性（AI-navigability）。