Posts

一个万亿参数的模型，在 8 张消费级 GPU 上每秒吐出 1000 个 token——这件事本身并不新鲜，因为类似数字过去只在论文 demo 或特制硬件上见过。但小米 MiMo 团队和 TileRT 推出的 MiMo-V2.5-Pro-UltraSpeed，用的是商品化 GPU、开源推理框架、没有定制芯片。这就有意思了。 更关键的是，实现这个速度的路径不是"把量化做狠一点"或"投机解码多猜几个 token"这么简单。它触及了一个更根本的问题：当推理系统逼近硬件物理极限时，模型架构和推理引擎必须从设计阶段就开始同步进化，而不是各自优化完再拼到一起。 这篇拆解 MiMo × TileRT 做了什么，以及"Speed Scaling"作为新范式到底意味着什么。 万亿参数推理为什么特别难 先说背景。MoE（Mixture of Experts）架构让万亿参数模型在训练端变得可行——每次前向传播只激活一小部分参数，推理时的计算量远低于密集模型。但推理端有一个不太一样的瓶颈：显存带宽。 一个 1T 参数的 MoE 模型，即使只激活几百亿参数，完整的权重还是得住在 GPU 显存里。用 FP16 加载需要 2TB 显存，8 张 80GB H100 只有 640GB，根本装不下。即使用 FP8（1TB），仍然超出单节点容量。 这意味着推理速度的瓶颈不在计算，而在数据搬运——每生成一个 token，GPU 都要从显存读取相关权重，读取速度直接决定生成速度。业界称之为"Memory-Bound"场景，token/s 的上限 = 显存带宽 / 每 token 需要读取的字节数。 所以，要让 1T 模型跑快，核心就两件事：减少每次搬运的数据量，和减少搬运次数。 第一层：FP4 选择性量化——不是所有参数都值得用低精度 减少数据量最直接的方法是量化。MiMo-V2.5-Pro 采用的是 OCP Microscaling (MXFP4) 格式——一种 Microsoft 主导的 FP4 标准，在极低比特下保持数值稳定性。 但关键不是"全模型 FP4"。如果暴力把所有层都压到 4 bit，模型在复杂推理、代码生成等任务上会出现明显退化。MiMo 的做法是选择性量化： ...

最近 HN 上有篇帖子引起了我的注意：一个叫 Lathe 的开源项目，247 points，标题是"Use LLMs to learn a new domain, not skip past it"。 说实话，看到这个标题的第一反应是：又一个 LLM 教学工具？市面上这类东西已经太多了——NotebookLM、各种 AI tutor、ChatGPT 自己就能教你任何东西。但仔细看完 README 和 HN 评论区之后，我觉得这个项目抓住了一个很多人没说出口的痛点。 问题出在哪？ 过去一年，“Vibe Coding"这个概念从 Andrej Karpathy 的一条推文变成了整个行业的主流工作方式。打开 Claude Code、Cursor 或者 Copilot，描述你想要什么，AI 帮你生成代码，你负责 Review 和微调。效率确实高，但这里有一个很少被正面讨论的问题：你到底学到了什么？ HN 上另一篇今天 807 points 的帖子——“LLMs are eroding my software engineering career”——把这个焦虑写得很直白。一位资深工程师说，LLM 正在侵蚀他的软件工程职业，他不知道该怎么办。评论区里各种声音都有，但核心矛盾其实就一个：当 AI 代劳了思考过程，工程师的价值在哪里？ 这不是杞人忧天。看看现在的 AI 编程成本追踪工具（比如 Budi）就知道，很多团队每个月在 AI 编程上的开销已经不小了。但如果你问这些开发者"你从 AI 生成的代码里学到了什么”，大部分人会沉默。 Lathe 的反直觉设计 Lathe 的作者 Deven Jarvis 在 README 里写了一段很长的个人经历，我读完觉得挺真诚的。他在 2000 年代通过 PSP 自制游戏社区学会了编程，后来通过各种 hands-on 教程（build-your-own-x、Crafting Interpreters 这类）不断精进。他说这些教程给他的不只是知识，更是"从零到一"的信心和继续深入的底气。 ...

