LLM Inference

如果你只看标题，TurboFieldfare 很容易被误读成又一个“神奇压缩模型”的项目：26B 参数，2GB 内存，任意 M 系列 Mac 都能跑。 我一开始也有点怀疑。因为做过本地推理的人都知道，内存不会凭空消失。模型权重、KV cache、运行时缓冲区、系统占用，哪一项都不是靠一句“优化”就能省掉的。真正值得研究的地方不是“它怎么把 14GB 变成 2GB”，而是它愿意用什么代价换掉这部分内存。 答案很工程化：TurboFieldfare 没有把完整模型塞进内存，而是把 Gemma 4 26B-A4B 的共享权重和 KV cache 留在内存里，把路由专家权重放在 SSD 上，每生成一个 token 时只读取当前会用到的专家。项目 README 明确说，它面向 Apple Silicon，用 Swift 和 Metal 写了一个模型专用 runtime，不是 MLX 或 llama.cpp 的薄封装。HN 上这条 Show HN 也拿到了很高讨论度，说明大家真正关心的是同一个问题：本地大模型推理，能不能从“必须买大内存机器”变成“接受慢一点，但普通机器也能跑”？ 项目地址在这里：drumih/turbo-fieldfare，HN 讨论记录可见 HN Algolia 条目 49098510。我建议先把它当成一个外存推理实验看，而不是马上当成生产推理引擎看。 它省的不是模型大小，而是常驻内存 TurboFieldfare 选择的模型是 Gemma 4 26B-A4B 的 4-bit 指令版本，权重来源是 Hugging Face 上的 mlx-community/gemma-4-26b-a4b-it-4bit。按项目文档，它的文本部分安装后大约 14.3GB，但运行时常驻内存主要是 1.35GB 的共享权重、FP16 KV cache 和一些工作缓冲区。 关键在 A4B 这个 MoE 结构。Mixture-of-Experts 模型并不是每次都激活所有专家。TurboFieldfare 的系统设计文档写得很细：每层有 128 个 routed experts，router 每个 token 选择 8 个；同时还有 dense shared expert 分支。于是它把“专家权重”从常驻内存里拆出来，按层存成文件，推理时用显式 pread 把当前 token 需要的专家读进缓存槽。 ...

如果只看标题，“在 8 美元微控制器上跑 LLM”很容易被误读成又一个玩具式 demo：模型很小、输出几句童话、离 ChatGPT 差十万八千里。 但我反而觉得这个项目值得认真看。原因不是它能在 ESP32-S3 上聊天，而是它把一个越来越重要的工程问题讲得非常直白：当算力不是最大瓶颈，内存层级才是决定模型能不能落地的关键。 HN 这两天热度很高的 esp32-ai 做了一件很极端的事：把一个 28.9M 参数的小语言模型放到 ESP32-S3 N16R8 上运行。这个芯片大概 8 美元，只有 512KB SRAM、8MB PSRAM、16MB flash。项目 README 给出的公开数字是：模型 4-bit 后约 14.9MB，端到端速度约 9.5 token/s，完全离线运行，不把输入发到服务器。 这当然不是一个通用助手。README 也说得很克制：模型用 TinyStories 训练，只会生成短故事，不能问答、不能写代码、也没有事实知识。换句话说，它的产品能力并不重要。 真正重要的是：它证明了“参数量”不一定等于“必须常驻高速内存”。 别急着问它能不能替代云端模型 我以前看边缘 AI 项目，最容易犯的一个错误是上来就问：“这个东西能不能替代大模型？”答案几乎永远是否定的，然后讨论就结束了。 但这次应该换个问法：如果一个模型的很多参数并不是每个 token 都需要完整读取，那我们能不能把这些参数放到更便宜、更慢、但容量更大的存储层里？ ESP32-AI 的设计核心就是这个问题。 项目作者借用了 Google Gemma 系列里的 Per-Layer Embeddings 思路。Gemma 3n 文档把它描述为一种面向端侧设备的效率设计：把部分模型容量做成按需访问的 embedding 结构，而不是让所有权重都以同样方式参与每一步计算。ESP32-AI 更进一步，把这个想法搬到了微控制器的内存布局里。 用人话说就是：别把整个模型都塞进“办公桌”上。常用的小核心放桌面，偶尔查的巨大词表放书架；每次只抽几页出来看。 在 ESP32-S3 上，这个“办公桌”是 512KB SRAM，“书架”是 flash。项目 README 里的分层很清楚：SRAM 放小的计算核心，PSRAM 放输出头和工作区，flash 放 25M 参数级别的 PLE table。每个 token 只需要从 flash 取大约 450 字节，而不是把 12MB 级别的表整块搬进快内存。 ...

如果你关注 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 专家上效果可接受。 ...