Junyi's Lab

deciax：用 JAX 和 Pallas 在 TPU 上运行 Decision Model

junyi.h@comp.nus.edu.sg (Junyi Hou) — Thu, 15 Oct 2026 00:00:00 +0800

Laya 是一个 Decision Model：用一次前向计算处理选择、评分和是非问题。我把它的推理路径移植到了 JAX，做成了 deciax，让这类模型可以在 TPU 上运行，再用 Pallas 优化其中的计算。

这次测试里¹，单芯片 TPU v6e 的英文模型单问题调用 p50 是 2.18 ms，多语言模型是 1.55 ms。作为对比，A100 SXM4、H100 PCIe、H200 NVL 的最快实测结果分别是 6.4 / 4.0 ms、4.8 / 3.2 ms、5.8 / 4.1 ms（英文 / 多语言）。

每次 50 个问题时，v6e Pallas 的 p50 是 33.69 / 17.83 ms，相较普通 JAX 实现提速约 2.3 倍；A100、H100、H200 的最快实测结果分别是 68.8 / 36.2 ms、44.0 / 23.2 ms、39.8 / 21.2 ms。

# 从一个例子开始

deciax 接收输入和一组问题，返回结构化结果。以一条重复扣款的工单为例：

import deciax

decider = deciax.load("laya")
result = decider.decide(
 {"user": "I was charged twice this month. Please refund the duplicate."},
 {
 "department": {
 "type": "choice",
 "instructions": "Which department should handle this?",
 "criteria": {
 "billing": "payments, invoices, refunds",
 "technical": "bugs, outages, system errors",
 "other": "everything else",
 },
 },
 "urgency": {
 "type": "score",
 "instructions": "How urgent is this?",
 "criteria": ["not urgent", "soon", "blocking"],
 },
 "refund_requested": {
 "type": "noul",
 "instructions": "Does the user ask for a refund?",
 },
 },
)
print(result)

# 我们先用 JAX 实现 Laya

我们先用 JAX 重新实现 Laya 的推理计算：由 ModernBERT encoder 处理输入，再由决策 head 输出各个问题的结果。输入构造保持不变，checkpoint 和 tokenizer 也沿用原模型。这样就得到了一条可以在 TPU 上运行的普通 JAX 推理路径，作为下面性能测试和后续 Pallas 优化的基线。

deciax 中的 Laya 推理流程。每个问题构成独立的一行输入，经过编码和 head 层后，得到选项分数与 action probability。

## JAX 实现的性能如何？

测试在 Oct 12, 2026 进行，覆盖 RTX 3090、A100 SXM4、RTX A6000、H100 PCIe 和 H200 NVL，以及各用一颗芯片的 TPU v5e、v6e。

延迟图展示进程内调用的稳态 p50²，包含输入编码、推理和结果处理。实心柱是 p50，虚线标记 p95。

先只看 GPU 的 PyTorch eager 和 TPU 的普通 JAX 实现：

未优化基线，单位 ms，越低越好。实心柱表示 p50，虚线表示 p95，标注为 p50 / p95。星号表示共享主机。

英文模型单问题调用，GPU eager 的 p50 是 13.3–25.8 ms，v6e JAX 是 2.27 ms。但每次 50 个问题时，v6e JAX 需要 76.79 ms，GPU eager 的最低值是 H200 NVL 的 57.5 ms。多语言模型也有类似变化：v6e JAX 从单问题的 1.61 ms 增长到 50 问题的 41.24 ms，H200 eager 的 50 问题结果是 34.0 ms。

## 耗时分解

接着拆开基线调用的耗时，以英文模型为例³：

蓝色为 profiler 记录的设备忙碌时间，斜线部分为总延迟减去设备时间的余量，标注是独立计时的 p50。两部分来自不同测量序列，是近似拆分；余量包含调度、Python、输入输出处理及设备空闲等开销，不是精确 CPU 耗时。

单问题的 GPU eager 调用包含大量小 kernel：英文模型一次调用就有 1090–1213 次 cudaLaunchKernel。设备执行之外的余量很大，优化需要同时考虑 kernel 融合和调用开销。

每次 50 个问题时，计算本身开始占主要时间。v6e JAX 的英文模型总延迟为 76.79 ms，其中单独测量的 forward-only 是 71.27 ms，输入编码约 3 ms。XProf 中，dot_general 和 sub 分别占这组设备时间的约 38% 和 21%，提示我们关注矩阵计算和逐元素操作的数据搬运。

# 如果让它更快呢？

我们使用 Pallas 对 TPU 上的 Laya 进行 kernel fusion 优化。当序列长度不超过 512 token 时，每个 encoder 层和 Transformer head 层都由一个 kernel 完成，将归一化、投影、attention 和 MLP 融合起来，encoder 中还包括 RoPE⁴。中间结果留在片上 VMEM 中，减少反复读写 HBM；每个 kernel 的权重也驻留在 VMEM 中，供不同的行块复用。此外，我们调整了 attention 的矩阵布局，采用转置形式的计算来更好地适配 TPU 矩阵单元。PR #1 记录了这些优化，以及长序列使用的三 kernel 路径。

为了尽可能公平，我们也测试了使用 TileLang、CUDA Graph 和 torch.compile 优化的 GPU 版 Laya。对于每台主机、每个模型和问题数，我们选取实测最快的实现，与 TPU v6e 上的 Pallas 版本进行比较。

每次一个问题，单位 ms，越低越好。实心柱表示 p50，虚线表示 p95，标注为 p50 / p95。星号表示共享主机。GPU 测试覆盖 TileLang、CUDA Graph 和 torch.compile，选择各卡实测最快的实现，以尽可能保证公平。

单问题调用，v6e Pallas 的英文模型 p50 是 2.18 ms，多语言模型是 1.55 ms。GPU 的英文模型最低值是 H100 PCIe 上 torch.compile with cudagraph 的 4.8 ms，多语言模型最低值是 3.2 ms。这个形状下，Pallas 相比普通 JAX 的改善很小。

每次 50 个问题，实心柱为 p50，虚线为 p95，标注为 p50 / p95。所有 GPU 项的最快实现均为 torch.compile with cudagraph；v6e Pallas 的 p50 是 33.69 ms / 17.83 ms，最快 GPU 是 39.8 ms / 21.2 ms（英文 / 多语言）。

每次 50 个问题，v6e 的英文模型从 JAX 的 76.79 ms 降到 Pallas 的 33.69 ms，多语言模型从 41.24 ms 降到 17.83 ms，分别提速 2.28 倍、2.31 倍。英文模型的 forward-only 从 71.27 ms 降到 28.25 ms，多语言模型从 36.54 ms 降到 13.36 ms。

# 不同 batch size 下的性能

Batch size 会影响硬件利用率，因为它决定了硬件能同时处理多少计算。小 batch 可能无法充分利用计算单元，调度等固定开销在单次调用中的占比也更高。增大 batch 可以提供更多并行工作，让权重在更多输入之间复用，并将固定开销分摊到更多决策上。但它也会增加计算量和内存需求，因此吞吐量提高的同时，单次调用的延迟也可能变长。在小 batch 下表现好的实现，换到大 batch 后不一定仍有同样的优势。

