Day 76 · 自部署推理:vLLM / SGLang 上线一个开源模型
把一个开源模型跑成 OpenAI 兼容接口,让 SupportPilot 改一个环境变量就能调用。先算清楚什么时候值得自部署,再用显存账解释 vLLM 为什么快,最后用压测工具量出吞吐和延迟,把昨天 TCO 里空着的那一项填上。
把一个开源模型跑成 OpenAI 兼容接口,让 SupportPilot 改一个环境变量就能调用。先算清楚什么时候值得自部署,再用显存账解释 vLLM 为什么快,最后用压测工具量出吞吐和延迟,把昨天 TCO 里空着的那一项填上。
评测集和 benchmark 的区别,在于后者要让别人也能复现、也信得过。今天拆解 τ-bench 和 SWE-bench 是怎么造出来的,再看 2025 年那篇 benchmark 体检论文发现的问题:τ-bench 里一个只会回空话的 Agent,在不可能完成的航空任务上拿了 38%,比 GPT-4o 还高。然后给 SupportPilot 设计 CloudLedger-Bench:环境快照、按最终数据库状态判分、参考解和空 Agent 双重自检、防污染金丝雀串、版本规则,并用代码抓出两个藏着 bug 的任务。
把测带宽、测算力、画 roofline、扫 batch、对比标称这五天压成一页笔记:每一步的公式、预期区间和坑放在一起。合上笔记做路线图 W3 的五道验收题,再把这周最容易测错的地方一条条摊开。屋顶从这周起是自己测的,不是抄的。
昨天测了斜线,今天测屋顶。用大方阵矩阵乘法把 T4 真正能算多快测出来:FLOPs = 2MNK 除以时间。坑比带宽多:矩阵不够大打不满、fp32 的标称是另一个数、fp16 要真走 tensor core 才对得上 65 TFLOPS、A100 的 624 是稀疏值。顺手算出方阵多大才跨过 ridge point。
W3 开工。标称 320 GB/s 是纸面数字,今天用一次最简单的逐元素加法,把 T4 真正能搬多快测出来,再把这个实测值装回 Day 5 的 decode 下限公式里。顺手踩清三个坑:字节只算读没算写、张量小到落进 L2、没 synchronize。
CPU 把 kernel 扔进队列就往下走,GPU 在后面慢慢干。不加 synchronize,perf_counter 测到的是「派活的时间」,不是「干完活的时间」,能差几个数量级。今天把这件事画成时间线,对比两种正确的计时法,把 Day 7 的计时代码改成以后一年都用的最终版。