AI 芯片为什么越来越像内存生意？从 HBM 成本看 LLM 推理的真正瓶颈 Gemma 4 的多 token 预测：LLM 推理加速不该只盯着量化 KV-cache 量化为什么一直"不敢开" 做过 vLLM 生产部署的人大概都纠结过一个问题：context 越来越长，KV-cache 吃掉的 GPU 显存越来越多，但官方文档里那个 --kv-cache-dtype 参数，你真的敢在生产环境打开吗？ vLLM 团队今年 5 月发了一篇 TurboQuant 的系统性基准测试1，结论相当诚实：除了 FP8 之外，所有 KV-cache 量化方案都在"拿吞吐量换容量"。具体来说： TurboQuant 4bit-nc：最高 3.4 倍 KV-cache 容量，但吞吐量损失 40-52%，延迟增加最高 60% TurboQuant 3bit-nc：精度大幅下降，推理和长上下文任务表现尤其差 FP8：2 倍容量，吞吐量基本无损，但容量增幅有限 说白了就是：你要么选 FP8（安全但只翻倍），要么选更激进的量化（容量大但吞吐暴跌）。在推理密集型场景——比如长上下文 Agent、代码生成、数学推理——吞吐量下降意味着请求排队变长、用户等待变久，这在生产环境是不可接受的。 所以 vLLM 官方的建议一直是：默认用 BF16，显存不够就用 FP8，其他量化方案慎用。 这就是 KVarN 想解决的问题。 KVarN 是什么：华为的 KV-cache 量化新方案 KVarN（读作 /kvɑːɳ/，瑞典语"研磨机"的意思）来自华为通讯系统实验室（Huawei CSL），论文在 arXiv 上2，代码以 Apache 2.0 开源在 GitHub3，目前 196 星，最新提交就在今天。 ...

做 RAG 的人大多有个盲区：眼睛只盯着文字。 你花了两周调 chunk size，换了三种 embedding 模型，reranker 也加上了——《Rerank 在 RAG 中的角色：Bi-Encoder vs Cross-Encoder》里讲的那些优化你全做了。但回头一看，技术文档里的截图、架构图、参数表格，这些图片承载的信息，你的系统压根没碰。 这不是小问题。kapa.ai 的团队最近在 Hacker News 上分享了他们的生产实践（89 points），标题直白：How we index images for RAG。他们服务 200+ 客户，知识库里有数百万张图片，每天处理百万级查询。这篇文章把他们的方案拆开来看，顺便聊聊 ColPali 等另一条路线，以及你到底该选哪条。 图片在技术文档里到底干了什么 kapa.ai 把文档图片分成两类，这个分类非常实用。 说明型（illustrative）：文字说"点击设置图标"，旁边的截图标出了图标在哪、长什么样。图片让答案更直观，但信息本身在文字里也有——用户不看图也能做事，只是要多找一会儿。 承重型（load-bearing）：接线图、参数规格表、认证矩阵、颜色可选表——这些图里的数值只存在于图片中。你不看图，就根本不知道答案。 他们跑了上千条真实客户问题验证：有图片上下文时，LLM 评委（McNemar 检验，p < 0.05）显著偏好带图片的答案。效果不是微调能弥补的那种——是用户能感知到的质变。 但问题来了：怎么把这些图片喂给 LLM？ 查询时看图：一个看起来对、实际上贵到用不起的方案 直觉反应是：检索到相关 chunk 后，把它们引用的图片一起丢给多模态模型（GPT-5.1、Claude 4.6 Sonnet 等）。kapa.ai 测试了这个方案，发现三个结构性问题： 1. 贵得离谱。 原始图片让 GPT 单次查询成本增加 27%，Claude 增加 51%（Claude 把一张图编码成约 975 tokens，GPT 约 716）。kapa.ai 每天百万级查询，这笔钱根本花不起。 2. 塞不进去。 一个典型问题检索 10-30 个 chunk，平均引用 20-30 张图片，长尾能到 130 张。Claude 的 payload 上限 30 MB，OpenAI 的 50 MB——超过 20 张图就撞墙了。 ...

前几天看到 PrismML 发布了 Bonsai Image 4B，声称可以在 iPhone 上本地跑图像生成，我的第一反应是"又一个宣传噱头"。毕竟图像生成模型动辄几个 GB，Diffusion Transformer 的计算量比文本 LLM 大得多，怎么压缩到手机能跑？ 但仔细看了他们的技术方案和社区基准之后，我改了主意。这不是简单的模型量化，而是从训练阶段就用 1-bit 权重做端到端训练——换句话说，模型天生就是"压缩态"的，不是训好之后再硬压。 这和我们之前讨论过的推理优化路线完全不同。量化只是推理阶段的事，但 PrismML 的思路是：让模型在训练时就接受 1-bit 的约束，这样精度损失是渐进的，而不是事后的暴力截断。 从 Bonsai-8B 到 Bonsai Image：一条技术路线的延伸 PrismML 这家公司来头不小——脱胎于 Caltech 研究，拿了 Khosla Ventures、Cerberus 和 Google 的投资。他们今年 3 月发布的 Bonsai-8B 是全球第一个"商业可行的 1-bit LLM"，整数权重只有 {-1, 0, +1} 三种取值。 用人话说就是：传统模型的每个权重参数是一个 16 位浮点数，占 2 字节。Bonsai 的每个权重只占 1 bit（甚至 ternary 版本约 1.58 bit）。一个 8B 参数模型，FP16 版本要 16 GB 内存，Bonsai-8B 只要 1.15 GB。 这个压缩比有多大？14 倍。在 RTX 4090 上推理速度提升 6.2 倍，能耗降低 4-5 倍。这就是为什么他们敢说"可以在手机上跑"——不是噱头，是真的把模型缩小到了手机内存能装下的程度。 ...