Laya 会把每个问题构造成独立的一行输入，因此这里针对同一条输入，每次分别提交 1、5、10、50 个问题，改变逻辑 batch size。TPU 实现会将这些行补齐到支持的 batch 桶，所以问题数代表有效输入行数，不一定等于实际执行张量的 batch 维度。下图对比 H100、H200 与 v6e Pallas 在这些 batch size 下的单次调用延迟，观察处理更多决策时耗时如何增长：

横轴为每次调用的问题数，纵轴为 p50 ms，两轴均为对数刻度。分别展示 H100 PCIe、H200 NVL 各问题数下实测最快的实现，以及 v6e Pallas。每条 GPU 曲线固定对应同一张卡。

# 部署模型服务

## HTTP 服务

为了让其他应用调用 Laya，我们通过 deciax.serve 将同样的决策接口暴露为 HTTP 服务：向 POST /v1/systemone 发送输入和问题，服务以 JSON 返回结构化答案。模型在服务启动时加载，并在后续请求之间复用。

在已安装 deciax 的 TPU 主机上，运行以下命令，使用 Pallas 实现在 8000 端口启动 HTTP server：

python -m deciax.serve --model laya --impl pallas --port 8000

启动和预热完成后，在另一个终端发送请求：

curl http://127.0.0.1:8000/v1/systemone \
 -H 'Content-Type: application/json' \
 -d '{
 "state": "I was charged twice. Please refund the duplicate charge.",
 "questions": {
 "refund": {
 "type": "noul",
 "instructions": "Does the user ask for a refund?"
 }
 }
 }'

返回结果中的 answers.refund.noul 表示答案为真的概率，同时还包含置信度、action probability 和 token 用量。服务也提供 GET /health 健康检查和 POST /v1/systemone/batch 批量接口。

在 loopback、keep-alive 条件下，我们测得 v6e Pallas 的单问题 HTTP p50 为英文 3.0 ms、多语言 2.4 ms。

## Cost：Million model input tokens per US dollar

成本只比较 English model 的优化版本：GPU 取前面的实测最快实现，TPU 只放 v6e Pallas。分别按 on-demand 与 preemptible / spot 两种小时价格计算。

性能数据和价格数据采集于 Oct 12, 2026。

价格单位：USD / GPU-hour 或 TPU chip-hour。

硬件	供应商	On-demand	Preemptible / Spot⁵
A100 SXM4 80GB	Vast.ai	$1.176	$0.727
H100（SXM 报价）	Nebius	$4.500	$0.790
H200（SXM 报价）	Nebius	$5.400	$0.790
TPU v6e	Google Cloud	$2.700	$0.970

计算公式是⁶：

Million model input tokens per US dollar
 = model input tokens per second × 3600 / hourly price / 1,000,000

这里的 model input tokens 包含各问题重复的工单文本。

每美元可处理的百万 model input tokens，越高越好。仅 English model，对比 A100、H100 的实测最快实现与 TPU v6e Pallas。上图每次一个问题，下图每次 50 个问题。价格、日期和供应商见上文；preemptible / spot 沿用报告的价格假设。

# 总结

deciax 把 Laya 的结构化决策能力带到了 TPU 上。这次实验中，普通 JAX 已经能把单问题调用做到约 2 ms，Pallas 在这个形状下的额外收益很小；当每次调用增加到 50 个问题，融合后的 Pallas 路径相较普通 JAX 提速约 2.3 倍。问题数改变了主要开销，也改变了优化的收益。

在本文测试的输入、模型和实现范围内，v6e Pallas 的单问题和 50 问题延迟都低于参与对比的 GPU 实现。

如果你想试试 deciax，可以在 Colab 中体验，也可以到 GitHub 仓库查看代码。

# 致谢

感谢 2026 TPU Builders Program 和 TPU Research Cloud（TRC）为本文工作提供 TPU 计算资源。

本文性能数据来自开发版本 6f3a930。 ↩︎
输入采用上游的 Payout failing 工单，问题交替使用 noul 和 choice。每组先预热 20 次，再计时 20 次，并等待设备计算完成。 ↩︎
耗时拆解图中的 GPU p50 来自 profiling 配套的独立计时，与前一张基线图的测试序列不同。 ↩︎
本次报告中的 Pallas 路径融合了 norm、QKV 投影、RoPE、attention、输出投影和 MLP。对于序列长度不超过 512 的路径，每层使用一次 pallas_call。 ↩︎
Nebius Spot 使用起始价；TPU preemptible 使用报告快照。 ↩︎
English model 每次单问题调用有 194 个 model input tokens，每次 50 问题有 9975 个。吞吐采用报告记录的 input tokens/s，由输入 token 数除以原始 p50 延迟得到。 ↩︎

HLO Visualizer：把 XLA HLO 变成看得懂的图

junyi.h@comp.nus.edu.sg (Junyi Hou) — Sat, 10 Oct 2026 14:00:00 +0800

调 JAX / TPU 程序的时候，迟早会碰到 HLO。想知道一个计算被编译成了什么、为什么多出几次 copy、一个 fusion 里到底装了哪些操作，最后都要打开编译器吐出来的那份文本。

指令里挤着 shape、layout、tiling、memory space 和 computation 引用，光认出 bf16 和 fusion 还远远不够。

所以我做了 HLO Visualizer：把 HLO 文本变成可以探索的图，点一下节点，就能把这条指令一块一块地读明白。

# 从「画出计算图」到「读懂这条指令」

官方已经有 HLO 可视化工具了：XProf 的 Graph Viewer。它能围绕某条操作查看依赖关系、展开或折叠 fusion，并把图与 profiling 数据关联起来。定位到耗时操作后，再跳进图里看它的上下游，这个工作流很有用。官方文档也介绍了这些功能。

XProf Graph Viewer。图片来自 OpenXLA 官方文档，按 CC BY 4.0 署名使用。

HLO Visualizer 把图和指令解释放在同一个界面里。图上的节点按输入、计算、数据搬运、控制流等类别区分；选中节点后，可以追踪上下游，查看原始 HLO，再进入它引用的 computation。读图和读指令之间不需要一直切换窗口。

HLO Visualizer 的 attention 示例：先看清输入、数据搬运和 fusion 之间的关系，再点击节点看细节。与上面的官方截图使用不同程序，展示的是界面与阅读方式。

XProf 的强项是把 HLO 与真实运行表现联系起来。我的工具更侧重 拿到一份 HLO 文本，就开始理解它。

# 把教程放到你正在读的指令旁边

Google DeepMind 的 How to Scale Your Model 中，How to read an XLA op 是很好的入门材料：它用一条 fusion 说明名称、类型、布局、内存位置和输入该怎么读。OpenXLA 的 Operation semantics 则适合查操作的准确语义。

读完教程，再面对自己的 HLO，还是需要把这些知识逐项对应回去。

比如下面是一条简化的指令：

%x = bf16[128,128]{1,0:T(8,128)(2,1)S(1)} parameter(0)

