ptv3-p150

Point Transformer V3 (Autoware autoware_ptv3): the LiDAR segmentation and detection network of Autoware's autoware_ptv3 node (weights AutowareFoundation/ptv3 v4.0 with the pre- and post-processing of the node at autoware_universe 5eb9286), ported to one Tenstorrent Blackhole p150 with tt-nn. One concatenated LiDAR cloud in base_link in (x, y, z, intensity 0-255); for every input point a class (15 PTv3 classes, plus Autoware's PointCloudClassification value), its probability, the normalised entropy and the obstacle-cloud membership out, and optionally 3D boxes (CAR, TRUCK, BUS, BICYCLE, PEDESTRIAN, TRAFFIC_CONE, BARRIER). In Autoware, PTv3 is an opt-in ML ground-removal and segmentation stage whose detection head is idle; no tagged Autoware release runs these v4.0 weights (see Caveats). Weights: AutowareFoundation/ptv3 v4.0 · Paper: arXiv:2312.10035 · Autoware package: autoware_ptv3 @ 5eb9286 · Training code: not public (lineage: Pointcept → tier4/AWML projects/PTv3) · Port: code/

Runs on p150 (mesh P150). Configuration: dispatch on the ETH cores, 1 command queue, 12×10 compute grid. Two serve profiles of one image: seg (default; encoder + segmentation head, one metal trace: the autoware_launch wiring) and seg_det (adds the detection head as a second trace). Precision: fp32 weights with HiFi4 math and fp32 accumulation and fp32 activations in the encoder and the segmentation head, the serialized patch attention in fp32, two-term (hi + lo bf16) voxel features and detection-head convs; bf16 only in the gather tables, the detection decoder's attention and the heatmap peak selection; no bfp8. All numbers on this card were measured in this configuration.

Packaged and published with tt-model-manager 0.1.0 (manifest schema 5.1).

Quickstart (Python)

Prerequisite: a tt-metal / ttnn environment at tt-metal 44d66500520 with patches/tt-metal-eth-dispatch.patch applied. ttnn is not on PyPI.

hf download changh95/ptv3-p150 --exclude "image/*" --local-dir ptv3-p150 && cd ptv3-p150
pip install -e .                        # adds numpy<2, pillow, pyyaml, onnx, huggingface_hub; ttnn and torch come from tt-metal
pip install -e ".[server,test]"         # optional: the HTTP server and the tests

