Junyi's Lab

HLO Visualizer: Learn XLA HLO by Exploring It

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

When working with JAX on TPU, you eventually need to read HLO. You want to know what a computation became after compilation, why extra copies appeared, or what is inside a fusion. The answers start with a compiler-generated text file.

Instructions pack together shapes, layouts, tiling, memory spaces, and references to other computations.

I built HLO Visualizer to make that easier. It turns HLO text into an explorable graph, with explanations of the instruction you select, piece by piece.

# From seeing the graph to understanding an instruction

There is already an official HLO visualization tool: XProf’s Graph Viewer. It lets you explore an operation’s neighborhood, expand or collapse fusions, and connect the graph to profiling data. That is useful when you have identified an expensive operation and want to understand its dependencies. The official documentation describes this workflow.

XProf Graph Viewer. Image from the OpenXLA documentation, used with attribution under CC BY 4.0.

HLO Visualizer puts the graph and the explanation in one interface. Nodes distinguish inputs, computation, transfers, and control flow. Select one to trace dependencies, inspect its original HLO, and navigate to the computations it references.

The attention example in HLO Visualizer. Follow inputs, transfers, and fusions, then click a node for details. This and the official screenshot use different programs; they illustrate the interfaces and reading workflows.

XProf connects HLO to measured performance. HLO Visualizer starts with a piece of HLO text you want to understand.

# Put the tutorial beside the instruction

Google DeepMind’s How to Scale Your Model has a useful introduction, How to read an XLA op. It explains names, types, layouts, memory locations, and operands through a fusion example. OpenXLA’s Operation semantics is the reference for precise operation behavior.

The next step is applying those rules to your own program.

Consider this simplified instruction:

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

It contains several layers of information:

%x names the instruction’s result.
bf16[128,128] gives the logical type and shape.
1,0 is the minor-to-major dimension order.
T(8,128)(2,1) describes two levels of physical tiling.
S(1) means VMEM in these TPU examples.
parameter(0) declares input 0 of the current computation.

The inspector breaks the original instruction into colored segments and explains its name, operation, operands, and attributes. Expand the type to inspect shape, dimension order, tiling, and memory space separately. Tuple elements can be explored individually too.

A while instruction, broken down into explanations of its state, condition, and body.

# Draw the TPU layout

Layout is an important part of HLO. Logical shape and physical storage layout describe different things. A 128 × 128 array can be split into tiles, with another level of tiling inside each tile. OpenXLA’s Shapes and layout and Tiled layout document the representation.

For the common TPU layout T(8,128)(2,1), HLO Visualizer draws a corner of a tile, labeling physical offsets and inner tile boundaries. The two sets of numbers become something you can see.

The top-left corner of an 8×128 outer tile. Red outlines mark 2×1 inner tiles; numbers are physical offsets within the tile.

The tool also explains TPU memory locations such as HBM, VMEM, and SMEM, helping you interpret transfer instructions. Memory-space numbers depend on the backend; the explanations here use the project’s TPU v6e examples as their context.

# Start with a small program

The bundled examples come from 21 small JAX programs compiled on TPU v6e, each with HLO before and after optimization. Try attention for inputs and fusions, fori_matmul for loops, or gather_scatter for indexing operations.

Open an example, enter its entry computation from the sidebar, and select a node. Inspect its inputs and result type, then explore a computation referenced by a fusion or while. Switch between Before and After in Examples to inspect how compilation changes the graph.

To explore your own code, export HLO through JAX’s lowering and compilation interfaces:

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 before optimization
print(lowered.as_text(dialect="hlo"))

# Compiled HLO; layouts and memory spaces depend on the backend
print(lowered.compile().as_text())

Copy either output and paste it through Open HLO. HLO text from XLA’s --xla_dump_to works too.

I want someone learning HLO for the first time to be able to connect the syntax to a small, real program. Open the graph, select an instruction, and follow the data.

Try HLO Visualizer. If it helps you understand your HLO, a star on GitHub is welcome. Please open an issue for instructions that are unclear or do not parse correctly.

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) 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.

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.

This is not a TPU-versus-GPU comparison. We did not run a GPU baseline. The goal is to report clear TPU v6e numbers 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 is 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.

All comparisons are between these three models on the same TPU host. We do not compare against GPUs, prices, or total cost.

# 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

Three points stand out.

First, active parameter count matters a lot for decode. The 30B-A3B MoE and the 32B dense model have similar total size, but very different active size. The MoE model uses 3B parameters per token. The dense model uses 32B. This explains the large decode gap: 7.0 ms versus 17.9 ms at batch size 1.

Second, the MoE model also wins in prefill. Its peak prefill throughput is 26,063 tok/s, or about 6.5k tok/s per chip. The dense 32B model reaches 19,714 tok/s, or about 4.9k tok/s per chip. On this host, the MoE model is faster in both prefill and decode.