它同时包含几层信息：

%x 是这条指令结果的名字。
bf16[128,128] 是逻辑类型和 shape。
1,0 是布局的 minor-to-major 维度顺序。
T(8,128)(2,1) 表示两层物理 tiling。
S(1) 在这里的 TPU 示例中表示 VMEM。
parameter(0) 表示当前 computation 的第 0 个输入。

Inspector 会把原始指令分成对应的彩色片段，解释名称、操作、输入和属性。类型还可以继续展开，分别看 shape、维度顺序、tiling 和内存空间；tuple 里的元素也能逐层查看。

一条 while 指令拆开以后，循环状态、condition 和 body 就有了各自的解释。

# TPU 的 layout，直接画出来

HLO 里一个很重要的部分是 layout。逻辑 shape 和物理存储布局是两回事：一个 128 × 128 的数组，还可以按 tile 分块，再在 tile 内继续分块。OpenXLA 的 Shapes and layout 与 Tiled layout 给出了正式说明。

对于 TPU 示例里常见的 T(8,128)(2,1)，HLO Visualizer 会画出 tile 的一个局部，标明元素在 tile 内的物理偏移和内层 tile 的边界。这样就能把字符串里的两组数字和实际排列对应起来。

8×128 外层 tile 的左上角；红框是 2×1 内层 tile，格子里的数字是 tile 内的物理偏移。

工具也会按 TPU 的内存空间解释 HBM、VMEM、SMEM 等位置，帮助理解数据搬运指令。这里的空间编号与后端有关，文章和截图里的解释以项目提供的 TPU v6e 示例为背景。

# 用一个小程序开始

内置示例来自 21 个在 TPU v6e 上编译的 JAX 小程序，每个都提供优化前和优化后的 HLO。你可以从 attention 看输入和 fusion，也可以从 fori_matmul 看循环，或者从 gather_scatter 看索引操作。

一个简单的学习顺序是：打开示例，从左侧进入入口 computation，点一个节点看输入和结果类型，再进入 fusion 或 while 引用的 computation。然后在 Examples 中切换同一个程序的 Before / After，观察编译前后图的变化。

如果想看自己的代码，可以按照 JAX 的 lowering / compilation 接口导出 HLO：

import jax
import jax.numpy as jnp

def f(x, w):
 return jax.nn.relu(x @ w)

x = jnp.ones((128, 128), dtype=jnp.bfloat16)
w = jnp.ones((128, 128), dtype=jnp.bfloat16)
lowered = jax.jit(f).lower(x, w)

# 优化前的 HLO
print(lowered.as_text(dialect="hlo"))

# 编译后的 HLO；具体布局与内存空间取决于后端
print(lowered.compile().as_text())

复制其中一份输出，点击 Open HLO 粘贴进去即可。XLA 通过 --xla_dump_to 导出的 HLO 文本也可以打开。

我希望第一次学习 HLO 的人，也能从一个小程序开始，把抽象的语法和眼前的计算对应起来。打开图，点一条指令，顺着数据往下看。

试试 HLO Visualizer。如果它让你更容易读懂自己的 HLO，欢迎给 GitHub 仓库点个 star；遇到看不懂或解析不对的指令，也欢迎提 issue。

LLM Inference on TPU v6e-4: Small Dense, Large MoE, and Large Dense Models

junyi.h@comp.nus.edu.sg (Junyi Hou) — Thu, 11 Jun 2026 00:00:00 Z

# Abstract

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.

The MoE model is fastest in all three tests. It reaches 26,063 tok/s in prefill, compared with 19,714 tok/s for the dense 32B model. At batch size 1, its decode latency is 7.0 ms per token, compared with 17.9 ms for the dense 32B model. In online serving, it reaches 1.27 req/s and 1,303 output tok/s, compared with 0.88 req/s and 901 output tok/s for the dense 32B model.

The 4B model has good latency at low load, but it does not handle high concurrency well on one chip. Its stable serving capacity is about 0.45 req/s.

The goal is to report TPU v6e performance using the same vLLM tools that users would run in practice.

# 1. Motivation

Public TPU data for LLM inference is limited. The only TPU submission Google has made to MLPerf Inference is SDXL image generation, not an LLM. The TPU LLM numbers are measured on Google’s JAX/JetStream stack rather than the vLLM path most practitioners deploy.

We measured the performance ourselves on one TPU v6e-4 host. The goal is to give simple, reproducible numbers for three common model types:

a small dense model,
a large MoE model,
a large dense model.

# 2. Experimental Setup

All measurements use one TPU v6e-4 host with four chips in one VM. The 4B model uses one chip. The 30B-A3B and 32B models use all four chips. For per-chip numbers, we divide the four-chip throughput by four.

We use vLLM 0.20.0, JAX 0.10.0, libtpu 0.0.40, Python 3.11 with the tpu-inference backend. The KV cache uses fp8_e5m2 in all runs. We report exact versions because TPU performance can change quickly across releases.

Model	Type	Total / active params	Parallelism	Chips	Config
Qwen3.5-4B	dense	4B / 4B	tp1	1	GDN, MBT2048
Qwen3-30B-A3B	MoE	30B / 3B	tp4	4	GMU0.8, MBT8192
Qwen3-32B	dense	32B / 32B	tp4	4	GMU0.8, MBT8192

Table 1. Model configurations used in all experiments. GDN = guided decoding off, GMU = GPU memory utilization, MBT = max-num-batched-tokens.

The key comparison is between Qwen3-30B-A3B and Qwen3-32B. They have similar total size, but the MoE model only uses 3B parameters per token, while the dense 32B model uses all 32B.

We run three tests.

For prefill, we use concurrency 1 and output length 1. We vary context length over 512, 1024, 2048, 4096, and 8192 tokens. This measures how fast the model processes the input prompt.

For decode, we fix the output length at 128 tokens and vary batch size over 1, 4, 16, and 64. We mainly report context length 1024, with context length 4096 as a longer-KV case. This measures the cost of generating tokens after prefill.

For online serving, we use vllm bench serve against the OpenAI-compatible endpoint. Input and output lengths are both 1024 tokens. We increase the request rate until the server saturates.

Metrics:

TTFT: time to first token. This mainly measures prefill.
TPOT: time per output token. This mainly measures decode.
E2E latency: full request time.
Prefill throughput: context length divided by p50 TTFT.
Decode throughput: batch size × 1000 divided by p50 TPOT.
Output throughput: generated tokens per second.
Request throughput: completed requests per second.

We report p50 unless stated otherwise.

# 3. Results

## 3.1 Prefill

Figure 1. Prefill throughput versus context length. Higher is better. Throughput is aggregate over the chips each model uses — the 30B-A3B and 32B use four chips, the 4B uses one.

The MoE model has the highest prefill throughput.

Model	Best prefill throughput	Per-chip peak
Qwen3-30B-A3B	26,063 tok/s	~6.5k tok/s
Qwen3-32B	19,714 tok/s	~4.9k tok/s
Qwen3.5-4B	4,177 tok/s	~4.2k tok/s

