Hypho

如果你关注 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 端？ ...

上周，里约热内卢市政府高调发布了名为 Rio-3.5-Open-397B 的大语言模型，官方说法是"由 IplanRIO（里约市政 IT 公司）自主训练的 397B 参数模型"。模型发布后，巴西媒体一片欢腾——这可是全球首个由市政当局发布的前沿级 AI 模型，还号称在多项基准测试中超过了 Qwen 3.7 Plus。 然后，48 小时之内，Nex-AGI（一家来自上海的 AI 实验室）在 GitHub 上发了一条 issue，用两种完全独立的方法证明：这个模型的每一个权重，都是 Nex-N2-Pro 和 Qwen3.5-397B-A17B 按 6:4 比例线性混合的结果。 不是微调，不是蒸馏，是直接把两个模型的权重按比例倒在一起。 身份探针：去掉系统提示词后，模型自己说了实话 Rio-3.5-Open-397B 附带了一个硬编码的系统提示词：“You are Rio, a large language model developed by IplanRIO。“这个提示词在每次推理时都会被注入，强制模型"记住"自己的身份。 Nex-AGI 做了一件很简单的事：把这个系统提示词删掉，然后问模型"你是谁”。 他们在去除了身份强制的情况下，向 Rio 的部署端点发送了 120 次身份提问。结果如下： 模型回答"我是 Nex"的比例：79.2%（95/120 次） 模型回答"我是 Nex-AGI 的"比例：73.3%（88/120 次） 模型回答"我是 Rio"的比例：0.0%（0/120 次） 零。一次都没有。 更离谱的是，模型还能逐字背出 Nex-AGI 的组织背景——“Nex-AGI is a large-model ecosystem alliance, jointly built by the Shanghai Innovation Institute（上海创智学院）…"——这段文字是 Nex-AGI 在训练自己的模型时注入的专属身份数据，出现在数百条训练样本中。 ...

两天之内 4700+ Star，241 条 HN 评论——小米 MiMo Code 的发布在开发者社区引起了不小的波澜。但让我真正感兴趣的不是这个数字本身，而是它背后的策略：fork 一个已经有 17 万 Star 的开源项目 OpenCode，然后在上面叠加自己的东西。 坦白说，“大厂 fork 开源项目"这件事本身就自带争议。HN 评论区有人直接开喷：“fork 一个已有的开源项目，不给上游贡献代码，附加可能跟 MIT 许可证冲突的使用限制，然后还要 PR。“但也有另一种声音：如果 fork 出来的东西确实有实质性的技术创新，那这件事本身就有讨论的价值。 所以这篇文章想回答的核心问题是：MiMo Code 到底加了什么？这些加的东西值不值得一个独立项目的存在？ 从 OpenCode 到 MiMo Code：不是换层皮那么简单 先说上游项目。OpenCode（现在叫 opencode）是一个终端原生的 AI 编程助手，17 万+ Star，TypeScript 写的，支持多 Provider、TUI 界面、LSP、MCP 协议和插件系统。它在 2025 年 4 月创建，到现在已经迭代了一年多，是终端编程 agent 领域里用户量最大的开源项目之一。 MiMo Code 保留了 OpenCode 的所有核心能力——多 Provider 切换、TUI 交互、LSP 集成、MCP 工具协议和插件系统——在此基础上叠加了五个关键模块。从源码结构看，它在 packages/opencode 目录下保留了 OpenCode 的核心代码，同时新增了 packages/app、packages/desktop、packages/enterprise、packages/sdk 等模块，看起来不只是一个 CLI 工具，而是一个完整的平台化产品。 持久化记忆系统 —— 这可能是最有意思的部分。它用 SQLite FTS5（全文搜索）做底层存储，维护一个 MEMORY.md 文件作为跨会话的项目知识库。每次你开新会话，记忆自动注入上下文，agent 不需要重新理解项目结构。 ...

一个万亿参数的模型，在 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——说白了就是"有结构，但远不够可靠"。如果你让五个实习生做同一批事实核查，交上来的结果差异这么大，你大概不会直接发布。 ...