如果你正在用 LLM 做事实核查、内容审核或者知识问答系统，有一个问题你大概率回避不了：当多个模型对同一条声明给出判断时，它们的答案到底能不能互相印证？ 答案可能比你想象的更令人不安。 Lenz Research 在 2026 年 5 月发布了一份名为《Beyond Benchmarks: Frontier LLM Disagreement on Real-World Fact-Checks》的快照研究（Snapshot v1.0），用 1,000 条真实用户提交的事实声明，让五款顶级前沿 LLM 各自独立判断真假。结论很直白：67% 的声明，至少有一个模型的判断与多数派相左——要么没有形成多数共识，要么有模型直接唱反调。 这可不是 benchmark 刷分游戏。这些声明来自真实用户提交给 Lenz 事实核查平台的请求，涵盖健康、科学、政治、金融、法律、技术等领域。没有公开的答案库，没有排行榜可以 pattern-match。 研究设计：五个模型，一千条声明，强制四选一 测试对象是当前公认的五款顶级模型：GPT-5.4、Claude Opus 4.7、Gemini 3 Pro、Gemini 3 Pro + Search（带 Google 搜索增强）、Sonar Pro（Perplexity 的搜索增强模型）。 每条声明被提炼成一个中立的、可检验的命题（Lenz 称之为"framing step"——剥离情绪化表达和偏见，只保留核心事实主张），然后要求每个模型从四个选项中强制选择一个：True、Mostly True、Misleading、False。 注意两个关键设计决策： 强制选择，不允许弃权。没有"我不确定"这个选项。这保证了对称比较——如果允许 Abstain，搜索增强模型可能通过大量弃权来"提高准确率"，但那就不是同一场比赛了。 不做 ground truth 对比。研究的视角不是"哪个模型更准确"，而是"模型之间有多不一致"。多数派意见不等于正确答案，少数派也不等于错误——但分歧本身就是一个值得重视的信号。 核心发现：三分之二的声明，模型们吵起来了 数据很清晰： 67% 的声明（672/1,000，95% CI: 64–70%）存在至少一个模型与多数派分歧 34% 的声明（343/1,000）涉及 2 个以上桶位的实质性分歧——不是 True 和 Mostly True 之间的细微差异，而是 True 和 False 之间的根本对立 21% 的声明（211/1,000）出现极端对峙：一个模型说是 True，另一个说是 False 只有 33% 的声明达成五方一致 用 Krippendorff’s α（序数版）衡量五个评分者的一致性，得到 0.639——说白了就是"有结构，但远不够可靠"。如果你让五个实习生做同一批事实核查，交上来的结果差异这么大，你大概不会直接发布。 ...