Table 2. Peak prefill throughput and per-chip peak for each model.

Model	ctx 512	ctx 1024	ctx 2048	ctx 4096	ctx 8192
Qwen3-30B-A3B	35 ms	51 ms	84 ms	157 ms	318 ms
Qwen3-32B	38 ms	58 ms	104 ms	208 ms	461 ms
Qwen3.5-4B	432 ms	452 ms	495 ms	983 ms	1,961 ms

Table 3. p50 TTFT at each context length (ms).

The 4B result is limited by its single-chip setup and by max-num-batched-tokens=2048. For contexts above 2048, prefill is split into chunks, so the curve flattens.

## 3.2 Decode

Figure 2. Decode p50 TPOT versus batch size. Solid lines: context 1024. Dashed lines: context 4096. Lower is better.

Figure 3. Aggregate decode throughput versus batch size. Solid lines: context 1024. Dashed lines: context 4096. Higher is better. Throughput is aggregate over the chips each model uses — the 30B-A3B and 32B use four chips, the 4B uses one.

Model	BS	p50 TPOT	p99 TPOT	throughput
Qwen3-30B-A3B	1	7.0 ms	7.1 ms	143 tok/s
Qwen3-30B-A3B	4	8.8 ms	9.9 ms	456 tok/s
Qwen3-30B-A3B	16	14.9 ms	17.5 ms	1,071 tok/s
Qwen3-30B-A3B	64	48.1 ms	152.7 ms	1,331 tok/s
Qwen3-32B	1	17.9 ms	17.9 ms	56 tok/s
Qwen3-32B	4	18.2 ms	19.4 ms	220 tok/s
Qwen3-32B	16	22.4 ms	27.4 ms	715 tok/s
Qwen3-32B	64	58.4 ms	65.3 ms	1,096 tok/s
Qwen3.5-4B	1	10.7 ms	10.7 ms	93 tok/s
Qwen3.5-4B	4	16.2 ms	18.3 ms	247 tok/s
Qwen3.5-4B	16	41.4 ms	647.3 ms	387 tok/s
Qwen3.5-4B	64	80.5 ms	97.2 ms	795 tok/s

Table 4. Decode TPOT at context length 1024 (p50, p99, and aggregate throughput).

Model	BS	p50 TPOT	p99 TPOT	throughput
Qwen3-30B-A3B	1	7.0 ms	7.1 ms	143 tok/s
Qwen3-30B-A3B	4	9.7 ms	12.9 ms	411 tok/s
Qwen3-30B-A3B	16	22.3 ms	28.5 ms	719 tok/s
Qwen3-30B-A3B	64	96.8 ms	213.9 ms	661 tok/s
Qwen3-32B	1	19.1 ms	19.3 ms	53 tok/s
Qwen3-32B	4	21.4 ms	25.2 ms	187 tok/s
Qwen3-32B	16	37.7 ms	130.6 ms	424 tok/s
Qwen3-32B	64	82.5 ms	92.8 ms	775 tok/s
Qwen3.5-4B	1	10.8 ms	10.8 ms	93 tok/s
Qwen3.5-4B	4	25.3 ms	34.1 ms	158 tok/s
Qwen3.5-4B	16	85.0 ms	89.2 ms	188 tok/s
Qwen3.5-4B	64	85.0 ms	89.2 ms	753 tok/s

Table 5. Decode TPOT at context length 4096 (p50, p99, and aggregate throughput).

At batch size 1, the MoE model is 2.5× faster than the dense 32B model: 7.0 ms versus 17.9 ms at context 1024. This follows active parameter count. Decode is memory-bandwidth-bound. The MoE model reads 3B active parameters per token; the dense 32B model reads all 32B.

Tail latency — the p99 columns of Tables 4 and 5 — stays tight for the four-chip models until BS64 (the 30B-A3B reaches p99 152.7 ms against a 48.1 ms p50 at ctx 1024). The 4B model on one chip is the outlier: at BS16 ctx 1024 its p99 TPOT reaches 647.3 ms against a 41.4 ms p50. These decode runs are driven at an unlimited request rate, so on the single chip the prefill chunks of newly admitted requests repeatedly preempt in-flight decode — the median inter-token latency stays near 12 ms while a heavy minority of requests stall. This marks the 4B’s single-chip concurrency limit, not steady-state decode.

At context 4096, longer KV sequences reduce throughput across all models. The 30B-A3B at BS64 drops from 1,331 tok/s (ctx 1024) to 661 tok/s (ctx 4096). The dense 32B drops less in relative terms (1,096 to 775 tok/s) because its compute is already the bottleneck at ctx 1024. The 4B model saturates at BS16 for ctx 4096: p50 TPOT at BS64 equals BS16 (85.0 ms both), meaning additional concurrency gives no throughput gain on one chip.

## 3.3 Online serving

Figure 4. Online serving throughput and latency. The x-axis is output throughput. The y-axis is p50 TPOT. Lower-right is better. Throughput is aggregate over the chips each model uses — the 30B-A3B and 32B use four chips, the 4B uses one.

In online serving, higher request rate gives higher throughput, but also higher latency. Each model reaches a point where adding more requests no longer helps.

Figure 5. End-to-end latency sweep. Left: p50 TTFT versus output throughput. Right: p50 TPOT versus output throughput. The × marker on the 4B line marks the concurrency-collapse point under unlimited load. Throughput is aggregate over the chips each model uses — the 30B-A3B and 32B use four chips, the 4B uses one.

Req rate	Actual req/s	Output tok/s	TTFT p50	TTFT p99	TPOT p50	TPOT p99	E2E p50
0.2	0.19	197	90 ms	2,682 ms	7.9 ms	9.0 ms	8.2 s
0.4	0.36	366	92 ms	190 ms	9.2 ms	10.1 ms	9.5 s
0.6	0.52	537	94 ms	1,331 ms	11.2 ms	13.8 ms	11.6 s
0.8	0.62	635	116 ms	6,335 ms	18.8 ms	28.7 ms	24.6 s
∞	1.27	1,303	712 ms	1,092 ms	22.3 ms	22.8 ms	23.6 s

Table 6. Qwen3-30B-A3B online serving results (ISL = OSL = 1024 tokens).

Req rate	Actual req/s	Output tok/s	TTFT p50	TTFT p99	TPOT p50	TPOT p99	E2E p50
0.15	0.14	144	115 ms	2,243 ms	18.0 ms	18.3 ms	18.5 s
0.3	0.26	271	115 ms	1,042 ms	18.9 ms	20.1 ms	19.5 s
0.45	0.37	380	116 ms	295 ms	19.5 ms	20.9 ms	20.2 s
0.6	0.45	466	123 ms	3,983 ms	21.0 ms	28.1 ms	21.7 s
∞	0.88	901	1,190 ms	9,249 ms	43.2 ms	44.0 ms	45.4 s

Table 7. Qwen3-32B online serving results (ISL = OSL = 1024 tokens).

