Junyi's Lab

拆穿 introl 和 ainewshub，TPU 比 GPU 便宜 4 倍是 AI 编的幻觉

junyi.h@comp.nus.edu.sg (Junyi Hou) — Wed, 10 Jun 2026 15:26:00 +0800

声明：这篇文章不是要论证 TPU 不如 GPU。TPU 和 GPU 各有适用场景，谁强谁弱要看具体负载。我要说的是，目前网上流传的那批对比数据本身不准确，很多是 AI 编造、无法溯源的。下面拆的就是这些假数据。

Artificial Analysis 最近放出一组硬件基准测试¹，以 Llama 3.3 70B、vLLM、每查询 30 output tokens/s 的参考速度计算每百万输入输出 token 的成本，NVIDIA 对 TPU v6e (Trillium) 有大约 5 倍的每美元 token 优势，对 AMD MI300X 有大约 2 倍优势²。

Artificial Analysis 在 X 上公布的硬件基准结论，NVIDIA 对 TPU v6e 有约 5 倍每美元 token 优势，对 MI300X 约 2 倍，H100 是 1.06 美元，MI300X 是 2.24 美元，TPU v6e 是 5.13 美元。

跟这些能复现的数据一起在网上传的，还有另一类东西。

# 一篇高调的对比文

introl 有一篇文章，标题叫 Google TPU v6e vs GPU: 4x Better AI Performance Per Dollar³。核心论点是 TPU 每美元性能比 H100 好 4 倍，TPU 在推理经济性上全面压过 NVIDIA。它的关键数据来自另一篇文章，ainewshub.org 的 Nvidia vs Google TPU 2025 Cost Comparison⁴。顺着这条引用链往下看，会发现两篇都是 AI 生成的，数据是编的。

# 锤点一，核心引用指向一份不存在的数据

ainewshub 那篇最核心的一句话是这样写的。

ainewshub 文章里的核心论断，4.7 倍每美元性能，来源标的却是并不存在的 MLPerf v4.1 LLM 推理结果。

“4.7× better performance-per-dollar on LLM inference than Nvidia H100/H200”，来源标的是 Google Cloud MLPerf Inference v4.1 results + customer case studies, October 2025。

但其实，MLPerf Inference v4.1 里，Google 的 TPU 提交项只有 stable-diffusion-xl 一个模型。我去 MLCommons 的官方结果⁵里按 Google 加 TPU 筛，v4.1 Closed Datacenter 下只有两条记录，tpu-v5e-4 和 tpu-v6-4，跑的都是 stable-diffusion-xl。

在 MLPerf v4.1 Closed Datacenter 里筛 Google TPU，只有 tpu-v5e-4 和 tpu-v6-4 两条，跑的都是 stable-diffusion-xl，没有任何 LLM 推理项。

没有任何 LLM 推理项！这篇文章引用的所谓 MLPerf v4.1 的 LLM 推理每美元性能 4.7 倍，在它声称的来源里根本不存在。数字是凭空生成的，然后挂了一个看起来权威的出处。

其次，MLPerf 压根不报每美元性能。它报的是吞吐，samples/s 和 queries/s，里面没有价格。所以那 4.7 倍根本不可能是从 MLPerf 算出来的。

# 锤点二，数字在转载之间漂移

把 introl³ 和 ainewshub⁴ 两篇放一起时，数字对不上（而且有虚假陈述）。

每美元性能倍数，introl 写 4 倍，ainewshub 写 4.7 倍。（这条纯骗人，见上文）
MLPerf 版本，introl 引 v3.1，ainewshub 引 v4.1。（不知道 introl 从哪哪来的数据）
Midjourney 案例，introl 写月支出从 200 万美元降到 70 万美元，ainewshub 写从 210 万美元降到 70 万美元。（这条我没仔细核查，大概率也是幻觉出来的）

转载来转载去，每复述一次就变一点。他妈的，模型每生成一次，就重编一个差不多的数出来。

# 锤点三，精确到吓人的 TCO 表，却没有来源

ainewshub⁴ 给了一张三年总拥有成本表，1000 芯片集群，NVIDIA H100 总成本 1.77 亿美元，Google TPU v6 总成本 7850 万美元，省 9850 万美元。还细分到硬件降 48%、电费降 66%、制冷降 67%、支持降 63%、网络降 67%、地产降 63%。（全是编的）