Third, the small 4B model is limited by single-chip concurrency. It has good low-load latency, but one chip cannot absorb unlimited requests. Its practical serving capacity is about 0.45 req/s. To serve more traffic, the better path is to add chips or replicas, rather than pushing more concurrency onto one chip.

# 5. Conclusion

On one TPU v6e-4 host, using vLLM 0.20.0, tpu-inference, and an fp8_e5m2 KV cache, the large MoE model is the fastest of the three models we tested.

Compared with the dense 32B model, Qwen3-30B-A3B has:

higher prefill throughput: 26,063 vs 19,714 tok/s,
lower batch-size-1 decode latency: 7.0 vs 17.9 ms,
higher serving capacity: 1.27 vs 0.88 req/s,
higher output throughput at saturation: 1,303 vs 901 tok/s.

The 4B dense model has good latency at low load, but on one chip it is concurrency-limited. Its stable serving capacity is about 0.45 req/s.

# 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

Debunking introl and ainewshub: "TPU is 4x Cheaper than GPU" is an AI Hallucination

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

Disclaimer: this article is not arguing that TPU is worse than GPU. TPU and GPU each have their own fit, and which one wins depends on the specific workload. My point is that the batch of comparison data currently circulating online is itself inaccurate, much of it AI-fabricated and impossible to trace. What I’m taking apart below is exactly that fake data.

Artificial Analysis recently released a set of hardware benchmarks¹. Using Llama 3.3 70B, vLLM, and a reference speed of 30 output tokens/s per query to compute the cost per million input/output tokens, NVIDIA has roughly a 5x per-dollar token advantage over TPU v6e (Trillium), and roughly a 2x advantage over AMD MI300X².

The hardware benchmark conclusion Artificial Analysis posted on X. NVIDIA has about a 5x per-dollar token advantage over TPU v6e and about 2x over MI300X. H100 is $1.06, MI300X is $2.24, TPU v6e is $5.13.

Alongside this reproducible data, another kind of thing is also circulating online.

# A High-Profile Comparison Article

introl has an article titled Google TPU v6e vs GPU: 4x Better AI Performance Per Dollar³. Its core argument is that TPU has 4x better performance per dollar than H100, and that TPU completely beats NVIDIA on inference economics. Its key data comes from another article, ainewshub.org’s Nvidia vs Google TPU 2025 Cost Comparison⁴. Follow this citation chain down and you find that both are AI-generated, and the data is made up.

# The First Problem: The Core Citation Points to Data That Doesn’t Exist

The most central sentence in the ainewshub article reads like this.

The core claim in the ainewshub article, 4.7x better performance per dollar, but the source it cites is a non-existent MLPerf v4.1 LLM inference result.

“4.7× better performance-per-dollar on LLM inference than Nvidia H100/H200”, with the source listed as Google Cloud MLPerf Inference v4.1 results + customer case studies, October 2025.

But in fact, in MLPerf Inference v4.1, Google’s TPU submissions include only one model, stable-diffusion-xl. I went to MLCommons’ official results⁵ and filtered by Google plus TPU. Under v4.1 Closed Datacenter there are only two records, tpu-v5e-4 and tpu-v6-4, and both ran stable-diffusion-xl.

Filtering MLPerf v4.1 Closed Datacenter for Google TPU shows only two entries, tpu-v5e-4 and tpu-v6-4, both running stable-diffusion-xl. There is no LLM inference entry at all.

No LLM inference entry at all! The so-called MLPerf v4.1 LLM inference 4.7x performance per dollar cited by this article simply does not exist in the source it claims. The number was generated out of thin air and then attached to an authoritative-looking source.

Second, MLPerf does not report performance per dollar at all. It reports throughput, samples/s and queries/s, with no pricing in it. So that 4.7x could not possibly have been computed from MLPerf.

# The Second Problem: The Numbers Drift Between Reposts

Put introl³ and ainewshub⁴ side by side and the numbers don’t match (and there are false statements).

Performance per dollar multiple: introl writes 4x, ainewshub writes 4.7x. (This one is pure deception, see above.)
MLPerf version: introl cites v3.1, ainewshub cites v4.1. (No idea where introl got its data.)
Midjourney case: introl writes monthly spend dropped from $2 million to $700k, ainewshub writes from $2.1 million to $700k. (I didn’t carefully verify this one, but it’s most likely hallucinated too.)

Reposted again and again, it changes a little each time it’s retold. Damn it, every time the model generates it, it makes up a slightly different number.

# The Third Problem: A Frighteningly Precise TCO Table, With No Source

ainewshub⁴ gives a three-year total cost of ownership table, for a 1000-chip cluster, with NVIDIA H100 total cost $177 million, Google TPU v6 total cost $78.5 million, saving $98.5 million. It even breaks it down to hardware down 48%, power down 66%, cooling down 67%, support down 63%, networking down 67%, real estate down 63%. (All made up.)

This kind of breakdown precise to the single percentage point looks very professional. The problem is that not one item can be traced to a source. The accompanying customer cases are the same. Midjourney, and a so-called Series C computer vision startup whose monthly spend dropped from $340k to $89k, are all unverifiable specific numbers.