Req rate	Actual req/s	Output tok/s	TTFT p50	TTFT p99	TPOT p50	TPOT p99	E2E p50
0.2	0.19	194	509 ms	33,147 ms	12.3 ms	15.4 ms	13.1 s
0.3	0.28	283	507 ms	1,185 ms	12.8 ms	14.3 ms	13.7 s
0.4	0.36	367	506 ms	1,099 ms	13.4 ms	15.7 ms	14.4 s
0.45	0.40	407	507 ms	1,141 ms	13.8 ms	15.9 ms	14.6 s
∞	0.14	143	6,762 ms	219,855 ms	133.8 ms	237.2 ms	206.8 s

Table 8. Qwen3.5-4B online serving results (ISL = OSL = 1024 tokens).

The MoE model (30B-A3B) has a stable working zone up to about 0.6 req/s, where p50 TPOT stays below 12 ms and p99 TTFT stays below 1.4 seconds. At 0.8 req/s the server is already queuing: p99 TTFT jumps to 6.3 seconds while p50 TPOT jumps from 11 ms to 19 ms. Saturation at ∞ rate gives tight p99/p50 TPOT (22.8 ms versus 22.3 ms), meaning the server is consistently loaded with no idle cycles.

The dense 32B model’s TPOT p50 is nearly flat from 0.15 to 0.6 req/s (18–21 ms), then doubles at saturation (43.2 ms). Its TTFT p99 is noisy across the sweep, suggesting occasional prefill bursts even at low load.

The 4B model holds stable from 0.2 to 0.45 req/s. At 0.45 req/s it sustains 0.40 req/s and 407 output tok/s, with TPOT p50 of 13.8 ms and E2E p50 of 14.6 seconds. Under unlimited load it collapses entirely: output throughput drops from 407 tok/s to 143 tok/s, p50 TPOT rises from 13.8 ms to 133.8 ms, and p50 E2E latency reaches 206.8 seconds. The p99 TTFT at unlimited load is 219,855 ms — 220 seconds. This is not a degraded state; it is a broken one. We treat the unlimited-load point as a single-chip concurrency limit, not useful serving capacity.

Model	p50 TTFT	p50 E2E latency
Qwen3-30B-A3B	712 ms	23.6 s
Qwen3-32B	1,190 ms	45.4 s
Qwen3.5-4B	507 ms	14.6 s

Table 9. p50 TTFT and p50 E2E latency at the saturation or stable operating point.

Figure 6. Summary relative to the dense Qwen3-32B baseline. Higher is better.

Across all three tests, the MoE model beats the dense 32B model at similar total parameter count:

Metric	Qwen3-30B-A3B	Qwen3-32B
Best prefill throughput	26,063 tok/s	19,714 tok/s
BS1 decode TPOT	7.0 ms	17.9 ms
Serving capacity	1.27 req/s	0.88 req/s
Output throughput at saturation	1,303 tok/s	901 tok/s

Table 10. Summary comparison of Qwen3-30B-A3B versus Qwen3-32B across all three tests.

The MoE model gives about 2.5× lower single-stream decode latency, about 1.4× higher serving capacity, and about 1.3× higher prefill throughput.

# 4. Discussion

The large MoE and dense models have similar total parameter counts but different active sizes. The lower active parameter count helps explain the MoE model’s decode advantage.

The small 4B model is limited by its single-chip setup. To serve more traffic, the better path is to add chips or replicas, rather than increasing concurrency on one chip.

# 5. Conclusion

In these tests, Qwen3-30B-A3B has the highest prefill throughput, the lowest batch-size-1 decode latency, and the highest serving capacity. The 4B dense model has good low-load latency, but its single-chip setup limits concurrency.

# Limitations

These results are for one host only: four TPU v6e chips in one VM. We did not test multi-host scaling.

We did not run a GPU baseline, so this study makes no TPU-versus-GPU claim.

The online serving test uses one input/output shape: 1024 input tokens and 1024 output tokens. Other workloads may shift the balance between prefill and decode.

The results are version-specific. TPU support in vLLM changes quickly, so the numbers here apply to vLLM 0.20.0.

All runs use an fp8_e5m2 KV cache. We did not test other KV cache formats.

# Reproducibility

The main numbers are ./data.json

Figures are generated by ./figures/plot.py

Per-model results are at ./rawdata.zip

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、修复编译错误，接着执行下一步。我已经在所有服务器上安装了它。短板是幻觉，尤其是在生成大段文档、或者引用它没吃透的大型系统时，它会编东西出来。

## 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 长什么样

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

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

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

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

组合这些 Agent 时，我会同时看基座模型和工具的执行流程。

例如，Anthropic 的 Claude 3.5 Sonnet 可以在多个环境中使用：

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

在我用过的工程工作流里，即使使用相同模型，不同工具的执行体验也有差别。Claude Code 的文件操作、命令执行和错误恢复配合起来更顺手。

# 社区里的类似探索

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

# 写在最后

除了给同一个模型分配不同角色，我也会考虑模型本身和 Agent 工作方式的差异。LLM-DNA 是一个分析语言模型之间进化关系和功能差异的研究框架，已在 ICLR'26 以 Oral 形式发表，可以用来观察模型之间的差异。

在我的项目里，Claude Code 和 Gemini CLI 配合起来最顺手：Claude 负责写代码和执行，Gemini 负责结合整个仓库检查改动。

用 nerdctl + Tailscale Sidecar 让容器流量走 Exit Node：踩坑全记录

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

在容器化部署中，有时候我们需要让容器的所有出站流量通过特定的网络出口。Tailscale 的 sidecar 模式可以做到这一点：用一个 Tailscale 容器作为 sidecar，其他容器共享它的网络命名空间，流量通过 WireGuard 隧道经由远端 exit node 出去。

这个方案在 Docker Compose 下很成熟，但迁移到 nerdctl（containerd）时，我踩了一连串的坑。记录下来，希望能帮后来人少走弯路。

# 最终目标

让任意容器通过 Tailscale sidecar 接入 tailnet，所有出站流量经由远程 exit node 转发。架构如下：

为了方便验证网络是否通畅，我用 nicolaka/netshoot 作为测试容器——它自带 curl、dig、tcpdump、iperf 等一整套网络排查工具，比临时装工具方便得多。

# 坑 1：nerdctl compose 不支持 `network_mode: service:xxx`

Docker Compose 支持 network_mode: service:<service_name> 语法，它会自动把 service 名解析为对应容器的网络命名空间。但 nerdctl compose 没有实现这个翻译层，直接报错：

unsupported network_mode: service:tailscale-sidecar

解法： 改用 network_mode: container:<container_name>，并通过 container_name 字段固定 sidecar 容器的名称。

services:
 tailscale-sidecar:
 container_name: tailscale-sidecar # 固定名称
 # ...
 netshoot:
 network_mode: container:tailscale-sidecar # 用容器名而非服务名

如果不固定 container_name，nerdctl compose 会自动生成类似 blockchain-tailscale-sidecar-1 的名称，导致引用不匹配。

# 坑 2：Tailscale ACL 中未定义 tag

启动后 Tailscale 容器立即退出，日志显示：

Received error: requested tags [tag:container] are invalid or not permitted