这种精确到个位百分比的分项拆解看起来很专业。问题是没有一项能溯源。配套的客户案例也一样，Midjourney，还有一家所谓 C 轮计算机视觉创业公司月支出从 34 万美元降到 8.9 万美元，全是无法核实的具体数字。

# 最可恶的是 “data verified”

顺着 ainewshub 那篇成本对比文再往上游追，它的来源指向同一个站点的另一篇文章，AI Inference Costs: TPU vs GPU 2025⁶。同样的数字在这里又复述了一遍，4 倍性价比、Midjourney 省 65%、TPU v5e 在 9 项里赢 8 项，我必须再次强调，这个数据是假的、是不存在的。

它结尾那句声明是这样写的：

Data verified as of November 26, 2025. Sources include Google Cloud documentation, MLPerf benchmarks, company earnings reports, and verified industry migrations.

核实了个屁

它说核实了，却给不出任何一个能点开的链接，没有具体报告，没有方法。前面已经查过，它依赖的 MLPerf TPU LLM 推理结果根本不存在。所谓 verified，全他妈假的。

同一个站点的不同文章，连这些假数字都对不上，写的人自己也不知道这个数从哪来，因为它本来就不存在。

一个成批生产幻觉数字、再统一盖上 data verified … 这个垃圾网站真害人不浅

# 目前我查到的数据是这样（至少比他们网站可信一点）

Artificial Analysis 的 System Load Test¹，跑的是 Llama 3.3 70B。

Artificial Analysis System Load Test，Llama 3.3 70B 的峰值系统吞吐、每查询输出速度和按需租用价格。

峰值系统吞吐，B200 是 15.4k tokens/s，H200 是 8.47k，H100 是 7.28k，TPU v6e 是 6.73k，MI300X 是 3.67k。TPU v6e 落在 NVIDIA 同代后面。每查询输出速度，TPU v6e 是 61.3 tokens/s，是这组里最慢的。

成本要分两种情况说，这里 TPU 也有能算的账。

Llama 3.3 70B 在峰值吞吐下的每百万 token 成本，TPU v6e 为 0.62 美元，与 H100 的 0.67 到 0.69 美元接近。

在峰值吞吐下算每百万 token 成本，TPU v6e 是 0.62 美元，和 H100 的 0.67 到 0.69 美元接近，比 MI300X 的 0.90 美元和 B200 跑 vLLM 的 1.63 美元都便宜。如果负载是离线大批量、能把芯片喂满，TPU 的账是划算的。

但线上服务很少跑在峰值吞吐上。一旦要求一个能用的交互速度，比如每查询 30 tokens/s 的参考速度，TPU v6e 的单位成本就跳到 5.13 美元，而 H100 是 1.06 美元。这就是 Artificial Analysis 说的大约 5 倍差距的来处。

后面我们会自己进行 benchmark 得到一手数据，到时再对比。

# 识别出 AI 生成垃圾文的方法

只要遵循一个原则：任何数据、任何数字，必须有可点开的来源，必须有可复现的方法。

Claude Code 在 tmux 里要求重新登录？八成是 macOS Keychain 的锅

junyi.h@comp.nus.edu.sg (Junyi Hou) — Fri, 03 Apr 2026 00:00:00 +0800

终端里 claude 好好的，Team Account 也认得，进了 tmux 就让我重新登录。折腾了一会儿才发现是 macOS Security Session 的老问题。

# 现象

Ghostty 里直接跑 claude，没问题。tmux 里跑，要求登录。

排查过程（点击展开）

## 环境变量？

第一反应是 tmux 里环境变量不一样。

env | grep -iE 'claude|anthropic'

两边都没有。Claude Code 认证不存环境变量。

## 配置文件？

cat ~/.claude/.credentials.json 2>/dev/null || echo "no credentials file"

也没有。不在文件系统里。

## Keychain

security dump-keychain 2>&1 | grep -i -A3 'claude\|anthropic'

找到了，存在 macOS Keychain 里，service name 是 Claude Code-credentials：

0x00000007 <blob>="Claude Code-credentials"
"acct"<blob>="junyi"
"svce"<blob>="Claude Code-credentials"
keychain: "/Users/junyi/Library/Keychains/login.keychain-db"

然后试了下：

