调 JAX / TPU 程序的时候,迟早会碰到 HLO。想知道一个计算被编译成了什么、为什么多出几次 copy、一个 fusion 里到底装了哪些操作,最后都要打开编译器吐出来的那份文本。
指令里挤着 shape、layout、tiling、memory space 和 computation 引用,光认出 bf16 和 fusion 还远远不够。
所以我做了 HLO Visualizer:把 HLO 文本变成可以探索的图,点一下节点,就能把这条指令一块一块地读明白。
调 JAX / TPU 程序的时候,迟早会碰到 HLO。想知道一个计算被编译成了什么、为什么多出几次 copy、一个 fusion 里到底装了哪些操作,最后都要打开编译器吐出来的那份文本。
指令里挤着 shape、layout、tiling、memory space 和 computation 引用,光认出 bf16 和 fusion 还远远不够。
所以我做了 HLO Visualizer:把 HLO 文本变成可以探索的图,点一下节点,就能把这条指令一块一块地读明白。
We benchmark LLM inference on one Google TPU v6e-4 host (four chips, one VM). We use vLLM 0.20.0 with the tpu-inference backend and an fp8 KV cache.
We test three Qwen3 models:
| Model | Type | Params | Parallelism | Chips |
|---|---|---|---|---|
| Qwen3.5-4B | dense | 4B active | tp1 | 1 |
| Qwen3-30B-A3B | MoE | 30B total / 3B active | tp4 | 4 |
| Qwen3-32B | dense | 32B active | tp4 | 4 |
We measure three parts of inference: prefill, decode, and end-to-end online serving.
声明:这篇文章不是要论证 TPU 不如 GPU。TPU 和 GPU 各有适用场景,谁强谁弱要看具体负载。我要说的是,目前网上流传的那批对比数据本身不准确,很多是 AI 编造、无法溯源的。下面拆的就是这些假数据。
Artificial Analysis 最近放出一组硬件基准测试1,以 Llama 3.3 70B、vLLM、每查询 30 output tokens/s 的参考速度计算每百万输入输出 token 的成本,NVIDIA 对 TPU v6e (Trillium) 有大约 5 倍的每美元 token 优势,对 AMD MI300X 有大约 2 倍优势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 Dollar3。核心论点是 TPU 每美元性能比 H100 好 4 倍,TPU 在推理经济性上全面压过 NVIDIA。它的关键数据来自另一篇文章,ainewshub.org 的 Nvidia vs Google TPU 2025 Cost Comparison4。顺着这条引用链往下看,会发现两篇都是 AI 生成的,数据是编的。
终端里 claude 好好的,Team Account 也认得,进了 tmux 就让我重新登录。折腾了一会儿才发现是 macOS Security Session 的老问题。
现在 AI 编程助手越来越多,从聊天框一路卷到了跑在命令行里的 Agent。用了一圈下来,我最大的感受是:没有哪个 Agent 能在所有方面都做到最好。
我日常主要在用 Claude Code、Google Gemini CLI 和 Moonshot Kimi Code。一开始也是把它们当独立工具用,后来发现这样太浪费了,因为它们各有各的长板,如果让它们根据各自的优势互相配合、互相委派任务,效果会好很多。我把这个思路叫做 Agent Mesh。
在容器化部署中,有时候我们需要让容器的所有出站流量通过特定的网络出口。Tailscale 的 sidecar 模式可以做到这一点:用一个 Tailscale 容器作为 sidecar,其他容器共享它的网络命名空间,流量通过 WireGuard 隧道经由远端 exit node 出去。
这个方案在 Docker Compose 下很成熟,但迁移到 nerdctl(containerd)时,我踩了一连串的坑。记录下来,希望能帮后来人少走弯路。

2026 年初,我在新加坡 “INTO THE MODERN” 印象派画展中,第一次站在莫奈的原作前。
这套配置用 Dev Container1 管理 LaTeX 环境,用 Git 同步项目。拉取仓库后,在容器中打开即可编译。
我把日常跑轻量服务的树莓派 4B 换成了 Intel NUC,处理器从 ARM 换成 x86,存储从 TF 卡换成 SSD。
众所周知,键帽一旦“打油”,就很难通过简单擦拭恢复原状。我曾尝试用砂纸打磨键帽,但不仅效果更差,产生的碎屑还会掉进缝隙里。你可以在图中看到我打磨过的 Shift 和 Space,外观变得非常难看。
虽然有人说可以去 Apple 直营店更换键帽1,但据说每次只能更换几个。对于我这种整块键盘都打油的情况,显然还是自己动手来得更实际。
写这篇博客的原因是,我发现网上几乎找不到一篇完整介绍 MacBook Pro M1 键帽更换的教程。大多数视频2只演示了普通按键的拆解,也就是字母键和数字键,没有介绍长键帽,比如 Space、Caps Lock、ESC,以及方向键的处理方式。而这些键的结构明显不同,拆装方式也更复杂。