AX 严选 · 2026-07-08

SemiAnalysis这份报告给出了两个硬数字：Anthropic今年Q3利润预计超10亿美元，并且6月1日已经秘密交了IPO申请。它和OpenAI两家现在的年度经常性收入加起来快1000亿美元，说明头部AI公司确实在把技术变成真金白银，不是光烧钱。Anthropic能跑在前面，主要靠Claude Code在开发者群体里铺得快，帮它在企业生意上先赚到了钱，成了B2B这块的领跑者。 但报告里那个6万亿美元市值目标，正文没披露是怎么算出来的，只说是“基本情形”。这种远期估值变数太大，现在拿它当锚点意义不大。另外，利润和收入数据主要来自SemiAnalysis自己的模型估算，虽然他们提了一句《华尔街日报》的报道侧面验证了模型，但Anthropic还没公开财报，实际数字可能有出入。 还缺两个关键信息：一是Anthropic的客户集中度怎么样，如果收入太依赖少数大客户，风险会高不少；二是IPO的具体时间表和估值区间，现在只知道秘密交表，后面怎么走还不清楚。

这起诉讼暴露的不是 Grok 被恶意利用，而是 xAI 的安全上报机制几乎失灵。用户用 Grok 生成了超过 7000 张继女的儿童性虐待图片，xAI 只向美国国家失踪与受虐儿童中心上报了一条涉及轮奸的提示词，其余数千次生成全部沉默。该男子事后开枪自杀，案件本身已经没有刑事追诉对象，但诉讼把矛头指向了 X 和 xAI，指控他们实质上庇护了侵害者。 文章没有解释为什么安全过滤器漏掉了绝大多数图片，也没说 Grok 的图像生成功能是否默认禁用了真实人脸模拟。这两个信息缺口很关键——如果是默认关闭的，那说明用户刻意绕过了防护；如果没关，那问题就出在模型本身的安全能力上。另外，xAI 的内部上报阈值是什么、触发条件怎么设的，正文也没披露。 对从业者来说，这条新闻的警示很直接：生成模型的安全不能只靠事后上报，尤其是当上报本身也形同虚设的时候。如果连这么极端的内容都只抓到一条，那日常的擦边内容大概率全漏了。这点先别急着归因成“恶意”，但至少说明 xAI 的安全基础设施远没跟上产品节奏。

这条新闻的核心不是 AI 教唆杀人，而是 OpenAI 的安全上报机制在商业考量前失效了。枪手在 2025 年 6 月就被封号，但 OpenAI 当时没发现“即将发生袭击的证据”，所以没报警。直到 2026 年 2 月枪手杀了 8 个人，公司才在 4 月道歉，承认按更新后的规范“本应上报”。 家属律师的指控更直接：OpenAI 选择隐瞒，是因为上报一个账号意味着要上报成千上万个同类账号。这等于说，公司知道问题规模很大，但选择不面对。加拿大省政府现在要自己起诉，还分别在加拿大和加州请了律师，摆明了是要打跨国官司。如果胜诉，赔偿会用来重建学校和社区。 正文没披露 OpenAI 内部的安全审核流程到底怎么运作的，也没说清楚“2025 年 6 月之后更新的安全规范”具体改了什么。另外，枪手被封号后还能绕过 30 天封禁期继续用，这个漏洞的细节也没展开。这些信息缺口让“系统性问题”的判断还缺关键拼图。

Anthropic 的开发者公开了他们内部怎么用多智能体省钱，核心思路就一条：别啥事都让最贵的模型上。第一种 Advisor 模式，让便宜的 Sonnet 5 当主力写代码，碰到难题才通过工具调用去问贵的 Fable 5。在 SWE-bench Pro 的 482 道题上，这套组合拿了 84% 的分数，花了 1.40 美元；纯用 Fable 5 是 91.5% 但得花 2.25 美元。相当于用 92% 的性能，省了 37% 的钱。第二种 Orchestrator 模式，让 Fable 5 当指挥，把任务拆开分给多个 Sonnet 5 工人并行干。在 BrowseComp 测试上，这套编排方案拿到 86.8%，花 18.53 美元；全 Fable 5 是 90.8% 但成本高达 40.56 美元，省了一半还多。 这两组数字挺实在的，直接告诉你省了多少、掉了多少。不过要注意，测试集是 SWE-bench Pro 和 BrowseComp，都是代码和浏览类任务，其他场景能不能复现这个省钱比例，正文没提。另外，Orchestrator 模式里 Fable 5 怎么拆任务、Sonnet 5 之间怎么协调，细节也没展开，实际落地时调度逻辑写不好可能反而增加延迟。

周俊在 AICon 上给了一个很直观的比喻：万亿参数模型跑 15 分钟，算力成本抵一辆特斯拉。这个说法把大模型烧钱的程度讲清楚了。他们没去继续堆 Token 数量，而是提了一个“Token 密度”的概念，核心是让模型少说废话、多干正事。 技术实现上，他们用 7 份 Lightning Attention 加 1 份 MLA 搭了一套混合线性注意力架构，把 256K 长上下文的计算开销从指数级拉回到线性级。省下来的算力可以留给推理环节。Kpop 算法把工具调用的 Token 和自然语言 Token 分开处理，再配合思维链剪枝和自蒸馏，Token 输出量减少约 4 倍，但能力没降。千亿参数模型在 BFCL 等 Agent 基准上跑赢了部分更大的模型，小模型 flash 吞吐提到 2.4 倍，五轮对话成本降了 10 倍以上。 这些数字如果属实，对做 Agent 落地的人挺有吸引力，尤其是长上下文和工具调用频繁的场景。但正文没披露具体测试环境、对比基线的细节，也没看到开源权重或第三方验证。演讲里的数据先打个折看，等有公开复现报告再下结论。

Tunguz 这套架构的核心是把记忆和推理拆开。他建了一个约 90 个技能的长期库，智能体接到任务后先做“预检”，只把匹配的技能装进上下文窗口，而不是把全部资料塞进去。这相当于让模型带着小抄上考场，能省下不少上下文空间。日常任务里，80% 由本地跑的 Ornith 35B 模型处理，只有硬骨头才转给更强的模型，听起来能省不少调用大模型的费用。 系统里还有个“看门狗”，会记下每次决策，晚上做异步推理，自动建议新技能或把部分技能转成确定性代码，比如用 Rust 处理日历排期，而不是让大模型去比空闲时段。昨天是它第一次没提改进建议，可能说明系统到了平台期，只有遇到真正的新异常才需要人插手。 不过，这篇文章是个人实验分享，不是产品发布。正文没披露这套系统的实际延迟、单次任务成本，也没给准确率数据。90 个技能听着不少，但能不能覆盖复杂业务场景也未知。整体思路值得参考，但落地效果还得看具体数字。