LLM Inference

如果你关注 GPU 编程和 AI 基础设施，最近应该注意到一个趋势：Rust 正在悄悄渗透进 GPU 开发的每一个角落。NVIDIA Labs 在同一时间开源了两个 Rust GPU 项目——cuda-oxide（2768 stars）和 cuTile Rust（381 stars），前者是把标准 Rust 代码直接编译成 PTX 的 rustc 后端，后者是我们今天要聊的主角：一个基于 tile 抽象的安全 GPU 内核编程系统。 坦白说，第一次看到 cuTile Rust 的 README 时我有点不以为然——又一个 DSL？但读完论文 Fearless Concurrency on the GPU 之后，我的看法变了。这不是简单的语法糖，而是认认真真地把 Rust 的所有权和借用检查搬到了 GPU 内核层面。 问题：GPU 内核编程为什么需要安全？ 写 CUDA 内核的人大概都踩过这些坑：线程越界访问 shared memory、race condition 导致结果随机出错、异步 kernel launch 后 host 端提前释放了显存。传统 CUDA C++ 对这类问题基本靠程序员自觉——你犯了错，程序不会告诉你，只会给你一个错误结果或者 segfault。 cuTile Rust 的核心思路是：既然 Rust 在 CPU 端已经用所有权系统解决了数据竞争问题，为什么不能把这个保证延伸到 GPU 端？ ...

一个万亿参数的模型，在 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 的做法是选择性量化： ...

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 星，最新提交就在今天。 ...

前几天看到 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 倍。这就是为什么他们敢说"可以在手机上跑"——不是噱头，是真的把模型缩小到了手机内存能装下的程度。 ...

如果你还在用“这张卡有多少 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。上下文越长、并发越高，显存容量和带宽压力越明显。 ...

本地 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。 ...

如果你正在做 AI Agent，有一个问题很容易被忽略：Agent 到底需不需要一个很大的模型来“选择工具”？ 我以前默认答案是“需要”。毕竟工具调用看起来像推理：用户说“明天早上 8 点提醒我带伞”，模型要理解意图、找到日历或提醒工具、抽取时间、地点和参数，最后输出一段合法 JSON。让 7B、14B 甚至更大的模型来做，似乎很自然。 但这两天 HN 上的 Needle 把这个直觉反过来了。Cactus 团队开源了一个只有 26M 参数的 function calling 模型，README 里说它是把 Gemini 3.1 的工具调用能力蒸馏到一个 “Simple Attention Network” 上，目标是跑在手机、手表、眼镜这类消费设备上。项目目前 MIT 开源，代码在 cactus-compute/needle，权重放在 Hugging Face。 26M 是什么概念？比很多 embedding 模型还小，比常见的 0.5B/1.5B 小模型又小一个数量级。它不打算写诗、聊天、做数学题，只做一件事：给定用户 query 和工具 schema，吐出应该调用的工具及参数。 坦白说，我觉得这个方向比“又一个端侧聊天机器人”更值得写。因为生产里的 Agent 系统，最先遇到瓶颈的往往不是“模型不够聪明”，而是“每一步都太贵、太慢、太不稳定”。 把工具调用从“推理”降级成“路由” Needle 的核心判断很激进：单轮工具调用本质上不是开放式推理，而是 retrieval-and-assembly。 用人话说，就是三步：先从工具列表里匹配哪个工具最像用户意图；再从用户句子里抽参数；最后按 schema 拼成 JSON。这个过程当然需要语言理解，但它未必需要一个装满世界知识的大模型。工具说明和参数 schema 已经作为输入给了模型，事实知识在上下文里，不必塞进 FFN 权重里。 这也是它的架构为什么反常。Needle 的 Simple Attention Networks 文档 里明确写到：实验发现，如果任务依赖外部结构化知识，Transformer 里的 MLP/FFN 可以被完全拿掉，模型主要靠 attention 和 gating 工作。Needle 的结构是 12 层 encoder 加 8 层 decoder，隐藏维度 512，8 个 attention head，BPE 词表 8192；README 还强调 “no MLPs anywhere”。 ...

如果你已经在本地跑过大模型，应该很熟悉这个循环：先等通用推理框架支持新模型，再等量化格式稳定，再等各种 wrapper 把 API、工具调用、流式输出补齐。等一切能用时，下一代模型又来了。 所以我看到 Hacker News 上 DeepSeek 4 Flash local inference engine for Metal 这条讨论时，第一反应不是“又一个本地 LLM 项目”，而是：它把通用框架的路线反过来了。 ds4.c 不是一个新的 llama.cpp 替代品，也不是 Ollama 那种“模型管理 + 服务封装”。README 开头就把边界画得很死：它是一个只服务 DeepSeek V4 Flash 的原生推理引擎，主路径是 DeepSeek V4 Flash 专用的 Metal graph executor、DS4 专用加载器、prompt rendering、KV state 和 server API glue。换成人话说，它不是想做“什么模型都能跑”，而是想把一个特定模型在 Apple Silicon 上榨干。 坦白说，我挺喜欢这种不讨好所有人的设计。因为本地推理这件事，很多时候不是缺一个更漂亮的客户端，而是缺一条足够明确的工程假设。 “窄引擎”到底在赌什么 通用推理框架的优势很明显：模型覆盖广、社区大、格式生态成熟。比如 llama.cpp 已经是 GGUF 世界的事实底座，GitHub API 显示它仍在高频更新，star 超过 10 万。Hypho 之前写过 本地 LLM 推理引擎之争，核心判断也是：如果你要严肃做本地部署，底层引擎的透明度和社区活跃度比“安装是否一行命令”更重要。 但通用性有代价。 一个框架要支持几十种架构，就很难为某个模型的奇怪结构做激进假设。ds4.c 选择了另一边：它接受自己只能跑 DeepSeek V4 Flash，换来对这个模型的深度适配。项目 README 里列出的几个卖点很有代表性：DeepSeek V4 Flash 的 active parameters 更少；thinking 模式下推理段落更短；上下文窗口达到 1M tokens；KV cache 可以高度压缩并持久化到磁盘；2-bit 量化在特定 MoE 专家上效果可接受。 ...

