LLM

上周，里约热内卢市政府高调发布了名为 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 在训练自己的模型时注入的专属身份数据，出现在数百条训练样本中。 ...

最近 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 这类）不断精进。他说这些教程给他的不只是知识，更是"从零到一"的信心和继续深入的底气。 ...

做 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 张图就撞墙了。 ...

如果你正在用 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）清空。这和人类睡眠中的记忆整合过程惊人地相似。 ...

我越来越觉得，很多 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 把外部工具和数据源标准化成可连接的上下文。 ...

VibeVoice 在 HN 上冲到三百多分时，我第一反应不是“又一个开源 TTS 火了”。真正值得看的是另一个问题：语音 AI 开始从 demo 音质竞争，转向能不能被塞进真实产品链路。 这件事对做 AI 应用的人很现实。文字 Agent 已经卷到上下文工程、工具调用、评测和成本优化；但一旦加上语音，系统复杂度会立刻翻倍：ASR 要处理长音频、说话人、时间戳和热词；TTS 要处理首包延迟、流式输入、语气一致性和滥用风险。VibeVoice 这次之所以值得写，不是因为微软给了一个“声音很像真人”的玩具，而是因为它把 ASR、实时 TTS、长文本合成和 vLLM/Transformers 集成都放在一个开源项目里，让我们能更清楚地判断：开源 Voice AI 到底离生产系统还有多远。 先说我的结论：VibeVoice 很适合做研究原型、内部工具、长音频转写和语音 Agent 的技术验证；但如果你准备直接把它当成商业级语音生成服务，我会非常谨慎。 不是它不强，而是语音系统的生产风险和文本 LLM 完全不是一个量级。 它真正解决的不是“会说话”，而是语音链路的三个断点 从 VibeVoice GitHub README 看，项目现在不是单一模型，而是一组语音 AI 组件：VibeVoice-ASR-7B、VibeVoice-TTS-1.5B，以及 VibeVoice-Realtime-0.5B。README 里明确提到，ASR 可以处理 60 分钟长音频，输出包含 Who、When、What 的结构化转写；实时 TTS 则强调 streaming text input 和约 200ms 的首次可听延迟。 这几个关键词放在一起，含义很明确：它瞄准的不是“输入一句话，生成一段 wav”这种 demo，而是更接近真实业务里的语音流水线。 比如会议纪要系统，难点通常不是识别一句英文，而是 40 分钟会议里谁说了什么、什么时候说的、专有名词有没有错、跨语言夹杂会不会崩。再比如语音 Agent，用户希望模型一边生成答案一边开口说话，而不是等 LLM 完整吐出 800 字后再合成音频。技术上看，这就是 ASR 的长上下文与说话人结构化、TTS 的流式合成、以及中间 LLM 的 token streaming 能不能顺滑拼起来。 ...

如果你做过 Web 端 AI 功能，大概率踩过同一个坑：用户只是想总结一段文字、给评论纠错、从页面里问几个问题，你却要把内容发到云端 LLM，承担 token 成本、排队延迟、隐私合规和数据出境解释。 所以我看到 Hacker News 上 The Prompt API 这条讨论冲到两百多分时，第一反应不是“浏览器终于也有 AI 了”，而是：这东西如果真能稳定落地，会改变一类低风险 AI 功能的默认架构。 Chrome 的官方文档把 Prompt API 描述得很直接：网页或 Chrome Extension 可以把自然语言请求发给浏览器内置的 Gemini Nano。换成人话说，就是以前你在前端调用 fetch('/api/ask')，后端再转发给 OpenAI、Gemini 或自建 vLLM；现在有些场景可以直接在浏览器里问本地模型。 这听起来很香，但我不建议现在就把它当成“云端 LLM 替代品”。它更像一块新的系统拼图：适合放在用户设备边缘，处理轻量、局部、对隐私敏感、失败代价不高的任务。 它真正解决的不是“更聪明”，而是“更靠近数据” Prompt API 背后的标准化工作在 Web Machine Learning Community Group 的 prompt-api 仓库 里。这个 Explainer 说得很清楚：今天 Web 开发者要用语言模型，通常只有两条路：调用云端 API，或者自己把模型用 WASM/WebGPU 之类的方式塞进浏览器。前者简单但有隐私和成本问题，后者灵活但工程负担很重。 浏览器内置模型想走第三条路：模型由浏览器或操作系统提供，Web 应用只拿到一个标准 API。 说白了就是：模型不属于你，运行环境也不完全属于你，但调用入口变简单了。 这件事的工程价值不在于 Gemini Nano 一定比你后端的大模型强。恰恰相反，它大概率不会更强。它的价值在于位置：模型离用户输入、页面 DOM、临时草稿、聊天记录更近。很多数据本来就停留在浏览器里，如果只是做摘要、标签、轻量问答、辅助改写，非要绕一圈云端并不总是合理。 Chrome 的 built-in AI 入门文档 也强调了这个方向：内置 AI 让 Web 应用在不部署、不管理自有模型的情况下完成 AI 任务。这个表述很克制，它没有承诺“最强模型”，而是在强调部署和管理成本。 ...