security find-generic-password -s "Claude Code-credentials" -a "junyi" -w

终端里能输出 token，tmux 里报错。问题在这。

# 为什么

macOS 的 Keychain 访问绑在 Security Session 上，底层对应的是 Bootstrap Namespace。你开终端窗口的时候，进程会挂到当前用户的 Aqua session，Keychain 就是通过这个 session 解锁的。

但 tmux server 是个常驻后台进程，第一次 tmux new 的时候启动，之后就一直活着。你后面 tmux attach 的时候，tmux server fork 出来的 shell 继承的是 server 启动时的那个旧 session，不是你当前的 Aqua session。

正常终端:
Ghostty → fork shell → 继承 Aqua session → ✅ 能读 Keychain
tmux:
Ghostty → attach → tmux server (旧进程)
→ fork shell → 继承旧 session
→ ❌ 读不了 Keychain

pbcopy/pbpaste 在 tmux 里挂掉也是这个原因。

# 修复

装 reattach-to-user-namespace，让 tmux 里的进程重新接入当前用户的 Aqua session：

brew install reattach-to-user-namespace

~/.tmux.conf 加一行：

set-option -g default-command "reattach-to-user-namespace -l ${SHELL}"

然后杀掉整个 tmux server 重开。kill-session 没用，新 window 也没用，都还是从旧 server fork 的：

tmux kill-server
tmux new -s main

验证：

security find-generic-password -s "Claude Code-credentials" -a "$USER" -w 2>&1 | head -c 50

能输出 token 就说明通了。

# 顺带一提

tmux 里这些问题多半也是同一个原因：

pbcopy/pbpaste 不工作
ssh-agent 访问不了
osascript 执行失败
gh auth、op 等 CLI 工具认证挂了

都是 reattach-to-user-namespace 一把搞定。

Agent Mesh：聊聊我对多 AI 协同工作流的一些想法

junyi.h@comp.nus.edu.sg (Junyi Hou) — Wed, 11 Mar 2026 04:29:00 +0800

现在 AI 编程助手越来越多，从聊天框一路卷到了跑在命令行里的 Agent。用了一圈下来，我最大的感受是：没有哪个 Agent 能在所有方面都做到最好。

我日常主要在用 Claude Code、Google Gemini CLI 和 Moonshot Kimi Code。一开始也是把它们当独立工具用，后来发现这样太浪费了，因为它们各有各的长板，如果让它们根据各自的优势互相配合、互相委派任务，效果会好很多。我把这个思路叫做 Agent Mesh。

下面展开聊聊我的观察和想法。

# 核心角色：我的观察和真实体验

## Claude Code：顶级架构师与执行引擎

日常用下来，Claude Code 给我的感觉就是一个"资深工程师"。不管是从零起一个新项目，还是啃一坨复杂的重构，它出的方案在架构层面的眼光是最好的。而且它不只是出方案，它自己就能跑起来：遍历文件、跑 bash、编译报错了自己改，整个循环它能自己转。我已经在所有的服务器上安装了 Claude Code，它大大提高了我的生产力，解放了我的很多精力。短板是幻觉，尤其是在生成大段文档、或者引用它没吃透的大型系统时，它会编东西出来。

## Gemini CLI：大数据吞吐者与“幻觉检查员”

Gemini 最大的优势是那个 200 万 Token 的上下文窗口。实测下来，它真的能一口气吞掉整个仓库、很长很长的错误日志，我试过几百 K 的那种。正因为它能把整个宏观上下文都装进脑子里，它天然就是比较好的审计者。当 Claude Code 生成了一个出色但可能存在幻觉的代码方案时，可以调用 Gemini 进行大规模跨文件验证。

## Kimi Code：深度推理者与数据挖掘者，待评估

Kimi Code 走的是一条完全不同的路。它底层是 K2.5 的"长思考"模型 k0，走显式思维链，路子类似 OpenAI o1，再加上"Agentic Swarm"的玩法，理论上可以拉起一堆子 Agent 去网上多跳检索文档，或者死磕那种深度嵌套的算法难题。不过我得打个问号：Claude 和 Gemini 我是每天在用的，它们的能力边界我心里有数，但 Kimi 在"数据挖掘"和"深度推理"上到底比其他两个强多少，说实话我目前主要是看它架构上的宣称，还没做过严格的对比评估。所以目前它在这块只能说占了一个理论上的生态位。