解法： 在 Tailscale 管理后台的 ACL 策略中添加 tag 定义，并在生成 auth key 时勾选对应 tag：

"tagOwners": {
 "tag:container": ["autogroup:admin"]
}

# 坑 3：缺少 `SYS_MODULE` capability

这个坑最隐蔽。容器能正常加入 tailnet，tailscale ping 也通，但开启 exit node 后 TCP 流量完全不通，只有 ICMP 能过。

原因是内核模式（TS_USERSPACE=false）需要加载 xt_mark、nf_nat 等内核模块来设置 iptables 转发规则。缺少 SYS_MODULE capability 时，这些模块无法加载，iptables 规则写入但不生效，表现为 ICMP 正常而 TCP 断流。

解法：

cap_add:
 - net_admin
 - SYS_MODULE # 必须加上

# 坑 4：Exit Node 模式下 DNS 失败

开启 exit node 后，容器所有出站流量都走 WireGuard 隧道到远端 exit node 再出去。但 /etc/resolv.conf 里的 DNS 服务器仍然是本地地址（如 10.0.2.3），这些地址从 exit node 那端是不可达的，DNS 查询自然失败。

症状是 curl ifconfig.me 报 Could not resolve host，而直接用 IP 访问则卡住或返回异常。

解法： 让 Tailscale 接管 DNS，查询也走隧道：

environment:
 - TS_ACCEPT_DNS=true

# 最终可用的 compose.yaml

services:
 tailscale-sidecar:
 image: tailscale/tailscale:latest
 container_name: tailscale-sidecar
 hostname: tailscale-sidecar
 environment:
 - TS_AUTHKEY=${TS_AUTHKEY}
 - TS_EXTRA_ARGS=--advertise-tags=tag:container --exit-node=${TS_EXITNODE}
 - TS_STATE_DIR=/var/lib/tailscale
 - TS_USERSPACE=false
 - TS_ACCEPT_DNS=true
 volumes:
 - ${PWD}/tailscale-sidecar/state:/var/lib/tailscale
 devices:
 - /dev/net/tun:/dev/net/tun
 cap_add:
 - net_admin
 - SYS_MODULE
 restart: unless-stopped

 netshoot:
 image: nicolaka/netshoot
 depends_on:
 - tailscale-sidecar
 network_mode: container:tailscale-sidecar
 command: sleep infinity

需要在同目录下准备 .env 文件：

TS_AUTHKEY=tskey-auth-xxxxx
TS_EXITNODE=100.x.x.x

# 验证方法

nicolaka/netshoot 自带丰富的网络工具，非常适合验证：

# 检查出口 IP，确认流量是否走了 exit node
nerdctl exec -it netshoot curl ifconfig.me

# DNS 解析测试
nerdctl exec -it netshoot dig google.com

# 查看路由表
nerdctl exec -it netshoot ip route show table all

# 抓包排查
nerdctl exec -it netshoot tcpdump -i any -n

# Tailscale 侧的状态检查
nerdctl exec -it tailscale-sidecar tailscale status
nerdctl exec -it tailscale-sidecar tailscale exit-node status
nerdctl exec -it tailscale-sidecar tailscale ping <exit-node-ip>

# 排查思路总结

这次排查的过程本身也值得回顾。面对"exit node 不工作"这样的复合问题，有效的方法是逐层剥离：

先确认隧道连通性： tailscale ping 验证 WireGuard 隧道本身是否通。
对比实验： 关掉 exit node 测试，确认问题出在 exit node 还是基础网络。
区分协议： ICMP 通但 TCP 不通，指向 iptables/内核模块问题。
区分 DNS 和连通性： 用 IP 直连绕过 DNS，分别定位。
对比已知可用的配置： 发现之前能用的命令多了 SYS_MODULE，一下锁定问题。

每一步缩小范围，避免在错误的方向上浪费时间。

# 写在最后

nerdctl compose 作为 Docker Compose 的替代方案已经很成熟了，但在细节兼容性上仍有差距。network_mode: service: 的缺失、容器名的自动生成规则不同，这些都是迁移时容易踩到的坑。而 Tailscale 在容器中使用 exit node 时，SYS_MODULE 和 TS_ACCEPT_DNS 是两个容易被忽略但又不可或缺的配置。希望这篇记录能帮到遇到同样问题的人。

从像素到笔触：跨越十年的凝视

junyi.h@comp.nus.edu.sg (Junyi Hou) — Wed, 07 Jan 2026 15:16:00 +0800

INTO THE MODERN

2026 年初，我在新加坡 “INTO THE MODERN” 印象派画展中，第一次站在莫奈Monet的原作前。

颜料层层堆叠，笔触清晰可见，仿佛凝固了百年前某个晨光熹微或日暮西沉的瞬间。那一刻，我想起整整十年前（2016 年）的一个寂静的周日，我坐在电脑前，对着屏幕一页页翻找图片，为美术课挑选自己要介绍的画，主题是《从传统走向现代》。那时的我，连“印象派Impressionism”三个字都还陌生，更无法想象未来某天，竟能与这些曾只存在于像素中的杰作面对面。

展览虽未展出莫奈最著名的作品，却意外地完整：莫奈Monet、雷诺阿Renoir、西斯莱Sisley、塞尚Cézanne。这四位曾同窗于格莱尔画室Gleyre’s Studio的青年，如今以画作重聚。莫奈的画，颜料厚重如浮雕，可以清楚地看到笔触堆叠成厚厚的一团。雷诺阿用柔光晕染人脸，明亮却朦胧。西斯莱的风景静谧而克制。而塞尚，我对他没有太多的印象…

Haystacks 干草堆, 1890 - Claude Monet
（颜料厚重如浮雕，可以清楚地看到笔触堆叠成厚厚的一团）

这次展览最令我惊喜的是保罗·西涅克Paul Signac，他的画，色彩上保留了印象派的味道，但技法上却截然不同。画布上没有挥洒的笔触，取而代之的是无数细密的色点。后来我才知道，保罗·西涅克是“点彩派”的代表画家。

View of the Seine at Herblay 埃尔布莱的塞纳河景, 1889 - Paul Signac

Port of Saint-Cast 圣卡斯特港, 1889 - Paul Signac

站在展厅中，记忆倒流回那个试图在 PPT 里讲清楚 “从传统走向现代” 的高中生。那时的我，仅仅通过维基百科和一些图片来了解这些画作，并且轻易为每个流派贴上标签：

新古典主义追求严谨构图与科学透视，后期却流于空洞的教条形式；
浪漫主义在神话与激情中寻找崇高，最终却滑向情绪的浮夸；
写实主义将目光投向平民与日常，却仍未突破传统叙事的框架；
印象派挣脱画室，捕捉瞬息光色，却在对视觉印象的迷恋中，几乎遗忘了形体的结构；
后印象派彻底转身向内：梵高燃烧内心的火焰，高更逃向象征的彼岸。他们不再追求 “世界看起来如何”，而转向 “我如何感受世界”。
……

