52 篇博文 含有标签「Engineering」

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 工程指南讲了视觉侧，这篇补上听觉侧。

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

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

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

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

2026 年 8 月 17 日，Anysphere 宣布 Origin Code Hosting：Cursor 开始直接托管你的代码，面向所有付费计划用户开放 early beta。Hacker News 当天热度 482 分、374 条评论——但讨论的焦点并不全是"又一个 GitHub 替代品"，更多是"Agent 时代代码托管到底应该长什么样"。

这篇文章不重复发布会通稿，而是从工程视角拆三个问题：Origin 在技术上做了什么、它踩中了 AI 工程的哪个痛点、以及它对现有团队（尤其是自托管/合规敏感的团队）意味着什么。

2026 年 8 月 17 日，Wiz Research 公开了一项针对 Snowflake 的安全研究：他们的自主 AI 安全工具「Red Agent」发现并利用了一个 GitHub Actions 脚本注入漏洞，在无人工干预的情况下拿到了 Snowflake 内部 Jira（snowflakecomputing.atlassian.net）的只读访问权限——覆盖工程、安全合规、漏洞赏金项目的数据。漏洞从上线到被攻破只有 5 天，而引入漏洞的 PR 的 co-author 是 "Copilot Autofix powered by AI"。

对做 AI 工程的人来说，这是一次教科书级的「反噬」案例：AI 写代码的能力正在快速商品化，但 AI 生成代码的安全治理才刚刚开始。这篇文章把整个事件拆开：漏洞怎么来的、为什么做了 sed 转义还是被注入、Red Agent 如何从执行报错里自我纠错完成利用、以及工程上到底该加哪些护栏。

前两篇分别聊了向量数据库选型（向量数据库选型对比）和检索链路的分块/重排序（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 倍——就是把这笔账砍下来的三条路。