# The Most Infuriating Part is “data verified”

Following the ainewshub cost comparison article further upstream, its source points to another article on the same site, AI Inference Costs: TPU vs GPU 2025⁶. The same numbers are repeated here again, 4x value for money, Midjourney saving 65%, TPU v5e winning 8 out of 9 items. I have to stress again, this data is fake, it does not exist.

The statement at the end reads like this.

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

Verified? Nothing here was verified.

It says it verified, yet it can’t provide a single clickable link, no specific report, no methodology. As checked above, the MLPerf TPU LLM inference results it relies on simply do not exist. The so-called verified is all completely fake.

Different articles on the same site can’t even keep these fake numbers consistent. The person who wrote them doesn’t know where the numbers came from either, because they never existed in the first place.

A site that mass-produces hallucinated numbers and then stamps them all with data verified … this garbage site does real damage.

# The Data I’ve Found So Far (At Least a Bit More Credible Than Their Site)

Artificial Analysis’ System Load Test¹, running Llama 3.3 70B.

Artificial Analysis System Load Test, peak system throughput, per-query output speed, and on-demand rental price for Llama 3.3 70B.

Peak system throughput: B200 is 15.4k tokens/s, H200 is 8.47k, H100 is 7.28k, TPU v6e is 6.73k, MI300X is 3.67k. TPU v6e falls behind NVIDIA’s same generation. Per-query output speed, TPU v6e is 61.3 tokens/s, the slowest in this group.

Cost has to be discussed in two cases, and here TPU does have a favorable scenario too.

Cost per million tokens for Llama 3.3 70B at peak throughput. TPU v6e is $0.62, close to H100’s $0.67 to $0.69.

Computing cost per million tokens at peak throughput, TPU v6e is $0.62, close to H100’s $0.67 to $0.69, and cheaper than MI300X’s $0.90 and B200 running vLLM at $1.63. If the workload is offline large-batch and can keep the chips fed, TPU’s economics work out.

But online serving rarely runs at peak throughput. Once you require a usable interactive speed, for example the reference speed of 30 tokens/s per query, TPU v6e’s unit cost jumps to $5.13, while H100 is $1.06. This is where the roughly 5x gap Artificial Analysis mentions comes from.

Later we’ll run the benchmark ourselves to get first-hand data, and compare then.

# How to Spot AI-Generated Junk Articles

Just follow one principle: any data, any number, must have a clickable source and a reproducible method.

Claude Code Asks to Re-login in tmux? It's Probably macOS Keychain

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

claude works fine in my terminal — Team Account, auth, everything. Open tmux, run claude, and it wants me to log in again. Took a bit of digging to figure out it’s a macOS Security Session thing.

# What happens

claude in Ghostty: works. claude in tmux: asks to re-login.

How I tracked it down (click to expand)

## Environment variables?

First thought: tmux has different env vars.

env | grep -iE 'claude|anthropic'

Nothing on either side. Claude Code doesn’t store auth in env vars.

## Config files?

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

Nope. Not on disk either.

## Keychain

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

Found it — stored in macOS Keychain as Claude Code-credentials:

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

Then:

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

Works in the terminal, errors in tmux. There it is.

# Why this happens

macOS Keychain access is tied to a Security Session (Bootstrap Namespace). When you open a terminal window, the process gets attached to your Aqua session, which holds the Keychain unlock state.

tmux server is a long-running daemon — it starts on your first tmux new and stays alive. When you tmux attach later, shells forked inside tmux server inherit the server’s original session, not your current Aqua session.

Normal terminal:
Ghostty → fork shell → inherits Aqua session → ✅ Keychain works
tmux:
Ghostty → attach → tmux server (old process)
→ fork shell → inherits old session
→ ❌ Keychain blocked

Same reason pbcopy/pbpaste break inside tmux.

# Fix

Install reattach-to-user-namespace to reconnect tmux processes to your Aqua session:

brew install reattach-to-user-namespace

Add to ~/.tmux.conf:

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

Then kill the entire tmux server (kill-session won’t help — new windows still fork from the old server):

tmux kill-server
tmux new -s main

Verify:

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

If it prints the token, you’re good.

# While you’re at it

These tmux issues are probably the same root cause:

pbcopy/pbpaste broken
ssh-agent inaccessible
osascript failing
gh auth, op, and other Keychain-dependent CLI tools not working

reattach-to-user-namespace fixes all of them.

Agent Mesh: My Thoughts on Multi-AI Collaborative Workflows

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

AI coding assistants are everywhere now, from chat windows to CLI Agents. After using a bunch of them, my biggest takeaway is: no single Agent is the best at everything.

I mainly use Claude Code, Google Gemini CLI, and Moonshot Kimi Code day-to-day. At first I treated them as standalone tools, but soon realized that was a waste — each has distinct strengths, and if you let them collaborate and delegate tasks based on those strengths, the results are much better. I call this approach Agent Mesh.