你有没有想过，为什么人类需要睡觉？ 不是为了休息——肌肉放松不需要 8 小时。神经科学的答案是：记忆整合。白天经历的海量信息在睡眠中被大脑重新激活、压缩、筛选，重要的写入长期记忆，不重要的被丢弃。没有这个过程，新的学习会覆盖旧的记忆，认知系统逐渐崩溃。 如果把这个逻辑搬到 LLM 上呢？ Transformer 的注意力机制本质上是一个"永不睡觉"的系统——所有上下文都堆积在 KV Cache 里，每来一个新 token 就要和所有历史 token 做注意力计算。上下文越长，计算量呈二次方增长，内存占用线性膨胀。这和大脑在不睡觉时的状态惊人地相似：信息不断涌入，但没有一个"离线整合"的机制来压缩和提炼。 最近，CMU 和 Maryland 的研究团队在 Arxiv 上发了一篇论文 “Language Models Need Sleep”（2605.26099），正式把"LLM 需要睡觉"这个直觉变成了可验证的工程方案。更有趣的是，Letta 团队早在今年 4 月就提出了一个互补的思路 “Sleep-time Compute”（2504.13171），从推理优化的角度证明了"让模型在空闲时提前思考"能大幅降低推理成本。 两篇论文，两个角度，指向同一个结论：AI 系统需要一个类似"睡眠"的机制来处理信息过载。 瓶颈不在记忆容量，而在计算深度 “Language Models Need Sleep” 这篇论文的出发点很直接：现有的 SSM-Attention 混合模型（比如 Mamba-Transformer 混合架构）虽然通过固定大小的快权重（fast weights）解决了长上下文的内存问题，但记忆容量不等于推理能力。 论文作者做了一个干净的实验：他们让 SSM-Attention 混合模型做多跳图检索（multi-hop graph retrieval）和元胞自动机（cellular automata）推理，控制信息量不变，只增加推理深度。结果发现：随着推理深度增加，模型性能显著下降。 这意味着什么？当 KV Cache 被滑动窗口策略（sliding window eviction）强制截断后，被驱逐的 token 并没有"消失"——它们被压缩进了 SSM 的快权重里。但快权重只能存储信息，不能对信息做深度计算。就像你把一本书的内容全部压缩成一张图片，虽然信息都在，但你没法在图片上做逻辑推理。 这个发现比之前的研究更进了一步。以前大家认为长上下文的瓶颈是"记不住"，这篇论文证明真正的瓶颈是"算不动"。 睡眠机制：把计算从推理时转移到离线 论文的核心方案叫做 LLM Sleep——一种受神经科学启发的离线递归记忆整合机制。 工作机制很直觉： 清醒阶段（Wake Phase）：模型正常推理，注意力机制处理近期 token，KV Cache 不断增长。 睡眠阶段（Sleep Phase）：模型暂停接收新输入，对积累的上下文执行 N 次离线递归遍历（offline recurrent passes）。 整合阶段（Consolidation）：通过一个学习到的局部规则（learned local rule），将上下文中的关键信息写入 SSM 块的快权重。 清除阶段：整合完成后，清空 KV Cache，释放内存。 再次清醒：模型从"睡眠"中醒来，继续推理，但此时它拥有了一个经过深度处理的压缩记忆。 用人话说就是：模型工作一段时间后，“闭眼"把刚经历的内容反复咀嚼几遍，把重要的东西提炼成一种更紧凑的内部状态，然后把原始的"短期记忆”（KV Cache）清空。这和人类睡眠中的记忆整合过程惊人地相似。 ...

如果你还在用“这张卡有多少 TFLOPS”来判断一套 LLM 推理系统值不值得买，我建议先停一下。 这不是说算力不重要。训练大模型、跑高吞吐推理，当然离不开矩阵乘法能力。但最近 Hacker News 上一篇 Epoch AI 的芯片成本拆解很值得看：他们估算，在 Nvidia、AMD、Google、Amazon 等 AI 芯片的组件成本里，高带宽内存 HBM 的占比已经从 2024 年一季度的 52% 上升到 2025 年四季度的 63%。 也就是说，今天一颗 AI 加速器越来越不像“纯算力商品”，反而更像一块被昂贵内存包围的计算核心。 这个变化对做应用的人也有直接影响。你在云上选 H100/H200，或者在本地纠结 4090、Mac Studio、工作站多卡，并不是在买一个抽象的“AI 能力”。你买的是：模型权重能不能放下，KV cache 能不能撑住上下文，batch size 能不能拉起来，以及 token 流水线会不会被内存带宽卡死。 说白了，LLM 推理的很多瓶颈，最后都会变成内存问题。 HBM 成本占比上升，说明了什么？ Epoch AI 这篇文章的核心数字很简单：HBM 在 AI 芯片组件成本中的占比，从 52% 增长到 63%；同时 logic dies 大约维持在 13%，先进封装和其他辅助组件占比下降。这个结论不是单一芯片报价，而是按生产量加权估算出来的行业平均值。 我不建议把这个数字理解成“GPU 厂商利润被内存厂吃掉了”这么简单。更有用的读法是：产业链正在用真金白银投票，承认 AI 工作负载对内存系统的饥渴程度越来越高。 为什么？因为 LLM 不是只做一次矩阵乘法就结束。 模型推理至少有两类阶段：prefill 和 decode。prefill 阶段要把提示词一次性喂进去，计算密度相对高；decode 阶段则是一个 token 一个 token 往外吐，每一步都要读模型权重，还要读写不断增长的 KV cache。上下文越长、并发越高，显存容量和带宽压力越明显。 ...

