lizhaoliu

Oh nice, hadn't seen it. It looks good, and they've clearly got some decent stuff I don't (chrome extension, embedding in model cards, family pages).

The main difference appears to be how the graph gets made. From what I can tell they analyze the config on the server (their page says the first request can take a few minutes). I actually build the model on PyTorch's meta device and run a fake forward pass through it, so I get the real execution order and the tensor shapes at every module. That's what the animated replay and the compute/KV cache numbers are based on.

Hi! Not from the config alone, the config just tells transformers which classes to build. I let it actually build the model, but on PyTorch's meta device, so every module and parameter exists with its real shape and dtype but no memory behind it. That gives me the true nn.Module tree (the same one print(model) would show), and I hash repeated subtrees so 36 identical layers show as one stack with a ×36 badge.

Then I run a fake forward pass (dummy inputs, also on the meta device) with a forward hook on every module. Most ops do shape inference fine without real data, so that records the execution order and every module's input/output shapes. Both things you're asking about are already in the UI:

- Tensor shapes: click any module and the inspector shows its traced input/output (e.g. [1 batch × 7 seq × 4096 hidden], the labels come from matching dim values against config) plus its weight shapes ([151936 vocab × 4096 hidden]). The flow-replay HUD shows the shape transformation at each step. - Per-layer parameter counts: every node shows its param count and share of the model, there's a treemap of children by params, and a "cost" lens that switches the whole map to compute (MACs), activation memory, or KV cache — with sequence length as a slider.

Params/dtypes are cross-checked against the safetensors headers (fetched via HTTP range requests, no weight download).