The Jetson Orin Nano Super

# labs/board_specs.py
BOARDS: dict[str, dict[str, str]] = {
    "Raspberry Pi 4B": {
        "CPU": "4x Cortex-A72 @ 1.8 GHz",
        "GPU": "VideoCore VI, no CUDA",
        "Memory": "4 GB LPDDR4, one pool",
        "Bandwidth": "12.8 GB/s peak",
        "Storage": "microSD or USB",
        "Power": "5 V over USB-C",
        "Wi-Fi": "on the board",
        "GPIO": "40-pin header",
    },
    "Jetson Orin Nano Super": {
        "CPU": "6x Cortex-A78AE @ 1.7 GHz",
        "GPU": "Ampere, 1024 CUDA cores",
        "Memory": "8 GB LPDDR5, one pool",
        "Bandwidth": "102 GB/s peak",
        "Storage": "M.2 NVMe, none included",
        "Power": "9-19 V barrel jack",
        "Wi-Fi": "not on the board",
        "GPIO": "40-pin header",
    },
}


def missing_keys(boards: dict[str, dict[str, str]]) -> dict[str, list[str]]:
    """For each board, the rows some other board declares and this one does not."""
    every: set[str] = set()
    for spec in boards.values():
        every |= set(spec)
    return {name: sorted(every - set(spec)) for name, spec in boards.items()}


def shared_keys(boards: dict[str, dict[str, str]]) -> list[str]:
    """The comparable rows, in the first board's order. Raises if any board is short one."""
    gaps = {name: gap for name, gap in missing_keys(boards).items() if gap}
    if gaps:
        raise KeyError(f"boards do not declare the same rows: {gaps}")
    return list(next(iter(boards.values())))


if __name__ == "__main__":
    print(f"boards: {len(BOARDS)}")
    print(f"rows:   {len(shared_keys(BOARDS))}")
    print(f"gaps:   {missing_keys(BOARDS)}")

$ uv run python -m labs.board_specs
boards: 2
rows:   8
gaps:   {'Raspberry Pi 4B': [], 'Jetson Orin Nano Super': []}

Two dictionaries side by side are only a comparison while both declare the same rows. Drop one and the reader of the table sees a board with no entry where the other has a number, and reads that absence as a fact about the hardware instead of a fact about your typing. So the check happens once, at the top, and it is loud: shared_keys either returns the row list or refuses to return anything. Notice that missing_keys hands back data, not a yes or no. A boolean can only tell you something is wrong; a dictionary of gaps tells you which board is short which row, and that difference is what makes the failure at the end of this chapter solvable in one line.

# labs/board_compare.py
from labs.board_specs import BOARDS, shared_keys


def column_widths(boards: dict[str, dict[str, str]],
                  keys: list[str]) -> tuple[int, dict[str, int]]:
    """Widths taken from the data, so no cell can outgrow the column it sits in."""
    label = max(len(k) for k in keys)
    cells = {n: max([len(n)] + [len(s[k]) for k in keys]) for n, s in boards.items()}
    return label, cells


def render_table(boards: dict[str, dict[str, str]]) -> list[str]:
    keys = shared_keys(boards)
    label_w, cell_w = column_widths(boards, keys)
    names = list(boards)
    lines = ["".ljust(label_w) + "".join(f"  {n:<{cell_w[n]}}" for n in names)]
    lines.append("-" * label_w + "".join("  " + "-" * cell_w[n] for n in names))
    for key in keys:
        lines.append(f"{key:<{label_w}}"
                     + "".join(f"  {boards[n][key]:<{cell_w[n]}}" for n in names))
    return [line.rstrip() for line in lines]


if __name__ == "__main__":
    for line in render_table(BOARDS):
        print(line)

$ uv run python -m labs.board_compare
           Raspberry Pi 4B          Jetson Orin Nano Super
---------  -----------------------  -------------------------
CPU        4x Cortex-A72 @ 1.8 GHz  6x Cortex-A78AE @ 1.7 GHz
GPU        VideoCore VI, no CUDA    Ampere, 1024 CUDA cores
Memory     4 GB LPDDR4, one pool    8 GB LPDDR5, one pool
Bandwidth  12.8 GB/s peak           102 GB/s peak
Storage    microSD or USB           M.2 NVMe, none included
Power      5 V over USB-C           9-19 V barrel jack
Wi-Fi      on the board             not on the board
GPIO       40-pin header            40-pin header

A format specifier like :<35 sets a minimum width and never a maximum, so a hard-coded column is a promise the data is free to break: one long cell shoves the rest of its row past the border and the alignment is gone. Measuring the widest cell first costs one pass over the same dictionary and makes that impossible. The row list comes from shared_keys rather than from one board picked by name, so adding a third column later cannot quietly drop a row that only two of the three boards declare.