Run the snippet from the model repo root: code/tt_ptv3/samples/test_pcd.npz (Autoware's test.pcd) is a path relative to it.

from tt_ptv3 import PTv3

with PTv3.from_pretrained(device_id=0) as model:          # weights -> your HF cache, traces captured
    out = model("code/tt_ptv3/samples/test_pcd.npz")      # path, (N, 4) array, .npz/.npy/.pcd, or a PointCloud

print(out.class_counts())                                 # input points per class ("255": outside the crop)
for d in out.detections.to_dicts()[:5]:
    print(d["label"], d["score"], d["center"], d["size"], d["yaw"])

• from_pretrained downloads AutowareFoundation/ptv3 at the pinned commit 1673104843a (tag v4.0, three ONNX graphs, 170 MB) to your HF cache, opens the chip, builds the graph and captures the metal traces. With a warm JIT cache the load takes about 14 s; the first load on a machine also compiles the kernels (minutes).
• The traces are captured during the load, so the first call is as fast as the later ones.
• variant="seg" builds only the encoder and the segmentation head (Autoware's wiring; it skips the 45 ms detection trace); the Python default seg_det also runs the detection head.
• The with block releases the traces and closes the chip. Without with, call model.close().

Input	A point cloud in base_link: path (.npz / .npy / .pcd / .bin), raw bytes with fmt=, an (N, C) float array or tensor, or a PointCloud; fields x, y, z, intensity (Autoware's uint8 intensity 0-255; the feature is intensity / 255, the node's uint8 path). One concatenated sweep: the v4.0 node has no densification.
Options	run_detection=True, score_threshold=0.1, reconstruction="full" | "partial" | "none", neighbour_mode="alias-first" | "exact", min_voxels=16000 (the node's minimum; 0 disables it). from_pretrained(device_id=0, variant="seg_det" | "seg", dispatch="eth", weights_dir=None, device=None).
Output	PTv3Output: per output point label_ids (uint8, 255 = outside the crop), scores (probability), classification (PointCloudClassification), entropy, filter_keep (the node's obstacle cloud); detections (Detections3D: boxes x, y, z, length, width, height, yaw in base_link, scores, labels; or None); meta; timing_ms.
Methods	out.to_dict() gives the /predict JSON. out.class_counts(); out.detections.to_dicts(). tt_ptv3.viz.render_bev(xyz, out.label_ids, dets) draws a bird's-eye view.

• The API gives the same output as the HTTP server /predict: both share the decoders, the device traces and the host post-processing (checked on the device by test_api_equals_server).
• Every option is a host-side knob with the node's value as the default; none changes a device shape. A bad value is refused before the device runs.
• One model uses one chip; calls from several threads are serialised.
• Full reference: code/PYTHON.md. Runnable example: examples/quickstart.py (also writes quickstart_bev.png, the cloud coloured by class with the boxes, from above).

Serving (HTTP)

tt-model pull  changh95/ptv3-p150 --with-weights
tt-model serve changh95/ptv3-p150                       # profile seg (default); or with tt-cli: tt serve changh95/ptv3-p150
#   or, with the detection head (instead of the line above: one server per chip):
#   tt-model serve changh95/ptv3-p150 --profile seg_det
python3 code/tt_ptv3/server/client.py --points code/tt_ptv3/samples/test_pcd.npz --out req.json
curl -s localhost:20000/predict -H 'Content-Type: application/json' -d @req.json
tt model stop changh95/ptv3-p150

• The image does not contain the weights. --with-weights puts them in your HF cache.
• The server uses port 20000 (or the next free port). It is ready when the log shows Application startup complete.
• client.py builds the request with the standard library only; add --url http://127.0.0.1:20000 to send it.
• POST /predict: points (base64 .npz / .npy / .pcd / raw bin, base_link, fields x, y, z, intensity 0-255); optional params (every option above), output_format (json or npz). Also GET /health, GET /info, GET /v1/models (stub). Contract: SERVING.md section 3.

Served body of the shipped sample, profile seg_det (arrays are base64 NPZ, shortened here):

{
  "model": "ptv3-p150", "frame_id": "base_link", "num_points": 48048,
  "labels": {"format": "npz", "key": "labels", "dtype": "uint8", "shape": [48048], "data": "..."},
  "scores": {"format": "npz", "key": "scores", "dtype": "float32", "shape": [48048], "data": "..."},
  "classification": {"...": "uint8 [48048]"}, "entropy": {"...": "float32 [48048]"}, "filter_keep": {"...": "bool [48048]"},
  "class_names": ["car", "truck", "bus", "bicycle", "pedestrian", "traffic_cone", "barrier", "debris", "drivable_flat", "non_drivable_flat", "vegetation", "building", "vertical_thin", "static_clutter", "noise"],
  "class_counts": {"truck": 64, "debris": 1, "drivable_flat": 12, "non_drivable_flat": 17486, "vegetation": 24122, "building": 1789, "255": 4574, "...": 0},
  "num_detections": 1,
  "detections": [{"label": "TRUCK", "label_id": 1, "score": 0.1264, "center": [22.332, -0.724, 1.461], "size": [9.35, 2.567, 3.605], "yaw": -0.0085, "velocity": [0.0, 0.0], "autoware_label": "TRUCK"}],
  "meta": {"frame": {"num_points": 48048, "num_unique_voxels": 27346, "stage_counts": [27346, 16647, 8745, 3990, 1755], "...": "..."}, "neighbour_mode": "alias-first", "reconstruction": "full"},
  "timing_ms": {"decode": "...", "preprocess": "...", "device": "...", "postprocess": "...", "total": "..."}
}

• One row per input point, in input order (the node's full source reconstruction). Points outside the crop (x, y in [-122.88, 122.88) m, z in [-3, 5) m) get label 255 (INVALID), probability 0 and entropy NaN, and stay in the obstacle cloud.
• labels are the 15 PTv3 classes; classification the node's class_mapping to PointCloudClassification (CAR 0 … NOISE 11, INVALID 255); filter_keep the membership of ~/output/pointcloud/filtered (drivable_flat, non_drivable_flat and noise removed).
• detections (profile seg_det with run_detection) are in base_link metres / radians after the node's score threshold, yaw-norm gate, IoU-BEV NMS and area class remapper; center z is the box centre; autoware_label is the ObjectClassification the node publishes (TRAFFIC_CONE and BARRIER become HAZARD). The profile seg returns no detections.
• A frame with fewer than 16,000 voxels gets the node's empty output (meta.rejected) unless params.min_voxels is lowered.

Demo

The p150 output on the shipped sample (Autoware's test.pcd, one sweep, Apache-2.0): the cloud coloured by the p150's class next to the fp32 CPU reference's, and below only the points whose class differs.

PTv3 on p150 vs the CPU reference, test.pcd

On public driving datasets (p150 outputs; the frames themselves are not in this repository):

PandaSet 019, frame 40: front camera	PandaSet 019, frame 40: p150 vs the CPU reference
PandaSet 019, frames 20-59 (4 s at 10 Hz)	PandaSet 090, frame 40: bird's-eye view, ±60 m
nuScenes v1.0-mini scene-0103, key-frame 20: non-commercial, CC BY-NC-SA 4.0	the same frame from above, p150 vs the CPU reference: non-commercial, CC BY-NC-SA 4.0

Agreement with the fp32 CPU reference on these frames (per-point labels; boxes of the same label with centres within 0.5 m): test.pcd 99.89 %, 1 of 1 box; PandaSet 019 f40 99.76 %, 128 of 130 boxes (the p150 misses two pedestrians at scores 0.102 and 0.100 and adds a car at 0.101, all at the node's 0.1 threshold); PandaSet 090 f40 99.77 %, 132 of 135 boxes (the misses score 0.100-0.111); nuScenes 0103 key-frame 20 99.74 %, 18 of 18. The nuScenes frame has 15,414 voxels, below the node's 16,000 minimum: the stock node publishes nothing for it, so it ran with min_voxels=0 on both sides.

PandaSet renders: contains data from PandaSet (Scale AI and Hesai), https://pandaset.org, licensed under CC BY 4.0 and the PandaSet Dataset Terms; converted to an Autoware-style base_link and rendered with the model outputs (camera image downscaled, nearby vehicles and people pixelated); Scale AI and Hesai do not endorse this work. The nuScenes renders are non-commercial (CC BY-NC-SA 4.0): rendered from the nuScenes dataset, © Motional AD Inc., nuScenes Terms of Use; Motional does not endorse this work. Sources, changes and the full attributions: media/ATTRIBUTION.md.

Demo & Performances

Warm, batch 1, 2026-10-09 / 10. Latency: the stage bench of OPT_BASELINE.md (code/scripts/bench.py, 50 iterations per stage) on the shipped sample test.pcd (48,048 points, one sweep, 27,346 voxels) and on a PandaSet frame (106,501 points, one sweep, 73,992 voxels; not shipped), re-checked on the release code (20 iterations: trace A 840.18 ms, back-to-back A + B 885.45 ms, model() 1098.1 ms); the served rows from uvicorn on the host (the app the container runs) and a loopback client, 30 requests of the shipped sample per profile. The host is shared with other jobs, so the host stages move with its load (e2e by up to about 50 ms between processes); the device rows repeat to 0.2 ms. Accuracy: the p150 output against the fp32 CPU reference of the same network (same weights, same pre- and post-processing, identical host tables).

Metric	Performance
Agreement with the fp32 CPU reference, shipped sample test.pcd	99.89 % of point labels (classification 99.90 %, obstacle filter 99.95 %), 1 / 1 box (|Δscore| 0.0025)
Agreement, 21 frame cases (12 PandaSet frames, one of them also as the sample case; 4 frames of the T4 sample dataset; 4 nuScenes mini_val key-frames with the 16k minimum off), default alias-first neighbour tables	point labels ≥ 99.21 % per frame (worst: nuScenes 0103 k00); boxes recall 0.992 / precision 0.997 (same class, centres ≤ 0.5 m), |Δscore| ≤ 0.032, centres within 0.15 m
The same, exact neighbour tables	point labels ≥ 99.34 %; recall / precision 0.990 / 0.997; |Δscore| ≤ 0.036
Voxel label agreement, PandaSet 019 f40 / T4 scene 10 / nuScenes 0103 k20	99.70 / 99.80 / 99.65 %
Module PCC vs the fp32 reference on identical host tables (replay outputs, worst of the three frames)	encoder ≥ 0.999910 · segmentation head ≥ 0.999436 · detection head before the top-k ≥ 0.997936 · teacher-forced decoder and box heads ≥ 0.998353
Detection head top-500 proposals, set overlap with the reference (same three frames)	0.994 / 0.982 / 0.990
Python model() call, profile seg_det, test.pcd (host pre-processing, tables, H2D, both traces, D2H, post-processing)	1096.2 ms p50 (0.91 calls/s)
Python model() call, profile seg_det, PandaSet frame (not shipped)	1361.4 ms p50 (0.73 calls/s)
Python model() call, profile seg, test.pcd / PandaSet	1045.9 / 1334.1 ms p50
Served /predict timing_ms.total, test.pcd, profile seg / seg_det	1102.3 / 1110.1 ms median
Served client round trip, loopback, test.pcd, profile seg / seg_det	1115.2 / 1122.2 ms median (709 kB request)
Trace A (encoder + segmentation head), one blocking replay	840.4 ms
Trace B (detection head), one blocking replay	45.0 ms
Back-to-back replays per frame, seg_det (A + B) / seg (A)	885.1 ms (1.13 frames/s) / 837.9 ms (1.19 frames/s)
Host pre-processing (of which numpy neighbour maps) · tables · H2D (99.9 MB) · D2H · post-processing (test.pcd)	130.9 (105.2) · 39.7 · 19.3 · 1.6 · 2.8 ms
from_pretrained load, warm JIT cache	14.1 s

All numbers in this table were measured with dispatch on the ETH cores, 1 command queue and a 12×10 compute grid on one p150, with the published precision. This first release is the unoptimized port: the latency is dominated by capacity padding. Every encoder stage runs at the capacities of the node's 256k-voxel maximum (256,000 / 179,200 / 107,520 / 53,760 / 27,136 rows), which the measured frames fill to 6-29 %, so trace A costs about 840 ms for any cloud; a probe measured it at 421 ms with a 131k bucket and 71.5 ms with a bucket fitted to test.pcd, with bit-identical outputs. Capacity buckets are the first optimization target (OPT_REPORT.md). No paper-style metric is claimed: these weights were trained on TIER IV's T4Dataset only (15 segmentation / 7 detection classes that public datasets label differently), so a score on nuScenes or PandaSet would measure the domain gap and the label mapping, not the port; the accuracy rows are agreement with the CPU reference. Details: VERIFICATION_2026-10-10.md, OPT_BASELINE.md, OPT_REPORT.md.

No GPU comparison: no GPU was available on the host where this port was built and measured, so this card makes no GPU speed claim. The reference rows are the port's own fp32 CPU reference on the same host (a correctness baseline, not a speed target). Autoware runs this network as TensorRT engines (FP16 by default, per the upstream card); this port was validated against the fp32 reference, not against a TensorRT engine. p150 power per inference was not measured (the stage bench only logged the board's telemetry, median 75 W over the whole run including the host stages, OPT_BASELINE.md), so no efficiency comparison is made.

Caveats

• First release: baseline port, optimization pending. One frame is two metal traces of 1,264 programs, kernel-bound (op-to-op gaps 0.7 ms of 885 ms). The latency is dominated by capacity padding (above); inside trace A the fp32 patch attention is 49 % (410 ms: its p · v matmuls run on 16 cores and its scores pass through DRAM), and the host pre-processing adds 131-364 ms (numpy neighbour maps). OPT_REPORT.md ranks what comes next.
• Deployment status in Autoware: opt-in, segmentation only, and not in a tagged release. The v4.0 weights run only with the autoware_ptv3 node of autoware_universe main between 6910a9a (2026-07-16) and 5eb9286 (2026-09-01), whose semantics this port follows; the newest Autoware release (1.9.0) ships a different PTv3 network (v3), and the node on main after 5eb9286 expects a newer, unpublished model. In autoware_launch@main PTv3 is off by default (use_semantic_segmentation_ptv3:=false); when enabled it serves as ML ground removal and semantic segmentation, and nothing subscribes to its detections, so the node never runs the detection head there. The seg_det profile is provided for the node's full head set. This bundle is not a ROS 2 node (Python API and HTTP) and not a certified Autoware component; do not use it for safety-critical driving decisions.
• Documented deviations from the node:
  • neighbour tables: spconv's sub-manifold maps hash voxel keys linearly, and voxels in the top z layer alias onto other keys. The default alias-first reproduces that aliasing deterministically (the lowest-index voxel wins an aliased key); the TensorRT engine's choice depends on its GPU hash, so exact (true keys) is offered and validated too. The two emulations alone change 0.3-1.7 % of the voxel labels on public frames, which is why both sides of every comparison use identical tables;
  • one capacity bucket at the node's 256k-voxel maximum: voxels beyond 256k are clipped as the node does, but a frame whose pooled stages exceed the port's capacities (a margin over the largest measured pooling ratios) is refused instead of truncated; no measured frame comes close;
  • intensity: the input is read as Autoware's uint8 intensity (0-255, divided by 255: the node's path for the concatenated XYZIRC clouds); the node's float-intensity point formats (XYZI, XYZIRADRT) are not distinguished;
  • host steps: voxelization, Morton serialization, the pooling metadata, the sub-manifold neighbour maps, all gather tables, the segmentation reconstruction to the input points, the class LUT and obstacle filter, and the box decode, NMS and remapper run on the host in float32, bit-identical to the CPU reference; so does the last step of the detection head, center + bev_pos and the class / position split of the top-k index. The network (embedding, 5 encoder stages, decoder, classifier, softmax and per-voxel label / probability / entropy; fusion, BEV scatter-max, 12 dense convs, heatmap peaks, top-500 and the transformer decoder) runs on the device;
  • inputs are arrays or files, not PointCloud2 messages; sweeps, stream and camera inputs are refused (the v4.0 node has no densification and no state).
• nuScenes frames are below the node's minimum. Every single-sweep nuScenes key-frame has 10,256-15,564 voxels, below the 16,000 minimum of the node's TensorRT profile, so the stock node publishes nothing for them; the nuScenes validation ran with the minimum disabled (min_voxels=0) on both the CPU and the p150.
• Precision policy of this release: HiFi4 math with fp32 accumulation everywhere; the encoder and segmentation-head matmuls use fp32 weights with fp32 outputs and exact fp32 bias adds; the residual stream, LayerNorm, GELU and softmax are fp32; the voxel features are two-term (hi + lo bf16); the serialized patch attention computes q kᵀ, softmax and p v in fp32 (with the bf16 SDPA, point-label agreement on nuScenes 0103 k00 fell to 97.92 %, below the frozen 98.5 % gate); the sparse-conv and gather tables are bf16; the 12 detection convs use two bf16 weight terms and two-term activations; the detection decoder's attention, the heatmap local max and the top-k work in bf16 (the ops are bf16-only); no bfp8. The fp32 attention costs 410 ms of the 840 ms trace A today, the two-term detection convs 28 ms of trace B (OPT_BASELINE.md).
• Decision thresholds turn small differences into different outputs: a box near the score threshold 0.1 or at an NMS / top-k near-tie can appear or disappear (every unmatched box on the demo frames scores 0.100-0.111), and points where two classes are nearly tied can change class (0.1-0.8 % of points per frame). The agreement rows include all of these. Per-point probabilities and entropies are reported, not gated: where the labels agree, the probability differs by at most 0.064 on test.pcd and 0.25 on PandaSet 019 f40 (99.9th percentile 0.023 / 0.084, median 0.001), the normalised entropy by at most 0.086 / 0.111; the voxel probabilities are gated at PCC ≥ 0.99 (measured ≥ 0.9999).
• Domain: the weights were trained on T4Dataset (about 4,000 frames of TIER IV's VLS-128 + 4 × VLP-16 + Bpearl concatenated clouds, 96k-132k voxels); accuracy on another LiDAR setup can drop without fine-tuning, as the upstream card says. On the public frames (CPU reference, mapped labels, indicative only): vehicles, pedestrians, road and vegetation are segmented well (car IoU 0.94 on PandaSet, 0.85 on nuScenes mini_val), but PandaSet's Pandar64 gives about half the T4 density and nuScenes' HDL-32E about an eighth; T4's fine static classes (barrier, vertical_thin, static_clutter) do not transfer; no traffic cone or barrier is detected; parked bicycles are rarely detected. On PandaSet the base_link x origin is the pose origin under the roof rig, not the rear axle (offset unknown, not corrected).
• Validation scope: agreement with the fp32 CPU reference of the same network on Autoware's test.pcd, 4 frames of the T4 sample dataset, 12 PandaSet and 4 nuScenes v1.0-mini frames (plus the 40-frame demo sequence); the runtime knobs were validated at the node's defaults, in both neighbour modes and both variants.
• Does not scale to multiple p150 in a mesh configuration. The build uses a 12×10 compute grid of Tensix cores: the dispatch functions move from one Tensix column to the ETH cores (patches/tt-metal-eth-dispatch.patch), so this build assumes that you do not need chip-to-chip ethernet communication.
• dispatch="worker" (server: PTV3_DISPATCH=worker) is an A/B opt-in. On a p150 it gives an 11×10 grid (889.0 ms per A + B replay instead of 885.1 ms; its upload is 6 ms faster); if ETH dispatch is not available (tt-metal without the patch), the model falls back to it with a warning. The numbers on this card do not apply to that mode.
• Batch 1, one frame per request; requests are serialised on the chip. The device inputs have a fixed size (about 100 MB of index tables per frame at the 256k capacities), whatever the cloud.
• Not an OpenAI-compatible API; GET /v1/models is a stub so the tt-model ready card does not 404.
• p150 power per inference was not measured (only board telemetry during the stage bench), so no efficiency comparison is made.

Licensing

• Weights: AutowareFoundation/ptv3 at tag v4.0 (commit 1673104843af3c740145ac74dc4af6b8a4502bf3), Apache-2.0 per its model card. Not redistributed here: the package only points to them. The upstream card's training data: T4Dataset, about 4,000 frames (TIER IV), with a training configuration that is not public; the card carries no further data notice.
• Pre- and post-processing ported from autoware_universe perception/autoware_ptv3 @ 5eb9286 (Apache-2.0); the class tables and thresholds are read from the weights repo's ml_package_ptv3_*.param.yaml and the node's config.
• Port and serving code (code/): Apache-2.0. patches/tt-metal-eth-dispatch.patch modifies tt-metal (Apache-2.0).
• Sample data: code/tt_ptv3/samples/test_pcd.npz is derived from autoware_universe's perception/autoware_ground_segmentation/test/data/test.pcd (Apache-2.0): the non-zero returns moved to base_link; the *.reference.json files are CPU-reference outputs on it. Only this redistributable sample ships; the public-dataset and T4 frames of the accuracy rows are not in this repository.
• Demo media (media/, sources and changes in media/ATTRIBUTION.md):
  • PandaSet renders: Contains data from PandaSet (Scale AI and Hesai), https://pandaset.org, licensed under CC BY 4.0 and the PandaSet Dataset Terms. Changes: LiDAR converted to an Autoware-style base_link and rendered from above or over the resized camera image (nearby vehicles and people pixelated) with the model outputs. Scale AI and Hesai do not endorse this work. Cite: P. Xiao et al., PandaSet: Advanced Sensor Suite Dataset for Autonomous Driving, ITSC 2021.
  • nuScenes renders (media/ptv3_nuscenes_0103_kf20_*_NC.*), non-commercial, CC BY-NC-SA 4.0: Rendered from the nuScenes dataset, © Motional AD Inc., CC BY-NC-SA 4.0 and the nuScenes Terms of Use (https://www.nuscenes.org/terms-of-use). Non-commercial use only; adaptations under the same license. Motional does not endorse this work. Cite: H. Caesar et al., nuScenes: A Multimodal Dataset for Autonomous Driving, CVPR 2020.
  • ptv3_test_pcd_tt_vs_cpu.png: Apache-2.0.
  • The agreement rows use nuScenes v1.0-mini (CC BY-NC-SA 4.0), PandaSet (CC BY 4.0 + Dataset Terms) and the T4 sample dataset (licence not verified) as inputs; only the resulting numbers are on this card.

Provenance

These are the exact sources the container image was built from:

component	built from
tt-metal	44d66500520fda9f2c7060c0f6b41ec48f7ab37e + patches/tt-metal-eth-dispatch.patch (sha256 08d0ddf6…; dirty tree: the image includes the patch)
weights	AutowareFoundation/ptv3@1673104843af3c740145ac74dc4af6b8a4502bf3 (tag v4.0), files ptv3_encoder.onnx, ptv3_seg3d_head.onnx, ptv3_det3d_head.onnx, ml_package_ptv3_*.param.yaml, deploy_metadata.yaml (ONNX sha256 c244cfe2…, 06dcc59e…, 5b199d27…)
Autoware reference	autoware_universe 5eb9286d703b5de2dd8a30dfcd599d264ec7f13a (perception/autoware_ptv3, the last node revision that runs v4.0; not a tagged release)
shared package	ttaw 0.23.0, vendored as code/tt_ptv3/ttaw from the Autoware ports' shared common repository at commit 7b2c14b (code/tt_ptv3/ttaw/VENDORED.json: version, commit and per-file sha256)
code/ digest (image)	6bac7e0101b5f8c9 (sha256, first 16 hex digits; built.code_sha256 of tt_kernel_manifest.json)
image	tt-model/ptv3-p150:63450851e453 (sha256:63450851e453c20b4760f07517b7ac0b27e3f0f2a9e4f2f4fc2886f481e862e1)
base images	build stage ghcr.io/tenstorrent/tt-metal/tt-metalium/ubuntu-22.04-dev-amd64:latest @ sha256:df9d279c7f85c17c6fad982d196802682d669cca1b7ced9cbaad8181339cd5fc; runtime stage docker.io/library/ubuntu:22.04 @ sha256:5ec03bb3441e8b0bf3b4f9cd4629a1ae763010dc3035bb8da3ae6cf026486401 (tt-model's FROM tags float; these are the digests this build resolved, see build_info.json)
built	2026-10-10T00:34:49+00:00 by tt-model 0.1.0