李科燃的主页

买 GPU 的时候，大多数人盯着的是 FLOPS。A100 312 TFLOPS，H100 989 TFLOPS，H200 更高。这个数字直观，好对比，销售材料里也总是把它放在最显眼的位置。 但如果你真的跑过 LLM 推理，会发现一件让人困惑的事：你的实际算力利用率（MFU）往往只有 30%~50%，有时更低。剩下的一半算力去哪了？ 答案通常不是”代码写得烂”，而是内存带宽先到顶了。 Roofl

过去两年，”Scaling Law 是否失效”的讨论反复出现。支持者说模型能力还在上升，质疑者说边际效益在递减。但争论的焦点已经悄悄从训练时计算转移到了推理时计算。 o1 是这个转变的公开标志。它的核心逻辑是：与其在训练时堆更多 token，不如在推理时给模型更多”思考时间”。这个逻辑在 2025 年被反复验证和复现——DeepSeek-R1、Gemini 2.0 Flash Thinking、C

WebAssembly 在浏览器里已经算是成熟技术了。Figma 用它跑渲染引擎，Google Earth 用它处理地图，AutoCAD 用它把 C++ 代码跑在 Web 上。这些用例已经足够有说服力。 但浏览器内的成熟，并没有自动带来服务端的成熟。过去几年，”WASM 将改变服务端架构”的说法一直在流传，但实际落地情况远比叙事克制。 它到底在服务端做什么服务端使用 WASM 的核心逻辑是隔离。

过去三年，AI 编译器领域密集地涌现了一批工具和框架。Triton、OpenXLA、MLIR、TVM、Halide 改进版……每隔几个月就有一篇论文或一个新项目声称”让工程师用高层语言写出接近手写 CUDA 的性能”。 这个承诺很诱人，因为 CUDA 手写 kernel 是一件极度依赖专家经验的事。但现实是：这些工具在生产环境里的落地进展，远比 demo 和论文里展示的要慢。 承诺和现实之间的缝隙

RISC-V 这几年被讲得很多，但讲法两极分化：要么是”开放指令集将改变一切”，要么是”永远只能跑嵌入式”。两种说法都不够准确，但合在一起，大概勾勒出了它真实的处境。 它从哪里来RISC-V 诞生于 2010 年加州大学伯克利分校的一个课堂项目。设计者的出发点很简单：需要一个干净的指令集做研究，但 x86 太复杂、ARM 授权太贵，所以干脆自己设计一套，并且开放出来。 这个决定的意义，在当时没人意

工具是 Agent 能力的物理边界。一个 Agent 能做什么，本质上取决于它有哪些工具、这些工具设计得怎么样。 工具设计这件事，在大多数 Agent 系统里是被严重低估的工程问题。常见的实现方式是：把现有的函数或 API 包一层，写个描述，往 Agent 里一扔，能跑就好。到了生产，问题集中爆发——模型频繁选错工具，工具被错误参数调用，错误处理逻辑让 Agent 陷入循环，token 成本居高不

“Context Engineering”这个词在过去一年里被提及的频率越来越高。 Andrej Karpathy 在 2025 年说过一句话，大意是：Prompt Engineering 这个词已经低估了真实的工程问题——真正的挑战不是怎么写出漂亮的 prompt，而是怎么在 context 窗口有限的情况下，在正确的时刻，把正确的信息放进去。他把这称为 Context Engineering。

大多数团队发现成本问题的时机都太晚。 Demo 阶段，一次 Agent 运行消耗几分钱，团队觉得 LLM API 成本完全可控。到了生产，加上完整的系统提示、跨会话记忆检索、多轮工具调用之后，同一个任务的成本变成了几块钱。用户量稍微上来，账单就开始让人难受。 这不是”规模化的代价”，这是架构问题——只是在生产环境里才暴露出来。 Token 消耗的结构解决成本问题之前，先把钱花在哪里说清楚。 一次典

每次更新模型版本、调整工具描述、修改系统提示，你是怎么判断 Agent 变好了还是变坏了的？ 大多数团队的诚实回答是：看感觉。手动跑几个典型任务，主观判断一下，没有明显退步就上线。 这在 demo 阶段可以接受。在生产里，它意味着你对 Agent 的质量没有任何客观感知——你是在蒙眼开车。 为什么传统软件测试在 Agent 上失效软件工程里的单元测试，基础假设是确定性：给定相同输入，函数返回相同输

传统 LLM 应用的安全问题，主要是输出质量问题：模型说了不该说的话，或者被诱导输出了有害内容。这类问题的影响范围，大致等于”一个人能说的话”的影响范围。 Agent 系统的安全问题性质不同。当 LLM 拿到了工具——可以写文件、调 API、执行代码、提交代码库、发送消息——“输出”就不再是文本，而是真实世界里的行动。影响范围不再是”一个人能说的话”，而是”一个人能做的事”的量级。 这个差异是根本