美的探索从未停歇。十年过去，我不再只是隔着屏幕，阅读那段被平滑叙述后的历史。如今站在原作前，我真正感受到了那场混乱、激烈、充满不确定性的创造过程。除了色彩与笔触的震撼，更有一种深沉的历史回响。与其说我在和艺术家对话，不如说我在和自己对话。

艺术的现代之路，本就是在理性与感性、秩序与自由之间，不断裂变与重组。

画布背后，都是一个个活生生的人。他们在质疑与孤独中，依然选择相信自己的眼睛。

“There really is no such thing as Art. There are only artists.”
— E. H. Gombrich, The Story of Art

用 Dev Container 配置 VS Code + LaTeX 环境

junyi.h@comp.nus.edu.sg (Junyi Hou) — Tue, 23 Sep 2025 13:02:12 +0800

这套配置用 Dev Container¹ 管理 LaTeX 环境，用 Git 同步项目。拉取仓库后，在容器中打开即可编译。

# 安装编辑器扩展

在 Cursor 或 VSCode 中，安装官方扩展 Dev Containers

Cursor 中的 Dev Container

VS Code 中的 Dev Container

# 三个步骤，从 0 到能写 LaTeX

假设你已有一个 LaTeX 项目文件夹（新建空文件夹也可以），跟着做就能用：

## Step 1 引入 Dev Container 配置

打开项目的终端（VSCode/Cursor 内置终端即可），执行以下命令，将预配置好的容器环境作为「子模块」引入项目（子模块不干扰主项目文件，方便后续更新）：

git submodule add https://github.com/paperdebugger-bot/latex-devcontainer.git .devcontainer

如果你的项目还没初始化 Git（git init），也可以直接下载配置文件解压到 .devcontainer 文件夹：latex-devcontainer.zip

## Step 2 重载编辑器窗口

按下快捷键 Ctrl + Shift + P（macOS 是 ⌘ + ⇧ + P），在弹出的命令面板中输入 Reload Window 并执行，让编辑器识别新添加的容器配置。

## Step 3 启动容器并使用

重载后，编辑器会自动弹出提示「是否在 Dev Container 中打开项目」，点击 Reopen in Container；

接下来会让你选择容器版本，直接选 full 即可 —— 等待 3-5 分钟（首次构建需下载镜像，后续会快很多），环境就搭建完成了！

🎉 完成后你会获得什么？

预装 TeX Live Full 发行版（几乎包含所有宏包，不用手动装）；
自带 LaTeX Workshop 插件（支持实时预览、一键编译）²；
配置好的 PDF 预览 功能；
干净的终端环境（可直接用 pdflatex xelatex 等命令）。

# 进阶选择：不同的容器版本怎么挑？

上面推荐的 full 版本是「省事优先」，但如果你的项目轻量化、或想节省磁盘空间，可以选其他版本。核心区别在于「预装的 TeX 发行版」不同：

容器版本	核心 TeX 发行版	特点	适合场景
full	TeX Live Full	预装较完整的宏包（约 6GB），减少手动安装	复杂论文、自定义模板、不想处理宏包问题
tiny	TinyTeX³	轻量版（约 1GB），默认含 200+ 常用宏包	简单报告、常规学术论文（缺包时需手动 `tlmgr install 宏包名`）
nano	Tectonic⁴	零配置引擎，自动处理依赖	快速写 Demo、极简文档（兼容性略弱，复杂宏包可能不支持）

💡 切换方法：
在启动容器时，选择对应版本即可；如果已启动容器，可通过 Ctrl + Shift + P → Dev Containers: Rebuild Container 重新选择版本。

# 常见问题 Q&A

Q1：构建容器时速度很慢？

A1： 首次构建需下载大镜像，建议换国内 Docker 镜像源（比如阿里云、网易云镜像），或在网络较好的环境下操作。

Q2：编译中文文档乱码？

A2： full 和 tiny 版本已预装 xeCJK 宏包，编译时选择 xelatex 引擎即可（LaTeX Workshop 已默认配置）。

Q3：如何更新容器配置？

A3： 如果远程仓库的 latex-devcontainer 有更新，可在项目终端执行：

git pull --recurse-submodules
git submodule update --recursive --remote

然后重建容器（Rebuild Container）即可应用更新。

这套方案我自己用了半年，从写技术报告到学术论文，没再遇到过一次「环境报错」。如果你也厌倦了配置 LaTeX 环境，不妨试试。

Dev Containers 官方文档：了解容器配置的更多细节 ↩︎
LaTeX Workshop 插件文档：掌握更多编译、预览技巧 ↩︎
TinyTeX 官方网站：轻量 TeX 发行版的使用指南 ↩︎
基于 tinytex 的中文本地 TeX 环境：如何配置 tinytex 环境 ↩︎

从树莓派到 NUC：玩具的升级

junyi.h@comp.nus.edu.sg (Junyi Hou) — Fri, 05 Sep 2025 13:07:09 +0800

我把日常跑轻量服务的树莓派 4B 换成了 Intel NUC，处理器从 ARM 换成 x86，存储从 TF 卡换成 SSD。

# 树莓派的功与过

树莓派 4B 用来监控家庭网络流量、跑自动化脚本，偶尔充当开发测试环境。我还配置了每周日自动重启的定时任务。

但树莓派的短板也随着使用深度逐渐暴露。最让我焦虑的是 TF 卡的存储可靠性，即便选用了号称"耐用级"的 Endurance 卡，也无法完全避免潜在的 I/O 风险。在上一篇关于树莓派 5 集群配置 k3s的文章发布后，我的四节点集群仅稳定运行了一周，就有一个节点因突发大量 I/O Error 彻底挂掉，而它用的正是我精心挑选的高耐久卡，寿命甚至不如 4B 上的普通卡。

编译较大的项目时要等很久，同时跑多个服务也偶尔卡顿。虽然可以外接 SSD 缓解存储问题，但我最后选择了换成 NUC。

# 换成 NUC

NUC 的机身比树莓派大不了多少，但金属外壳明显更重。我给它装了 Ubuntu Desktop 24.04。同一个 Go 项目，在树莓派上编译需要 3 分钟，在 NUC 上需要 1 分钟。

Fig.1 - Intel NUC

换成内置 SSD 后，我也敢在本地跑一个小型数据库了，以前总担心频繁读写会烧卡。

退役的树莓派会继续作为边缘计算节点使用。

MacBook Pro M1 键帽更换指南

junyi.h@comp.nus.edu.sg (Junyi Hou) — Fri, 01 Aug 2025 01:16:29 +0800

众所周知，键帽一旦“打油”，就很难通过简单擦拭恢复原状。我曾尝试用砂纸打磨键帽，但不仅效果更差，产生的碎屑还会掉进缝隙里。你可以在图中看到我打磨过的 Shift 和 Space，外观变得非常难看。

虽然有人说可以去 Apple 直营店更换键帽¹，但据说每次只能更换几个。对于我这种整块键盘都打油的情况，显然还是自己动手来得更实际。

写这篇博客的原因是，我发现网上几乎找不到一篇完整介绍 MacBook Pro M1 键帽更换的教程。大多数视频²只演示了普通按键的拆解，也就是字母键和数字键，没有介绍长键帽，比如 Space、Caps Lock、ESC，以及方向键的处理方式。而这些键的结构明显不同，拆装方式也更复杂。

