We benchmark LLM inference on one Google TPU v6e-4 host (four chips, one VM) with four chips in 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（CLI）。用了一圈下来，我最大的感受是：没有哪个 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” 印象派画展中，第一次站在莫奈的原作前。
这篇文章为「有洁癖的程序员」和「不想折腾环境的写作者」，提供一套开箱即用的容器化 LaTeX 方案：用容器隔离环境，用 Git 同步项目，做到「拉仓库 → 打开容器 → 立即编译」，彻底告别环境配置焦虑。
你可以随时随地使用 Git 同步你的项目，随用随走，无需担心环境问题。同时，你也可以放心大胆地让 Claude Code、Codex 帮你写 LaTeX 代码，不担心执行危险指令（请做好 git push protect）
陪伴我许久的树莓派 4B 终于迎来了「继任者」—— 小巧的 Intel NUC。从 ARM 到 x86，从 TF 卡到 SSD，这个看似简单的设备迭代，却让我的折腾体验有了质的飞跃。
众所周知，键帽一旦“打油”，就很难通过简单擦拭恢复原状。我曾尝试用砂纸打磨键帽，但不仅效果更差，产生的碎屑还会掉进缝隙里（你可以在图中看到我打磨过的 Shift 和 Space，外观变得非常难看）。
虽然有人说可以去 Apple 直营店更换键帽1，但据说每次只能更换几个。对于我这种整块键盘都打油的情况，显然还是自己动手来得更实际。
写这篇博客的原因是，我发现网上几乎找不到一篇完整介绍 MacBook Pro M1 键帽更换的教程。大多数视频2只演示了普通按键（字母键和数字键）的拆解，刻意跳过了长键帽（如 Space、Caps Lock、ESC）和方向键的处理方式。而这些键的结构明显不同，拆装方式也更复杂。
K3s 是由 Rancher Labs 开发的轻量级 Kubernetes 发行版，专为资源受限的环境和边缘计算场景设计。
本文将介绍如何在 Raspberry Pi 5 集群上部署 K3s，搭建一个功能完整的容器编排平台。