Read the table before moving on. The GPIO row is identical, so the wiring loom built in Volume 7 physically survives the move, though the pin behaviour behind that header gets checked against the new chip in chapter 81. Wi-Fi, Power and Storage are the shopping list: budget for a USB adapter, a 19 V supply, and an NVMe drive, because none of the three is in the box. Everything that matters for how fast she thinks is in the two middle rows.

# labs/board_compare.py — added under the imports
POOL_GB = {"Raspberry Pi 4B": 4.0, "Jetson Orin Nano Super": 8.0}
RESIDENT_GB = {"Raspberry Pi 4B": 1.4, "Jetson Orin Nano Super": 1.9}
WEIGHTS_GB = {"llama3.2:3b": 2.0, "llama3.1:8b": 4.9, "qwen2.5:14b": 9.0}


def headroom_gb(board: str) -> float:
    """What is left of the shared pool once the OS and her own stack are resident."""
    return POOL_GB[board] - RESIDENT_GB[board]


def fit_verdict(board: str, model: str) -> str:
    slack = headroom_gb(board) - WEIGHTS_GB[model]
    if slack >= 0:
        return f"fits, {slack:.1f} GB spare"
    return f"short by {-slack:.1f} GB"


if __name__ == "__main__":
    for board in BOARDS:
        print(f"{board}: headroom {headroom_gb(board):.1f} GB of {POOL_GB[board]:.0f} GB")
        for model in WEIGHTS_GB:
            print(f"  {model:<13} {WEIGHTS_GB[model]:>4.1f} GB   {fit_verdict(board, model)}")

$ uv run python -m labs.board_compare   # resident figures measured on the bench — yours will vary
Raspberry Pi 4B: headroom 2.6 GB of 4 GB
  llama3.2:3b    2.0 GB   fits, 0.6 GB spare
  llama3.1:8b    4.9 GB   short by 2.3 GB
  qwen2.5:14b    9.0 GB   short by 6.4 GB
Jetson Orin Nano Super: headroom 6.1 GB of 8 GB
  llama3.2:3b    2.0 GB   fits, 4.1 GB spare
  llama3.1:8b    4.9 GB   fits, 1.2 GB spare
  qwen2.5:14b    9.0 GB   short by 2.9 GB

The resident figures are what the operating system, Python, faster-whisper and Piper were holding on each board with the voice loop idle. Subtracting them is the whole calculation, and it is a calculation you never have to do on a desktop with a graphics card, because there the model's budget is the card's own memory and the operating system lives somewhere else entirely. On both of these boards there is one pool and every user of it is a competitor. The first line of that output is also the answer to a question left open in Volume 1: the model chosen back in chapter 8 was 2.0 GB because 2.6 GB was all there was.

# labs/board_compare.py — continued
BANDWIDTH_GB_S = {"Raspberry Pi 4B": 12.8, "Jetson Orin Nano Super": 102.0}
MEASURED_TPS = {"Raspberry Pi 4B": 2.7, "Jetson Orin Nano Super": 18.4}
MODEL = "llama3.2:3b"


def peak_gb_s(board: str) -> float:
    """Peak memory bandwidth, the number the ceiling is computed from."""
    return BANDWIDTH_GB_S[board]


def ceiling_tps(board: str, model: str) -> float:
    """One token reads every weight once, so bandwidth over weight bytes is the ceiling."""
    return peak_gb_s(board) / WEIGHTS_GB[model]


if __name__ == "__main__":
    print(f"{MODEL}: {WEIGHTS_GB[MODEL]:.1f} GB of weights read per token")
    print(f"{'board':<24}{'GB/s':>7}{'ceiling':>10}{'measured':>10}{'of peak':>9}")
    for board in BOARDS:
        ceiling, measured = ceiling_tps(board, MODEL), MEASURED_TPS[board]
        print(f"{board:<24}{peak_gb_s(board):>7.1f}{ceiling:>10.1f}"
              f"{measured:>10.1f}{measured / ceiling * 100:>8.0f}%")

$ uv run python -m labs.board_compare   # measured column from the bench — yours will vary
llama3.2:3b: 2.0 GB of weights read per token
board                      GB/s   ceiling  measured  of peak
Raspberry Pi 4B            12.8       6.4       2.7      42%
Jetson Orin Nano Super    102.0      51.0      18.4      36%

That division is the most useful piece of arithmetic in the volume. Generating one token means running the whole network once, and every weight in the file gets read exactly once to do it, so a 2.0 GB model reads 2.0 GB per token. A board that can move 12.8 GB every second therefore cannot produce more than 6.4 tokens a second no matter how clever the software is, and one that can move 102 GB/s tops out near 51. Real engines land between a third and a half of peak once you count cache misses, the attention cache and the gaps between layers, which is where both measured columns sit. The ratio of the two measured rates is 6.8, and it comes almost entirely from the bandwidth row.