Here are my observations and thoughts.

# Core Roles: My Observations and Real Experience

## Claude Code: Top-Tier Architect and Execution Engine

In daily use, Claude Code feels like a “senior engineer.” Whether spinning up a new project from scratch or tackling a complex refactor, its architectural vision is the best of the bunch. And it doesn’t just plan — it executes: traversing files, running bash, fixing its own compile errors, driving the whole loop autonomously. I’ve installed Claude Code on all my servers. It has massively boosted my productivity and freed up a lot of my energy. The weakness is hallucinations — especially when generating large blocks of documentation or referencing large systems it hasn’t fully digested, it will make things up.

## Gemini CLI: Large-Context Consumer and “Hallucination Checker”

Gemini’s biggest advantage is that 2-million-token context window. In practice, it really can swallow an entire repository or very long error logs (I’ve tested with logs of several hundred KB). Because it can hold the entire macro context in its head, it’s a natural auditor. When Claude Code produces a brilliant but potentially hallucinated code plan, you can call on Gemini for large-scale cross-file verification.

## Kimi Code: Deep Reasoner and Data Miner (❓ Pending Evaluation)

Kimi Code takes a completely different path. Under the hood it runs K2.5’s “long thinking” model (k0), using explicit chain-of-thought (similar to OpenAI o1’s approach), plus an “Agentic Swarm” pattern that can theoretically spin up a swarm of sub-Agents for multi-hop document retrieval or grinding through deeply nested algorithmic problems. I do have a question mark here though: I use Claude and Gemini every day, so I have a solid feel for their capability boundaries, but how much better Kimi actually is at “data mining” and “deep reasoning” compared to the other two — honestly, I’m mostly going by its architectural claims and haven’t done rigorous head-to-head evaluations yet. So for now, its niche here is only a theoretical one.

# What My Ideal Agent Mesh Looks Like

Once you understand each Agent’s strengths and weaknesses, the natural next question is: can you have them collaborate, chaining tasks via prompts? That’s what I mean by Agent Mesh.

Most of the time, Claude Code is the workhorse — it writes the vast majority of the code. But when it hits a context ceiling, say I need to refactor a module but don’t know which parts of a 500K-line legacy codebase will be affected, I hand it off to Gemini — let it read the entire repo and report back the blast radius.

Conversely, after Claude executes a refactoring plan, I’ll have Gemini cross-reference it against the actual project files to catch hallucinations or broken dependencies. If Gemini encounters a particularly tough algorithmic problem during auditing, it can pass it to Kimi Code for extended reasoning.

After Kimi finishes thinking, it doesn’t touch files directly — it passes conclusions back to Claude Code for implementation. The whole flow is a loop: each does what it’s best at, and results flow between them.

# The Hidden Factor: Agent Architecture vs. Base Model

When trying to combine these Agents, I discovered a point that’s easy to overlook: the underlying base model is only half the equation — the “Agent architecture built around it” determines its actual capabilities.

The best example is Anthropic’s Claude 3.5 Sonnet. You can use this same base model in multiple environments:

As a standard chat assistant in VS Code.
As the driving engine inside Cursor IDE.
Through open-source Agent frameworks like OpenHands / Open Code.
Natively via the Claude Code CLI.

Despite sharing the exact same LLM DNA (Claude 3.5 Sonnet), their real-world capabilities differ dramatically. In demanding engineering workflows, native Claude Code consistently outperforms the others in Agent execution. Why? Because the Agent architecture has been uniquely optimized by the model’s creators (including but not limited to: hidden loop mechanisms, error recovery strategies, and specific context engineering).

Even using excellent open-source alternatives like Open Code with the Claude model, the execution fluidity and architectural vision often falls short of Claude Code. This tells us that when choosing Agents for a Mesh, we’re not just picking a base model (like Sonnet or GPT-4o) — we’re picking the engineering scaffolding built around it.

# Similar Explorations in the Community

After writing this up, I found that others in the community are working on similar ideas. Humanize is a Claude Code plugin that implements a workflow called RLCR (Ralph-Loop with Codex Review): Claude writes the code, Codex independently reviews it, and if issues are found, it gets kicked back for rework, looping until everything passes. The core idea is the same as Agent Mesh: let architecturally different AIs each do what they’re best at, iterating through a work-feedback loop instead of expecting one model to nail everything in a single shot.

# Final Thoughts

I don’t think a single “do-it-all” model will emerge to handle everything. What’s truly interesting is orchestration — having Agents with fundamentally different underlying architectures each play to their strengths.

One view I’ve consistently held: when we say “different” agents, we do not mean taking the same underlying model and wrapping it with different system prompts (e.g., role-playing “you are an architect” vs. “you are a tester”). True collaborative sparks only happen when agents have fundamental differences in how they process information at the architectural level.