上为换键帽前，下为换键帽后

我在淘宝上购买了全套键帽，花了 85 元，打算自己更换：

淘宝购买的全套键帽

后来才看到，闲鱼全套键帽每套只要 ¥20 到 ¥40³。

# 拆掉旧键帽

MacBook Pro 使用的是剪刀脚结构，因此我们必须遵循剪刀脚键盘的拆解方法。

## 普通按键拆装

操作步骤：

定位卡扣: 每个普通键帽都有四个卡扣，分别位于四个角
从右下角开始: 用撬棒微微翘起键帽右下角，听到轻微的"啪"声表示卡扣已释放
接着左下角: 重复同样操作释放左下角的卡扣
提起键帽: 当下方两个卡扣都释放后，轻轻向上提起整个键帽
完全取下: 上方卡扣会自然脱离

注意事项：

⚠️ 不要用力过猛，剪刀脚结构比较脆弱
⚠️ 避免直接向上拉扯，可能会损坏卡扣
💡 建议使用塑料撬棒而不是金属工具，避免刮伤

你可以参考这个视频²，视频中演示了普通按键的拆解方法。

安装键帽与拆卸过程相反，首先把键帽从上方滑到卡槽里，然后按压键帽，直到键帽完全卡入卡槽。

⚠️ 注意不要大力按压键帽，因为键帽的塑料件非常脆弱。

## 长键帽拆装：Shift、Caps Lock、ESC

这类键帽内部通常带有一到两个平衡杆，也就是铁丝，结构更复杂。

拆卸建议：

同样从右下角开始，再拆左下角；
拆下时注意不要用力过猛，避免下方金属卡槽变形。

左：拆下的 Caps Lock 键帽翻面放在键位旁。右：近景，键帽底部的金属平衡杆，以及露出的剪刀脚和卡槽

安装建议：

如果是 1 个平衡杆：
把铁丝先固定在键帽上，滑入键盘的缺口，再正常安装即可。
如果是 2 个平衡杆：
将上方平衡杆装在键帽上，下方平衡杆卡在键盘上。
安装时先对准上方卡槽，轻轻按入；再将下方卡扣压入孔位；

只有一个平衡杆的键帽，先把平衡杆卡住缺口，然后再正常装

## 长键帽拆装：Space

Space 是最长的键帽，底下的结构和其他长键不同：左右两端各有一组剪刀脚，中间只有一个硅胶碗，另外还有两根平衡杆。

拆卸建议：

和其他键一样，先从右下角撬起；
然后沿着靠近触控板的这一侧慢慢往左推进，直到整条前沿完全翘起；
前沿脱开后，键帽会连着平衡杆一起抬起，再从两端的剪刀脚上取下，注意收好两根平衡杆。

安装建议：

两根平衡杆分开装：一根装进键盘上剪刀脚的卡槽里，另一根挂在键帽上；
把键帽放上去，让键帽上的平衡杆勾住键盘的金属卡槽；
确认两根平衡杆都是平的，并且彼此拉开到最大距离；
先压 Space 的一侧，听到咔哒声，再压另一侧。

上排：从右下角开始，把 Space 靠触控板的一侧整条翘起，缝隙里能看到背光漏出来。下排：拆下后的键位，两端是剪刀脚，中间是硅胶碗；键帽背面挂着平衡杆

## 短键帽拆装：方向键

上方向键：先撬开左侧卡扣，然后从左向右滑出；
左/下/右方向键：先撬开右侧卡扣，然后从右向左滑出。

在拆之前，请参考方向键构造图。

方向键构造图

# 总结

记得最后检查一下所有拆下来的键，防止有一些铁丝忘记取下来，我在装的最后就发现有两个铁丝忘记取出来。

更换下来的旧键帽

## 常见问题解决

键帽装回去后按压感觉不对怎么办？

检查平衡杆是否正确卡入卡槽
确认剪刀脚支架没有变形或断裂
重新拆卸并按正确顺序安装

键帽容易脱落？

检查四个卡扣是否都正确扣入
平衡杆的安装方向是否正确

按键有卡顿现象？

检查是否有灰尘或异物卡在键帽下方
确认剪刀脚支架安装位置正确

## 专业建议

如果你对自己的动手能力不自信，或者已经有卡扣/剪刀脚损坏，建议：

联系 Apple 官方维修点；
找可信的第三方维修；
观看更多视频教程练练手再动工。

Junyi's Lab

deciax：用 JAX 和 Pallas 在 TPU 上运行 Decision Model

# 从一个例子开始

# 我们先用 JAX 实现 Laya

## JAX 实现的性能如何？

## 耗时分解

# 如果让它更快呢？

# 不同 batch size 下的性能

# 部署模型服务

## HTTP 服务

## Cost：Million model input tokens per US dollar

# 总结

# 致谢

HLO Visualizer：把 XLA HLO 变成看得懂的图

# 从「画出计算图」到「读懂这条指令」

# 把教程放到你正在读的指令旁边

# TPU 的 layout，直接画出来

# 用一个小程序开始

LLM Inference on TPU v6e-4: Small Dense, Large MoE, and Large Dense Models

# Abstract

# 1. Motivation

# 2. Experimental Setup

# 3. Results

## 3.1 Prefill

## 3.2 Decode

## 3.3 Online serving

# 4. Discussion

# 5. Conclusion

# Limitations

# Reproducibility

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

# 现象

## 环境变量？

## 配置文件？

## Keychain

# 为什么

# 修复

# 顺带一提

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

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

## Claude Code：规划与执行

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

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

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

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

# 社区里的类似探索

# 写在最后

用 nerdctl + Tailscale Sidecar 让容器流量走 Exit Node：踩坑全记录

# 最终目标

# 坑 1：nerdctl compose 不支持 network_mode: service:xxx

# 坑 2：Tailscale ACL 中未定义 tag

# 坑 3：缺少 SYS_MODULE capability

# 坑 4：Exit Node 模式下 DNS 失败

# 最终可用的 compose.yaml

# 验证方法

# 排查思路总结

# 写在最后

从像素到笔触：跨越十年的凝视

用 Dev Container 配置 VS Code + LaTeX 环境

# 安装编辑器扩展

# 三个步骤，从 0 到能写 LaTeX

## Step 1 引入 Dev Container 配置

## Step 2 重载编辑器窗口

## Step 3 启动容器并使用

# 进阶选择：不同的容器版本怎么挑？

# 常见问题 Q&A

从树莓派到 NUC：玩具的升级

# 树莓派的功与过

# 换成 NUC

MacBook Pro M1 键帽更换指南

# 拆掉旧键帽

## 普通按键拆装

## 长键帽拆装：Shift、Caps Lock、ESC

## 长键帽拆装：Space

## 短键帽拆装：方向键

# 总结

## 常见问题解决

## 专业建议

# 坑 1：nerdctl compose 不支持 `network_mode: service:xxx`

# 坑 3：缺少 `SYS_MODULE` capability