你有没有这种感觉：每天早上醒来，前一天学的东西大部分都忘了？ LLM 就是这样工作的。 每个对话 session，模型都是从零开始。它不记得你是谁，不记得你上次做了什么决定，更不记得那个方案三个月前就试过并且失败了。你花 20 分钟解释背景，下一个 session 又得重来一遍。 这不是 AI 的 bug——这是架构限制。大多数 Agent 的"记忆"，就是把整段对话历史塞进 prompt，靠上下文窗口撑着。贵、慢，而且换一个新 session 照样失忆。 Stash 想要解决这个问题。它的 slogan 很直接：Your AI has amnesia. We fixed it. 这个项目是做什么的 Stash 是一个开源的持久化记忆层，专门给 AI Agent 用。它不是一个聊天机器人，而是一个基础设施——在 Agent 和外部世界之间加了一层认知处理管道。 核心思路：Episodes become facts. Facts become patterns. Patterns become wisdom. AI 的每一次对话、每一个决定、每一次成功和失败，都被记录下来，经过一个 8 阶段的管道，转化成结构化的知识。事实与事实之间建立关联，关联形成模式，模式沉淀为真正的理解。 原始对话 ↓ Episode 记录（原始事件） ↓ Fact 提取（去掉了时间戳和情绪的事实） ↓ Relationship 建立（事实之间的连接） ↓ Pattern 检测（反复出现的模式） ↓ Goal Tracking（目标状态） ↓ Failure Pattern（失败教训） ↓ Hypothesis & Confidence（假设与置信度衰减） ↓ Wisdom（长期知识） 这个管道是增量的——每次运行只处理新数据，不会重复劳动。 ...

如果你在生产环境里接入了两个以上的 LLM 提供商（OpenAI、Anthropic、Gemini、Groq……），大概率已经踩过这些坑：供应商的 API 格式不统一、重试逻辑要写 N 份、想把 Claude 和 GPT 的调用日志合并看也做不到、换个供应商代码要改一大坨。 这就是 AI Gateway 存在的意义——在你和所有模型供应商之间加一层抽象，对外暴露统一的 OpenAI 兼容 API，你改供应商只需要改配置，不用动业务代码。 这个赛道最知名的是 LiteLLM（Python），今天要聊的是一个用 Go 写的竞争方案——GoModel，4 个月时间，511 Stars，GitHub 最后一次提交就在昨天。 背景：多供应商困境 先说个真实的场景。 你做 AI 产品，接入了 GPT-4o 做主力、Claude Sonnet 做复杂推理、Gemini 2.5 Flash 做快速摘要。三个供应商，三套 SDK，三套错误处理，三套重试策略，三套计费逻辑。然后产品经理说：「能不能把这个月各模型 token 消耗做个报表？」 你翻了三天日志，发现各家日志格式完全不一样，计量单位都不统一。这就是为什么需要一个 AI Gateway——它把所有调用收敛到一个统一的接口，同时帮你把日志、计费、缓存这些事情做好。 LiteLLM 是这个方向最成熟的开源方案，但它是 Python 写的，GIL 限制了并发能力，而且配置相对复杂。 GoModel 是什么 GoModel 是来自波兰华沙的独立开发者 Jakub（GitHub @santiago-pl）的作品，2024 年 12 月开始开发，定位是高性能 AI Gateway，用 Go 编写，对外暴露完整的 OpenAI 兼容 API。 核心特性： 11 家供应商支持：OpenAI、Anthropic、Google Gemini、xAI Grok、OpenRouter、Z.ai、Azure OpenAI、Oracle Cloud AI、Ollama、vLLM OpenAI 兼容端点全覆盖：/v1/chat/completions、/v1/embeddings、/v1/files、/v1/batches 双层响应缓存：精确匹配缓存 + 语义缓存（基于向量相似度），官方案例中语义缓存将命中率从 18% 提升到 60-70% Guardrails：可配置的请求/响应过滤管道 Provider Passthrough：原生端点透传（/p/{provider}/...），绕过网关直接访问供应商特性 Admin API：用量统计、Token 消耗追踪、审计日志 说白了就是：LiteLLM 能做的 GoModel 基本都能做，但用 Go 写的，高并发下性能更好，内存占用地更低。 ...