But how do you know whether two models are truly different, or just fine-tuned versions of the same base? This is where tools like LLM-DNA (a research framework for analyzing evolutionary relationships and functional differences between language models, published in ICLR'26) become invaluable. By analyzing the “genetic” lineage and functional distance between models, we can deliberately select Agents from entirely different evolutionary branches, ensuring they don’t share the same blind spots.

My hands-on engineering experience tells me: the Claude Code + Gemini CLI synergy is currently the most powerful and intuitive combination. Gemini CLI leverages its long context to swallow entire repos and stacks of logs, specializing in catching hallucinations and macro-level auditing. Claude Code focuses on what it does best — understanding code architecture and executing precisely in the local environment.

When you deliberately combine Agents with fundamentally different architectures, they stop overlapping and start complementing each other. That’s the Agent Mesh idea I wanted to share — hope it inspires some of you.

nerdctl + Tailscale Sidecar Exit Node: A Complete Pitfall Guide

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

In containerized deployments, sometimes you need all outbound traffic from a container to go through a specific network exit. Tailscale’s sidecar pattern makes this possible: a Tailscale container acts as a sidecar, other containers share its network namespace, and traffic flows through a WireGuard tunnel via a remote exit node.

This setup is well-documented for Docker Compose, but migrating to nerdctl (containerd) introduced a series of pitfalls. Here’s what I ran into so others can avoid the same traps.

# The Goal

Route all outbound traffic from any container through a Tailscale sidecar, forwarding via a remote exit node:

For verification, I used nicolaka/netshoot as a test container — it comes with curl, dig, tcpdump, iperf, and a full suite of networking tools out of the box.

# Pitfall 1: nerdctl compose doesn’t support `network_mode: service:xxx`

Docker Compose supports network_mode: service:<service_name>, which automatically resolves the service name to the corresponding container’s network namespace. nerdctl compose hasn’t implemented this translation layer and throws an error:

unsupported network_mode: service:tailscale-sidecar

Fix: Use network_mode: container:<container_name> instead, and pin the sidecar container’s name with container_name.

services:
 tailscale-sidecar:
 container_name: tailscale-sidecar # Pin the name
 # ...
 netshoot:
 network_mode: container:tailscale-sidecar # Use container name, not service name

Without a fixed container_name, nerdctl compose auto-generates names like blockchain-tailscale-sidecar-1, causing reference mismatches.

# Pitfall 2: Undefined tag in Tailscale ACL

After starting, the Tailscale container immediately exits with:

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

Fix: Define the tag in your Tailscale admin console’s ACL policy and select it when generating the auth key:

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

# Pitfall 3: Missing `SYS_MODULE` capability

This one is the sneakiest. The container joins the tailnet fine, tailscale ping works, but after enabling the exit node, TCP traffic is completely broken — only ICMP gets through.

The root cause: kernel mode (TS_USERSPACE=false) needs to load kernel modules like xt_mark and nf_nat to set up iptables forwarding rules. Without SYS_MODULE capability, these modules can’t load. The iptables rules are written but don’t take effect, resulting in working ICMP but broken TCP.

Fix:

cap_add:
 - net_admin
 - SYS_MODULE # Essential

# Pitfall 4: DNS failure in exit node mode

With the exit node enabled, all outbound traffic goes through the WireGuard tunnel to the remote exit node. But /etc/resolv.conf still points to local DNS servers (e.g., 10.0.2.3), which are unreachable from the exit node’s perspective. DNS queries naturally fail.

The symptom: curl ifconfig.me reports Could not resolve host, while direct IP access hangs or returns errors.

Fix: Let Tailscale take over DNS so queries also go through the tunnel:

environment:
 - TS_ACCEPT_DNS=true

# Final Working 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

Prepare a .env file in the same directory:

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

# Verification

nicolaka/netshoot comes with plenty of network tools, perfect for validation:

# Check exit IP to confirm traffic goes through the exit node
nerdctl exec -it netshoot curl ifconfig.me

# DNS resolution test
nerdctl exec -it netshoot dig google.com

# View routing table
nerdctl exec -it netshoot ip route show table all

# Packet capture for debugging
nerdctl exec -it netshoot tcpdump -i any -n

# Tailscale status checks
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>

# Debugging Methodology

The debugging process itself is worth reviewing. When facing a compound problem like “exit node doesn’t work”, the effective approach is to isolate layer by layer:

Verify tunnel connectivity first: tailscale ping confirms whether the WireGuard tunnel itself works.
Comparative testing: Disable the exit node to determine if the issue is with the exit node or the underlying network.
Differentiate protocols: ICMP works but TCP doesn’t — points to iptables/kernel module issues.
Separate DNS from connectivity: Use direct IP access to bypass DNS and isolate each issue.
Compare against known-working configs: Spotting that a previously working setup had SYS_MODULE immediately pinpointed the problem.

Each step narrows the scope, avoiding wasted time in the wrong direction.

# Final Thoughts

nerdctl compose has matured as a Docker Compose alternative, but gaps remain in edge-case compatibility. The missing network_mode: service: support and different container naming conventions are easy migration traps. For Tailscale in containers with exit node routing, SYS_MODULE and TS_ACCEPT_DNS are two easily overlooked but essential configurations. Hope this write-up helps anyone hitting the same issues.

From Pixel to Pigment: A Decade with Impressionism

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

INTO THE MODERN

In early 2026, at the “INTO THE MODERN” Impressionist exhibition in Singapore, I stood before an original Monet for the first time.

Layers of pigment were stacked high, brushstrokes clearly visible, as if freezing a moment of shimmering dawn or fading dusk from a century ago. At that moment, my mind drifted back to a quiet Sunday exactly ten years prior (2016). I was sitting in front of a computer, flipping through images on the screen one by one, selecting paintings to present for my art class. The theme was “From Tradition to Modernity.” At that time, the word “Impressionism” was still foreign to me, and I could never have imagined that one day I would come face to face with these masterpieces that had once only existed for me as pixels.

Although the exhibition did not feature Monet’s most famous works, it was unexpectedly comprehensive: Monet, Renoir, Sisley, and Cézanne. These four young men, who once studied together at Gleyre’s Studio, were now reunited through their paintings. Monet’s work featured paint as thick as relief sculpture; you could clearly see the brushstrokes piled into heavy clumps. Renoir bathed faces in soft light, luminous yet hazy. Sisley’s landscapes were tranquil and restrained. As for Cézanne, I didn’t have much of an impression of him…

Haystacks, 1890 - Claude Monet
(Paint as thick as relief sculpture; brushstrokes clearly visible in heavy clumps)

The biggest surprise of the exhibition for me was Paul Signac. While his colors retained the flavor of Impressionism, his technique was entirely different. There were no sweeping brushstrokes on the canvas, replaced instead by countless, meticulous tiny dots of color. Later, I learned that Paul Signac was a representative painter of “Pointillism.”

View of the Seine at Herblay, 1889 - Paul Signac

Port of Saint-Cast, 1889 - Paul Signac

Standing in the gallery, my memory flowed back to that high school student trying to explain “From Tradition to Modernity” in a PowerPoint presentation. Back then, I understood these works solely through Wikipedia and a few images, easily applying a label to each movement:

Neoclassicism pursued rigorous composition and scientific perspective, but later fell into empty, dogmatic forms;
Romanticism sought the sublime in mythology and passion, eventually sliding into emotional exaggeration;
Realism turned its gaze to the common people and daily life, yet failed to break through the framework of traditional narrative;
Impressionism broke free from the studio to capture fleeting light and color, yet in its obsession with visual impressions, almost forgot the structure of form;
Post-Impressionism turned completely inward: Van Gogh burned with inner fire, Gauguin fled to symbolic shores. They no longer sought “how the world looks,” but turned to “how I feel the world.”
……

The exploration of beauty never ceases. Ten years have passed, and I am no longer just reading a smoothed-over version of history across a screen. Now, standing before the originals, I truly felt that chaotic, intense, and uncertain process of creation. Beyond the shock of the color and brushwork, there was a deep historical resonance. I was not only conversing with the artists, but I was also conversing with myself.

The modern path of art is inherently a constant fission and recombination between reason and sensibility, order and freedom.

Behind the canvases are living, breathing people. Amidst doubt and loneliness, they still chose to believe their own eyes.

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

From Raspberry Pi to NUC: An Upgrade of My Toy

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

My long‑serving Raspberry Pi 4B has finally met its “successor” — the compact Intel NUC. From ARM to x86, from a TF card to an SSD, this seemingly simple hardware upgrade has brought a qualitative leap to my tinkering experience.

# Raspberry Pi: Pros and Cons

The Raspberry Pi 4B used to be a key pillar of my digital life. It quietly ran various lightweight services: monitoring my home network traffic, running automation scripts, and even serving as a temporary dev/test environment. To keep it stable, I set up a cron job to automatically reboot every Sunday, which kept it fairly reliable most of the time.

But its shortcomings surfaced as I pushed it further. What worried me most was the reliability of TF‑card storage — even with so‑called “endurance” cards, you can’t fully avoid I/O risks. After I published the article on setting up k3s on a Raspberry Pi 5 cluster, my four‑node cluster ran stably for only a week before one node died due to a sudden flood of I/O errors. Ironically, that node was using a carefully chosen high‑endurance card, which ended up lasting even shorter than the ordinary card in the 4B.

Performance bottlenecks also became more evident under heavier workloads: compiling a slightly larger project meant a long progress‑bar crawl, and occasional stutters with multiple services running in parallel reminded me of the hardware’s limits. While attaching an external SSD can ease the storage issue, it undoubtedly increases complexity; at that point, it made more sense to upgrade to a more reliable platform.

# Unboxing the NUC and the Performance Leap

Unboxing the NUC, my first impression was: “too refined to be a mini PC.” The palm‑sized body isn’t much bigger than a Pi, but the hefty metal shell feels solid. I installed Ubuntu Desktop 24.04. The performance gap is downright comforting: a Go project that took 3 minutes to compile on the Pi finishes in just 1 minute on the NUC.

Fig.1 - Compact yet powerful Intel NUC

The NUC brings not just performance but peace of mind: the built‑in SSD eliminates the TF‑card read/write anxiety, and the extra memory plus x86 architecture make heavier tasks easy. I finally feel comfortable running a small database locally — I used to worry frequent writes would burn out the card.

As for the retired Raspberry Pis, they’ll pivot to edge‑computing nodes and keep contributing.

# Closing Thoughts

Whenever I see the Pi’s LEDs blinking in rhythm, I remember the excitement of first unboxing it. The joy of tinkering was never about chasing the newest and the fastest, but about watching these devices find the right place at each stage — like tools slowly collecting stories of their own.

MacBook Pro M1 Keycap Replacement Guide

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

As we all know, once keycaps get greasy and shiny (“oiled”), it’s almost impossible to restore them by simply wiping. I once tried sanding the keycaps, but not only did it make things worse, the plastic debris also fell into the gaps between the keys. (You can see my sanded Shift and Space keys in the photo — they look terrible.)

While some say you can go to an Apple Store to get them replaced¹, it’s said they only allow a few keycaps to be replaced each time. For someone like me whose entire keyboard is shiny, DIY replacement is clearly the more practical option.

I’m writing this blog post because I found it incredibly difficult to locate a complete guide on how to replace MacBook Pro M1 keycaps. Most of the videos online² only show how to remove regular letter and number keys — they deliberately skip over the longer keys like Space, Caps Lock, ESC, and the arrow keys. These keys have different internal structures and require a different disassembly approach.

Keyboard before (top) and after (bottom) the keycap replacement

I bought a full set of replacement keycaps from Taobao for 85 RMB ($11.81 USD) and decided to do it myself:

The full set of keycaps purchased from Taobao

# Removing the Old Keycaps

The MacBook Pro uses a scissor-switch keyboard mechanism, so we need to follow the correct disassembly procedure for scissor-switch keys.

## Regular Key Disassembly

Steps:

Locate the latches: Each regular keycap has four clips, one at each corner.
Start at the bottom right: Gently lift the bottom-right corner with a spudger. A soft “pop” sound means the latch has been released.
Then the bottom left: Do the same for the bottom-left corner.
Lift the keycap: Once the bottom two clips are released, gently lift the entire keycap upward.
Fully remove: The top clips will naturally detach.

Tips:

⚠️ Avoid applying excessive force — the scissor-switch mechanism is fragile.
⚠️ Never pull straight up — it may break the clips.
💡 Use a plastic spudger instead of metal tools to prevent scratches.

You can refer to this video² — it clearly demonstrates how to remove regular keys.

To reinstall the keycap, reverse the removal steps: slide the keycap into the top clips first, then press down until it snaps into place.

⚠️ Be careful not to press too hard — the plastic components are delicate.

## Long Key Disassembly (e.g. Shift, Caps Lock, ESC)

These larger keys usually contain one or two stabilizer wires (metal bars), making the structure more complex.

Removal Tips:

Start from the bottom-right corner, then move to the bottom-left.
Do not use excessive force — avoid bending the metal stabilizer sockets.

Removed Caps Lock key (pointed to by tweezers) and the longer Shift key

Installation Tips:

For a single stabilizer wire:
Attach the metal bar to the keycap first, slide it into the slot on the keyboard, then press down to install as usual.
For two stabilizer wires:
Mount the top stabilizer wire to the keycap, and clip the bottom stabilizer wire into the keyboard.
First align the keycap with the top clips and press gently, then push the bottom part into place.

Keycap with a single stabilizer wire: first secure the wire, then press the keycap into place

## Short Key Disassembly (Arrow Keys)

Up Arrow: First release the left-side clip, then slide the key to the right.
Left/Down/Right Arrows: First release the right-side clip, then slide the key to the left.

(Before attempting this, refer to the structural images below.)

Arrow key structure diagram

# Summary

Be sure to check all removed keycaps before finishing — I realized I had left two stabilizer wires behind only when I was nearly done.

All the old keycaps after removal

## Troubleshooting

Key doesn’t feel right after reinstallation?

Check if the stabilizer wire is properly clipped in.
Ensure the scissor switch isn’t bent or broken.
Remove the keycap and reinstall in the correct order.

Keycap easily falls off?

Make sure all four clips are secured.
Verify the stabilizer is installed in the correct direction.

Key feels stuck or unresponsive?

Check for dust or debris underneath the cap.
Ensure the scissor switch is properly aligned.

## Pro Tips

If you’re unsure about your dexterity or notice any broken clips or switch parts, it’s best to:

Contact Apple’s official repair service;
Find a trustworthy third-party repair shop;
Watch more tutorial videos and practice before diving in.

Ultra-Low-Voltage Buck–Boost Converter (0.3 V to 5 V)

junyi.h@comp.nus.edu.sg (Junyi Hou) — Fri, 29 Mar 2024 16:42:00 +0800

Figure 1 – Ultra Boost Converter

# Chip Selection

I took on a challenging requirement: convert 0.5 V to 2.0 V.

A conventional boost–buck approach couldn’t meet this because a typical diode drop is about 0.7V while the source only provides 0.5V.

Most converter ICs on the market need around 0.9V to start up, which this source doesn’t meet.

After quite a bit of searching, I found the TPS61200, which supports 0.3–5.5V input and can output 1.8–5.5V (adjustable or fixed).

# PCB Design

Big thanks to my mentor JYF, who gave me lots of guidance and turned my PCB around.

For the first revision, I followed these app notes: Supplying TPS61200 With a Single Solar Cell and Using TPS61200 as WLED Driver. JYF taught me many power-supply layout tips, such as:

Use keep-out regions when copper-pouring to avoid creating “antennas”.
Near any “antenna,” add vias so interference returns cleanly to ground.
Size the PCB in 5 mm increments to make enclosures easier.
Stencils are cheaper to order on Taobao.
~~Horizontal sockets are awkward; vertical ones work better.~~
…

His help was key to making this project succeed on the first try.

(By the way, I skipped the MPP circuit. That can demand about 1A from the source for up to 20ms, which is effectively a short for some fuel cells and can shorten their lifespan.)

# Soldering

This was my first time hand-soldering a QFN. I ruined one PCB before getting it right, but the final result came out great.

My 0805 soldering used to look ugly; now 0603 is no problem either. ~~If I ever get laid off, I can go tighten screws in a factory.~~

Compared with before, I made a lot of progress this round (see my earlier board here: Ultra‑mini ESP8266 dev board).

# Photos

Figure 2 – Ultra Boost Converter

(a) Using a 3.0V coin cell to light the 2.0V LED

(b) Using a 1.5V battery to light the 2.0V LED

Figure 3 – 2.0V regulated output lighting the LED from different inputs

Update on 2024‑06‑15:

Removed the pin header
Removed the coin‑cell holder
Removed the POWERSAVE option (enabled by default)
Improved adjustable output range from 0.5–3.3V to 0.5–5.5V
Switched to a 3mm potentiometer; shorter feedback path

Figure 4 – Updated Ultra Boost Converter (Top), Original (Bottom)

Junyi's Lab

HLO Visualizer: Learn XLA HLO by Exploring It

# From seeing the graph to understanding an instruction

# Put the tutorial beside the instruction

# Draw the TPU layout

# Start with a small program

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

Debunking introl and ainewshub: "TPU is 4x Cheaper than GPU" is an AI Hallucination

# A High-Profile Comparison Article

# The First Problem: The Core Citation Points to Data That Doesn’t Exist

# The Second Problem: The Numbers Drift Between Reposts

# The Third Problem: A Frighteningly Precise TCO Table, With No Source

# The Most Infuriating Part is “data verified”

# The Data I’ve Found So Far (At Least a Bit More Credible Than Their Site)

# How to Spot AI-Generated Junk Articles

Claude Code Asks to Re-login in tmux? It's Probably macOS Keychain

# What happens

## Environment variables?

## Config files?

## Keychain

# Why this happens

# Fix

# While you’re at it

Agent Mesh: My Thoughts on Multi-AI Collaborative Workflows

# Core Roles: My Observations and Real Experience

## Claude Code: Top-Tier Architect and Execution Engine

## Gemini CLI: Large-Context Consumer and “Hallucination Checker”

## Kimi Code: Deep Reasoner and Data Miner (❓ Pending Evaluation)

# What My Ideal Agent Mesh Looks Like

# The Hidden Factor: Agent Architecture vs. Base Model

# Similar Explorations in the Community

# Final Thoughts

nerdctl + Tailscale Sidecar Exit Node: A Complete Pitfall Guide

# The Goal

# Pitfall 1: nerdctl compose doesn’t support network_mode: service:xxx

# Pitfall 2: Undefined tag in Tailscale ACL

# Pitfall 3: Missing SYS_MODULE capability

# Pitfall 4: DNS failure in exit node mode

# Final Working compose.yaml

# Verification

# Debugging Methodology

# Final Thoughts

From Pixel to Pigment: A Decade with Impressionism

From Raspberry Pi to NUC: An Upgrade of My Toy

# Raspberry Pi: Pros and Cons

# Unboxing the NUC and the Performance Leap

# Closing Thoughts

MacBook Pro M1 Keycap Replacement Guide

# Removing the Old Keycaps

## Regular Key Disassembly

## Long Key Disassembly (e.g. Shift, Caps Lock, ESC)

## Short Key Disassembly (Arrow Keys)

# Summary

## Troubleshooting

## Pro Tips

Ultra-Low-Voltage Buck–Boost Converter (0.3 V to 5 V)

# Chip Selection

# PCB Design

# Soldering

# Photos

# Pitfall 1: nerdctl compose doesn’t support `network_mode: service:xxx`

# Pitfall 3: Missing `SYS_MODULE` capability