# 我理想中的 Agent Mesh 长什么样

搞清楚了每个 Agent 的长板和短板之后，自然就会想：能不能让它们互相配合，用 Prompt 把活儿串起来？这就是我说的 Agent Mesh。

大部分时候 Claude Code 是干活的主力，代码基本都是它在写。但它遇到吃不下的大上下文时，比如我要重构一个模块但不知道会影响那 50 万行老代码的哪些地方，就丢给 Gemini，让它把整个仓库读一遍，告诉我影响范围。

反过来，Claude 执行完一份重构计划，我也会让 Gemini 拿着去跟实际项目文件交叉比对，看看有没有幻觉或坏掉的依赖。如果 Gemini 在审计过程中碰到特别硬的算法问题，还可以转手给 Kimi Code 去长考。

Kimi 想完之后也不直接改文件，而是把结论交回给 Claude Code，让 Claude 去落地执行。整个流程就是这样一个环：各自干各自最擅长的，结果互相流转。

# 隐形因素：Agent 架构 vs 基座模型

在尝试把这些 Agent 组合起来的时候，我发现了一个很容易被忽视的点：底层基座模型只是等式的一半，“围绕它构建的 Agent 架构”决定了它的实际能力。

最好的例子就是 Anthropic 的 Claude 3.5 Sonnet。你可以在多个环境中使用这同一个基座模型：

作为 VS Code 里的标准聊天助手。
作为 Cursor IDE 内部的驱动引擎。
通过 OpenHands / Open Code 这样的开源 Agent 框架。
原生通过 Claude Code CLI 使用。

尽管共享完全相同的 LLM DNA，也就是 Claude 3.5 Sonnet，它们的实际能力却大相径庭。在严苛的工程流中，原生 Claude Code 在 Agent 执行方面始终优于其他方式。为什么？因为 Agent 架构都由模型的创造者进行了独特的优化，包括但不限于隐藏的循环机制、错误恢复策略，以及特定的上下文工程。

即使使用像 Open Code 这样优秀的开源替代方案搭配 Claude 模型，其执行流畅度和架构视野也往往不及 Claude Code。这告诉我们，当我们为 Mesh 选择 Agent 时，我们选择的不仅仅是一个基座模型，比如 Sonnet 或 GPT-4o，更是围绕它构建的工程脚手架。

# 社区里的类似探索

写完这篇之后，我发现社区里已经有人在做类似的事情。Humanize 是一个 Claude Code 插件，它实现了一个叫 RLCR 的工作流，全称 Ralph-Loop with Codex Review：Claude 负责写代码，Codex 独立审查，发现问题就打回去重做，循环往复直到通过为止。核心思路和 Agent Mesh 一样，让架构上不同的 AI 各司其职，通过 work-feedback loop 不断迭代，而不是指望一个模型一次搞定所有事。

# 写在最后

我不觉得未来会出现一个“万能模型”把所有事都干了。真正有意思的是编排，让底层架构上有本质不同的 Agent 各司其职。

我一直坚持的一个观点是：当我们说“不同”的智能体时，我们指的不是拿同一个底层模型给它套上不同的系统提示词，比如玩”你是架构师”对”你是测试员”的角色扮演。只有当智能体在处理信息的底层架构上存在根本差异时，才能碰撞出真正的协同火花。

但是，你如何知道两个模型是真正不同的，还是只是同一个基础模型的微调版本？这时候，像 LLM-DNA 这样的工具就变得无比重要了。它是一个分析语言模型之间进化关系和功能差异的研究框架，已在 ICLR'26 以 Oral 形式发表。通过分析模型之间的“基因”谱系和功能距离，我们可以有意地选择那些属于完全不同进化分支的 Agent，从而确保它们不会拥有相同的盲区。

我的实际工程经验告诉我：Claude Code 与 Gemini CLI 的协同目前是最强大、最直观的组合。 Gemini CLI 靠长上下文，把整个仓库和一堆日志全吞进去，专门负责抓幻觉、做宏观审计。Claude Code 则专注在它最擅长的事上：理解代码架构、在本地系统里精准执行。

当你有意识地把架构上截然不同的 Agent 组合在一起时，它们不再互相重叠，开始互补。这就是我想分享的 Agent Mesh 思路，希望对大家有启发。