如果你最近还在把“LLM 推理优化”等同于量化，我建议停一下。 量化当然重要，尤其是本地部署和消费级 GPU 场景。但 Google 刚发的 Gemma 4 多 token 预测（Multi-Token Prediction, MTP）让我更确信一件事：下一轮推理加速的主战场，不只是在“把模型压小”，而是在减少大模型被调用的次数。 Google 在官方博客里说，Gemma 4 通过 MTP drafters 在推理阶段最高可以做到 up to 3x faster。这个数字本身很抓眼球，但我更关心它背后的工程含义：如果草稿器能一次猜中多个后续 token，大模型就不必老老实实一个 token 一个 token 地跑完整前向传播。 说白了就是：以前是大模型每吐一个字都要“亲自审批”；现在是小模型先写一小段，大模型批量盖章。 为什么“一个 token 一次前向”这么浪费 自回归 LLM 的默认解码方式很朴素：给定上下文，预测下一个 token；把这个 token 拼回上下文，再预测下一个。这个循环看起来合理，但对硬件很不友好。 每生成一个 token，模型都要访问大量权重。对于 27B、70B 这种规模，瓶颈往往不是矩阵乘法算不动，而是显存带宽和调度开销被小步循环吃掉。你可以把它理解成：GPU 明明适合一次搬一大车货，结果我们让它每次只送一个快递。 这也是为什么我之前写 DFlash + DDTree 投机解码 时，最看重的不是某个 benchmark 数字，而是“平均接受长度”。只要一次验证能接受更多 token，大模型前向次数就会下降，吞吐自然上来。 Gemma 4 的 MTP 走的是同一条大方向，但实现路径更靠近模型训练本身。 传统 speculative decoding 通常需要一个独立的小 draft model。经典论文 Speculative Sampling 的思路就是：小模型先生成候选，大模型并行验证，最后用修正过的采样过程保证输出分布不变。这套方法很漂亮，但工程上有两个麻烦：你要维护两个模型，还要处理 tokenizer、KV cache、调度和显存布局。 MTP 的反直觉之处在于，它不一定非要靠“另一个完整小模型”来猜。Meta 的论文 Better & Faster Large Language Models via Multi-token Prediction 提出，在训练时让模型不只预测下一个 token，而是同时预测未来多个 token。技术上可以看成在共享 trunk 上接多个输出 head，训练目标从“只看一步”扩展到“顺手看几步”。 ...

一个 27B 参数的大模型，在一张 2021 年买的游戏显卡上能跑多快？ Lucebox 团队给出了一个让很多人没想到的数字：207.6 token/s。用的还是 Qwen3.5-27B 官方模型，不是蒸馏，不是 INT8 量化残血版——就是 Q4_K_M 量化版本，目标加草稿模型全部加载在一张 24 GB VRAM 的 RTX 3090 上。 这个成绩靠的不是等英伟达下一代消费级显卡，而是对解码算法本身动刀子。 为什么自回归解码是瓶颈 大多数人聊 LLM 推理优化，会先想到量化、KV cache 压缩、batch 并行。但对单卡消费级 GPU 来说，这些都已经做到头了——Q4_K_M 量化能压缩到约 16 GB，再压下去效果肉眼可见地降。 问题出在自回归解码本身。每生成一个 token，GPU 要完整跑一遍 27B 参数的前向传播。27B 参数在 Q4_K_M 下大约 16 GB，VRAM 带宽是 936 GB/s——每次解码都要把这 16 GB 从显存读一遍，理论带宽利用率撑死不到 20%。这是机械式的物理限制，不是软件优化能绕过去的。 speculative decoding（投机解码）解决的就是这个问题：用一个小草稿模型一次生成多个候选 token，再用大模型一次验证整串。如果草稿猜得准，大模型只跑一次就能吐出五六个 token，GPU 计算资源用得更充分。 DFlash：块扩散草稿，比 Chain EAGLE 更容易命中 主流投机解码方案是 EAGLE（及其 chain 版），草稿模型做自回归预测，每步大约能接受 3 个 token。DFlash（2026） 换了个思路：用块扩散（block diffusion） 做草稿——一个 5 层非因果的去噪网络，同时预测多个位置，而不是逐个生成。 ...