我越来越觉得，很多 AI Agent 的问题不在“模型还不够聪明”，而在我们把它们塞进了一个很别扭的接口里：一条聊天消息进来，一条聊天消息出去，中间所有思考、工具调用、观察结果、用户反馈，都被挤在同一条时间线上。 这件事平时不明显。你让模型改一段代码、总结一篇文章，它慢一点、啰嗦一点，问题不大。但一旦进入真正的 Agent 场景，比如浏览器操作、长时间代码修改、后台任务、多人协作，它就开始露馅：模型正在“思考”时没法同时接收新信息，正在“输出”时没法真正读环境变化，正在等工具结果时也没法继续做别的规划。 说白了就是：我们想要一个能并行工作的智能系统，却还在用单线程聊天窗口来驱动它。 最近 HN 上有一篇论文讨论的正是这个问题：Multi-Stream LLMs: Unblocking Language Models with Parallel Streams of Thoughts, Inputs and Outputs。它的分数不算特别夸张，但我觉得比很多“又一个 Agent 框架”更值得写。因为它不是在 prompt 外面再包一层流程图，而是在问一个更底层的问题：LLM 的交互格式，是否已经成为 Agent 能力的瓶颈？ HN 原帖标题也很直接：Multi-Stream LLMs: new paper on parallelizing/separating prompts, thinking, I/O。这不是一个已经成熟可用的工程框架，更像是一份架构提案。但它戳中了生产级 Agent 的一个痛点。 当前 Agent 最大的隐性假设：所有事情都必须排队 今天大多数 Agent 系统，本质上还是 ChatGPT 时代的消息协议： system message 定规则； user message 给任务； assistant message 生成回答或工具调用； tool message 把结果塞回上下文； assistant 再继续。 OpenAI 的 Agents SDK 已经把 handoff、guardrails、tracing、tool calling 封装得很清楚；Anthropic 的 Computer Use 也让 Claude 可以观察屏幕、点击、输入、等待环境变化；MCP 则通过 Model Context Protocol 把外部工具和数据源标准化成可连接的上下文。 ...

本地 LLM 做 Agent，最容易被低估的不是模型能不能回答问题，而是它能不能稳定地把一串工具调用跑完。 这句话听起来有点扫兴。毕竟现在 7B、8B、14B 模型的 benchmark 分数越来越好，Ollama、llama.cpp、llama-server 也把本地部署门槛降到了很低。我之前写过一篇 本地 LLM 推理工具的取舍，当时重点放在推理后端、模型格式和生态锁定上。但如果你真的想把本地模型接进自动化工作流，另一个问题会更快冒出来：模型单步看起来不错，多步之后为什么还是崩？ HN 上这两天有个项目 Forge 很适合拿来讨论这个问题。它的标题很抓人：“Guardrails take an 8B model from 53% to 99% on agentic tasks”。我对这种数字一向谨慎，因为 agentic task 的定义、评测场景和采样参数都会强烈影响结果。但 Forge 真正值得看的地方，不是“8B 追平 frontier model”这个营销点，而是它把本地 Agent 失败拆成了几个非常工程化的小故障：工具调用解析失败、走错步骤、错误恢复失败、上下文预算失控，以及多个工作流争用同一个 GPU 推理槽。 说白了，它不是在训练一个更聪明的模型，而是在给一个不够稳定的模型加流程控制。 为什么本地 Agent 会在多步任务里快速掉队 很多人第一次做工具调用 Agent，会拿一个天气查询、数据库查询或者代码搜索 demo 开始。模型需要做的事情很简单：读用户问题，选择工具，填参数，拿结果，再回答。单步成功率只要看起来有 90%，体验就会很好。 问题出在复合任务上。 假设一个工作流有 5 步，每一步成功率都是 90%。如果这些步骤必须全部正确，整体成功率不是 90%，而是 0.9 的 5 次方，大约 59%。这还是独立错误的理想情况；真实 Agent 里，前一步的轻微偏差会污染后续上下文，错误会复利。 Forge 作者在 HN 发布帖 里也用了类似的“compounding math”解释：本地模型每一步都不算太差，但连续工具调用会把小错误放大成任务失败。这其实是我最认同它的地方。生产环境的 Agent 可靠性，很多时候不是靠“再换一个大模型”解决，而是靠把可控部分从自然语言里拿出来，交给确定性系统。 这也是为什么我会把 Forge 和之前写过的 Statewright 状态机护栏 放在同一类问题里看。Statewright 更偏“限制 Agent 在什么阶段能做什么”，Forge 更偏“当模型工具调用出错时，如何修、如何重试、如何阻止它跳步骤”。两者的共同点是：它们都不再迷信一个超长 system prompt。 ...