meteor-p150

METEOR, TIER IV's surround-view multi-task driving network released by the Autoware Foundation (meteor_v157c3Z.onnx, DepthSegIPMNetV52: a ResNet-34 + FPN encoder over eight cameras, image heads, a depth-gated IPM lift into one 96-channel 800×500 bird's-eye-view map at 0.2 m, BEV heads, an ego planner and three residual refiners; 48.25 M parameters, 2.58 TFLOP per frame), ported to one Tenstorrent Blackhole p150 with tt-nn. Eight camera images (768×432 RGB, raw and unrectified) with their intrinsics and extrinsics and the ego speed in; a BEV lane map, 3D boxes (vehicle / VRU) with stationary flags and agent futures, per-camera 2D boxes, 2D segmentation and depth, 3D occupancy, the ego-relevant traffic light, a risk field and three ego paths with steer / accel / brake out. Weights: AutowareFoundation/meteor v1.0 · Paper: none (GTC 2026 talk S81897; tier4/METEOR README) · Autoware package: none (METEOR's own runtimes, tier4/METEOR deploy/cpp) · Training code: tier4/METEOR (bevlane/train.py) · Port: code/

Runs on p150 (mesh P150). Configuration: dispatch on the ETH cores, 1 command queue, 12×10 compute grid. The whole network runs on the chip as ONE metal trace per frame (frame, 4,678 programs: the image encoder and heads of the eight cameras, the lift, the BEV trunk and heads, the planner, the refiners and the output packing); the image resize, the lift geometry tables (once per calibration), METEOR's C++ decode rules and the temporal state run on the host. 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 and patches/tt-metal-reshape-rm-sys1419.patch applied (the second one fixes an intermittent hang of row-major reshapes under ETH dispatch on Blackhole, see Caveats). ttnn is not on PyPI.

hf download changh95/meteor-p150 --exclude "image/*" --local-dir meteor-p150 && cd meteor-p150
pip install -e .                        # adds numpy<2, pillow, pyyaml, onnx, huggingface_hub, safetensors, opencv-python-headless; 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 (the sample path is relative to it).

from tt_meteor import METEOR, load_sample

with METEOR.from_pretrained(device_id=0) as model:      # weights -> your HF cache, trace captured
    out = model(**load_sample("code/tt_meteor/samples/synthetic_8cam.json"))   # 8 cameras + calibration + ego speed + stream

for d in out.to_dicts():
    print(d["label"], d["score"], d["center"], d["size"], d["yaw"], d["stationary"])
body = out.to_dict()
print(body["plan"]["mode"], body["trajectory"], body["traffic_light"]["state"])

• from_pretrained downloads AutowareFoundation/meteor at the pinned commit 01a5f6d71df (tag v1.0; meteor_v157c3Z.onnx, 335 MB, plus meteor_v157.param.yaml, LICENSE, SHA256SUMS) to your HF cache, opens the chip, builds the graph and captures the metal trace. The first load on a machine compiles the kernels (minutes: the container's first boot on an empty JIT cache was ready after 799 s); later loads take about 45-50 s (49.7 s measured with a warm kernel cache: most of it is the eager warm-up frame of 4,678 programs).
• The first call is as fast as the later calls: the load runs the whole graph eagerly before it captures the trace.
• The shipped sample is a synthetic test frame (a rendered street seen by a generic eight-camera rig; see code/tt_meteor/samples/README.md); feed your own rig's eight images, calibration and speed for real use.
• The with block releases the trace and closes the chip. Without with, call model.close().

Input	images: the eight cameras CAM_FRONT_WIDE, CAM_FRONT_LEFT, CAM_FRONT_RIGHT, CAM_BACK_WIDE, CAM_BACK_LEFT, CAM_BACK_RIGHT, CAM_FRONT_NARROW, CAM_BACK_NARROW, any order (path, bytes, PIL, uint8 array; raw, unrectified, at least 768×432, resized with OpenCV INTER_AREA semantics). An absent narrow camera (omitted, or an all-zero image) gets a zero input and its donor's pose, as trained. calibration: per camera intrinsics (of the image as sent) and T_ref_from_camera (camera optical frame -> base_link), or a preset. ego_speed (m/s). Optional stream: id, reset, T_world_from_ego for METEOR's host temporal state (BEV seg fusion, yaw smoothing, plan-mode hysteresis).
Options	Host post-processing (METEOR's C++ renderer defaults): det3d_threshold=0.15, det3d_topk=64, vehicle_threshold=0.35, vru_threshold=0.15, bev_nms_iou=0.3, bev_nms_containment=0.6, det2d_threshold=0.30, det2d_topk=48, det2d_hide="7", unk2d=True, mode_hysteresis=0.35, straight_margin=1.0, seg_fuse=True, thin_road_edge=True, yaw_smoothing=True, heads=False. Load time: from_pretrained(device_id=0, dispatch="eth", weights_dir=None, device=None, input_norm="onnx", depth_mean_bins="log", max_streams=16).
Output	MeteorOutput: 3D BEV boxes in base_link (center [x, y], size [length, width], yaw, score, label VEHICLE / VRU, stationary, future: 6 × [x, y] at 0.5-3 s), the selected ego path (6 × [x, y]) and the plan (mode, mode_probs, 3 paths, steer, accel, brake_prob), 2D boxes per camera (10 classes), unknown obstacles, the traffic-light state, the BEV lane map (uint8 800×500, 9 classes), timing_ms.
Methods	out.to_dict() gives the /predict JSON (out.to_dict("npz") with heads=True adds seg2d, depth, depth_mean, occupancy, risk, stationary); out.to_dicts() one dict per 3D box; out.path, out.lane.

• The API gives the same output as the HTTP server /predict: both share the decoders, the device trace and the host post-processing. One model uses one chip; calls from several threads are serialised.
• Full reference: code/PYTHON.md. Runnable example: examples/quickstart.py (writes the /predict JSON and a bird's-eye view, quickstart_bev.png).

Serving (HTTP)

tt-model pull  changh95/meteor-p150 --with-weights
tt-model serve changh95/meteor-p150       # or with tt-cli: tt serve changh95/meteor-p150
python3 code/tt_meteor/server/client.py --sample code/tt_meteor/samples/synthetic_8cam.json --out req.json
curl -s localhost:20000/predict -H 'Content-Type: application/json' -d @req.json
tt model stop changh95/meteor-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.
• POST /predict: images (all eight cameras, base64 JPEG / PNG / .npy, rgb8; an absent narrow camera as an all-zero image), calibration (per camera intrinsics and T_ref_from_camera, or {"preset": name}), ego_speed (m/s, required); optional stream (id, reset, T_world_from_ego), params, output_format. For your own frame: client.py --image CAM_FRONT_WIDE=f.jpg ... --calib rig.json --ego-speed 8.3. Also GET /health, GET /info, GET /v1/models (stub). Contract: SERVING.md section 3.

The shipped sample (a request after the warm-up, host server, 2026-10-10; trimmed):

{"model": "meteor-p150", "frame_id": "base_link", "num_detections": 8,
 "detections": [
   {"label": "VEHICLE", "label_id": 0, "score": 0.9932, "center": [-12.86, 0.095], "size": [4.399, 1.742], "yaw": -0.0687, "stationary": false, "future_mode": 0, "future": [[-11.92, -0.09], [-10.74, -0.15], ...]},
   {"label": "VEHICLE", "label_id": 0, "score": 0.9872, "center": [-7.176, -3.215], "size": [3.965, 1.731], "yaw": 0.0183, "stationary": false, ...},
   {"label": "VEHICLE", "label_id": 0, "score": 0.9624, "center": [10.84, 0.019], "size": [4.334, 1.761], "yaw": -0.0189, "stationary": false, ...},
   ...],
 "trajectory": [[0.74, 0.91], [0.85, 1.54], [0.41, 2.34], [0.31, 3.08], [0.62, 3.82], [0.3, 4.45]], "columns": ["x", "y"],
 "plan": {"mode": 0, "mode_probs": [0.233, 0.296, 0.471], "mode_logits": [...], "paths": [...], "steer": 0.0026, "accel": 0.021, "brake_prob": 0.131, "dt": 0.5},
 "detections_2d": {"CAM_FRONT_WIDE": [{"label": "car", "label_id": 1, "score": 0.5239, "box_xyxy": [412.76, 211.02, 438.5, 230.29]}, ...], ...},
 "unknown_obstacles": [],
 "traffic_light": {"state": "red", "state_id": 3, "probs": [0.363, 0.140, 0.031, 0.465]},
 "lane": {"format": "png", "key": "lane", "dtype": "uint8", "shape": [800, 500], "data": "iVBORw0KGgo..."},
 "lane_classes": ["bg", "road", "sidewalk", "crosswalk", "laneline", "stopline", "road_edge", "marking", "parking"],
 "stationary_head_healthy": true,
 "meta": {"present": [true, true, true, true, true, true, true, true], "v0": 8.0, "stream_id": "synthetic_8cam"},
 "timing_ms": {"decode": 83.95, "preprocess": 10.69, "device": 722.42, "postprocess": 86.08, "model_call": 820.65, "total": 908.67}}

• Boxes, paths and the lane map are in base_link metres (x forward, y left, origin on the road below the ego reference point); METEOR predicts BEV boxes without z, height or velocity. yaw is counter-clockwise from +x; boxes are sorted by score.
• trajectory is the selected ego path (METEOR's renderer: straight preference and mode hysteresis per stream); plan.paths holds all three modes. The synthetic sample is a test pattern (a red light, a car 11 m ahead): its plan barely moves forward (under 1 m in 3 s, drifting 4.5 m to the left) and is not meaningful driving; the stored CPU reference has the same path.
• lane is a PNG of the 800×500 class map (row 0 = 80 m ahead, column 0 = 50 m to the left); lane_classes names its values.
• meta carries the present cameras, v0 and the stream id; /info reports the device (ETH, 12×10), the camera order, the calibration presets and the load-time knobs.

Demo

PandaSet 019, frame 40 (San Francisco; CC BY 4.0): TT output	nuScenes scene-0103, key-frame 9 (Boston; CC BY-NC-SA 4.0, non-commercial): TT output

TT vs the fp32 CPU reference: PandaSet 019 frame 40, bird's-eye view	The shipped synthetic sample: TT vs the stored CPU reference

More: PandaSet 019 frames 0-48 as a GIF (every 4th frame, real-time playback), PandaSet 090 frame 40, and the camera heads (2D segmentation overlay and depth per slot) of PandaSet 019, PandaSet 090 and nuScenes scene-0103 (non-commercial). Every image shows outputs of this port on the p150, some next to the fp32 CPU reference; the BEV panels compare the plan with the logged ego path (white circles) and the 3D boxes with the dataset annotations (light blue). The public rigs map onto METEOR's eight slots as 6 real cameras, a virtual FRONT_NARROW centre crop of the front camera and an absent BACK_NARROW (zero image + the BACK_WIDE pose, as trained). Head and licence-plate regions of annotated people and vehicles are blurred. Sources, licences and changes: media/ATTRIBUTION.md. The weights were trained on TIER IV's own rig in Japan only, so both datasets are out of domain: the detections show the domain gap, not the port.

Demo & Performances

Warm, batch 1, eight cameras. Accuracy: the TT output against the port's fp32 CPU reference of the same network (same weights, same pre- and post-processing: METEOR's C++ runtime rules), which matches ONNX Runtime on meteor_v157c3Z.onnx (min PCC 0.99999990 over 155 taps and outputs). The gates are the PLAN thresholds, frozen at the first green run and never loosened. Speed: code/scripts/bench.py, p50 (p99) of 60 iterations, on a shared 8-core host (OPT_BASELINE.md).

Metric	Performance
Per-stage PCC vs the CPU reference, teacher-forced (26 gates, PandaSet 019 frame 40)	every tap ≥ 0.999989 (gate 0.99); lane / seg2d / depth argmax agreement 0.9984 / 0.9965 / 0.9936 (gate 0.99)
The served graph from the cameras, 4 frames of 3 rigs (PandaSet 019 / 090, nuScenes scene-0103, an in-domain METEOR demo frame)	min output PCC 0.99982; worst lane / seg2d / depth agreement 0.9963 / 0.9965 / 0.9925; selected ego path within 0.170 m (gate 0.3 m); 3D boxes strict recall / precision 1.0 / 1.0 on three frames, 0.971 / 0.971 (34 / 35) on the METEOR frame (gate 0.95)
38 public frames (PandaSet 019 and 090: 13 frames each, nuScenes scene-0103: 12 key-frames) through the served graph	argmax agreement lane ≥ 0.9971, seg2d ≥ 0.9962, depth ≥ 0.9925; dense-head PCC ≥ 0.9999 (hm, reg, stationary; risk ≥ 0.9996); all 19 outputs on one frame per sequence: PCC ≥ 0.9990 (depth_mean; the rest ≥ 0.99989); selected ego path 0.04-0.11 m from the CPU path (mean distance), the same plan mode and traffic-light state on all 38 frames; 3D boxes: every TT box matches a CPU box (precision 1.0), 408 of 418 CPU boxes matched (0.976): 9 of the 10 misses are CPU boxes within 0.004 of the class threshold (0.3507-0.3538 vs 0.35, 0.1505-0.1513 vs 0.15), the 10th a pedestrian whose TT peak lies 2.1 m away
Planned path vs the logged ego path (ADE, frames with a full 3 s future; a sanity metric, METEOR has no paper metric)	PandaSet 019 TT 0.598 m / CPU 0.552 m; PandaSet 090 2.570 / 2.472 m; nuScenes scene-0103 1.846 / 1.885 m
The shipped synthetic sample vs its stored CPU reference (the container smoke's check)	8 / 8 boxes (recall 1.000, precision 1.000), max |score difference| 0.0020, lane map agreement 0.9987, path ADE / FDE 0.018 / 0.030 m
input_norm=imagenet + depth_mean_bins=linear (the load-time option, two absent cameras) vs its own CPU reference	every float output PCC ≥ 0.99988; lane / seg2d / depth agreement 0.9980 / 0.9947 / 0.9934
Device, one frame (frame replay, 4,678 programs)	556.85 ms; back to back 556.75 ms: 1.80 frames/s device-bound
Python model(), the PandaSet 019 frame (eight 768×432 JPEGs, decoded)	918.2 ms (1,071.8): preprocess 11.2, camera transpose 26.3, upload 66.5, device 556.9, readback 17.2 + conversion 65.3, postprocess 129.9
Python model(), other inputs	synthetic noise 875.7 ms, PandaSet 090 902.8 ms, nuScenes 914.4 ms; the shipped sample 871.6 ms (release re-check, 30 iterations)
A call with a new calibration (rig change)	lift-table write 182.3 ms; call 1,128.5 ms
Served /predict on the host, shipped sample (uvicorn, loopback, after the first request)	timing_ms.total 904-909 ms (decode of the 1.8 MB body 81-84, preprocess 10.6, device 720, postprocess 86-87); client round trip 0.92-0.93 s; boot to ready 44.6 s (warm kernel cache)
ETH-dispatch stress (stress_frames.py --mode rigs: a rig change, table write, upload, replay and bit-compared read every frame)	2,000 frames clean on the baseline code (4 public rigs); 200 frames clean in this release (4 synthetic rigs, the golden-free mode), and 200 more inside the published container image (per-rig output hashes identical to the host run)

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, AICLK 1350 MHz. The device is kernel-bound (555.3 ms of kernels and 2.74 ms of op-to-op gaps for 4,678 programs); the image branch takes 268 ms of it (the three-term fp32 convs of the precision policy), and 57 % of the replay is layout, data movement and precision glue. The host rows move with the load of the shared host (a busier host added 18 ms to the PandaSet call in the release re-check). This is the first release: optimization has not started (OPT_REPORT.md ranks the plan; OPT_BASELINE.md has every measurement). Verification: VERIFICATION_2026-10-10.md.

Box agreement: a CPU box counts as matched when a TT box of the same class lies within 1 m (0.5 m for the gated frames and the shipped sample), one to one. The public frames are out of domain for METEOR, so they test the port (the same network on new rigs, lift tables and scenes), not the model's accuracy. 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: the raw data were used for local validation only and are not distributed here (only the _NC renders in media/ are); Motional does not endorse this work. Cite: H. Caesar et al., nuScenes: A Multimodal Dataset for Autonomous Driving, CVPR 2020.

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). Upstream reports 67.4 ms median per eight-camera frame on a Jetson AGX Orin (TensorRT INT8 with the 2:4-sparse trunk, CUDA Graph, zero-copy input; tier4/METEOR README) and about 30 ms with TensorRT fp16 on a data-centre GPU (the upstream model card); both are other precisions and, on the Orin, a different lift (the optional plugin path uses a coarser 0.8 m lift grid with the calibration baked in), so they are not like-for-like. p150 power was not measured, so no efficiency comparison is made.

Caveats

• Deployment status. There is no Autoware package for METEOR: neither autoware_universe nor the Autoware launch / ansible artifacts contain it; the upstream card and README list an Autoware (ROS 2) node as future work. METEOR is a reference model with its own Python and C++ TensorRT runtimes (tier4/METEOR), whose pre- and post-processing this port follows. It is not a ROS node and not a certified Autoware component: do not use it for safety-critical driving decisions (the upstream card: a research artefact that must not control a vehicle on public roads).
• First release: optimization pending. This is the functional baseline port; no optimization round has run yet (OPT_REPORT.md ranks the plan: TILE reshape copies, fused three-term convs, the input path, the lift as one gather kernel).
• ETH-dispatch hang, fixed. During the port the model hung intermittently under ETH dispatch (about 1 in 300 frames). The cause was one row-major ttnn.reshape writing 192-384 B DRAM pages from both NOCs (the Blackhole DRAM-arbiter issue SYS-1419), reproduced standalone in plain ttnn. patches/tt-metal-reshape-rm-sys1419.patch (built into the image) routes small destination pages to a single-kernel path; with it, 20,000 replays of the repro and two 2,000-frame rig-switch stress runs of the whole model were clean. Without the patch, ttaw 0.23.2 switches that resize tail to a TILE reshape (also clean, 38 ms slower per frame). Both patches are needed for the published configuration.
• Precision (the first release's policy: fp32 weights and biases, HiFi4, fp32 dest and packer L1 accumulation). The image branch and the 3D detection path run with fp32 activations, every conv as three bf16 terms (bf16 activations fail the depth argmax gate: 0.9797 < 0.99); the BEV trunk runs bf16 activations; the lift sums, the planner and every value that feeds a threshold, a softmax or an argmax are fp32. Outputs differ slightly from the fp32 reference (agreement figures above); objects and plan modes near a threshold can flip. The three-term image branch costs 166 ms of the 557 ms frame.
• Documented behaviour and deviations (PORT_LOG.md section 2, SERVING.md):
  • The input normalisation is the released graph's /255 (ONNX Runtime parity; decision D12), although METEOR was trained with ImageNet mean / std (an upstream export defect): input_norm="imagenet" (METEOR_INPUT_NORM) gives the trained normalisation, validated on the chip against its own CPU reference.
  • depth_mean keeps the exported log-spaced bin centres (parity); the trained bins are linear, 1 + 1.25 b m: depth_mean_bins="linear".
  • The temporal state (seg fusion, yaw tracks, plan hysteresis) is kept per stream.id on the host and resets on a new id or reset; upstream resets only the seg accumulator on a pose jump.
  • The released graph is single-frame and camera-only (its temporal memory and LiDAR input were baked out upstream).
• Domain gap. The weights were trained on TIER IV's eight-camera DRS rig in Japan (98 deg wide cameras, corner cameras pitched about 25 deg down, vertically squashed images). Other rigs work (the network takes K and T as inputs) but lose accuracy: on PandaSet and nuScenes the depth head is the main gap (only the camera with matching intrinsics gets METEOR-grade depth), 3D boxes are accurate but sparse, and the planner follows steady driving but not unseen intent (fp32 CPU reference on PandaSet 019: vehicles recall / precision 0.46 / 0.91 within 20 m of the LiDAR-supported annotations, planned-path ADE 0.55 m against the logged path vs 0.96 m on in-domain METEOR demo frames; the front camera's depth reads 1.65× the LiDAR range; on nuScenes scene-0103 the BEV drivable-area IoU is 0.39 against 0.70-0.74 on PandaSet).
• Fixed shapes. Eight 768×432 camera slots in METEOR's order, a 400×250 lift grid at 0.4 m, an 800×500 BEV at 0.2 m (±80 m × ±50 m); batch 1, one frame per request; requests are serialised on the chip. A new calibration costs about 0.2 s once (the lift tables, cached per rig).
• Validation scope. Agreement with the fp32 CPU reference on public data (PandaSet, nuScenes), on an in-domain METEOR demo frame and on the synthetic sample; no dataset-level metric exists for METEOR (no paper, no public split). The shipped sample is synthetic; a PandaSet sample is prepared but not shipped yet.
• 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: METEOR_DISPATCH=worker) is an A/B opt-in. On a p150 it gives an 11×10 grid (578.9 ms per frame with 2 CQs; the gates passed under WORKER during the port). 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.
• Not an OpenAI-compatible API; GET /v1/models is a stub so the tt-model ready card does not 404.

Licensing

• Weights: AutowareFoundation/meteor at tag v1.0 (commit 01a5f6d71df5ecbbb5853ec600825481d57b9c6b), Apache-2.0 per its model card and LICENSE. Not redistributed here: the package only points to them. The upstream card: trained with bevlane/train.py on TIER IV Co-MLOps DRS recordings in Japan, every supervision signal auto-generated (no human labels; adverse conditions added as NVIDIA Cosmos Transfer re-renderings of real scenes); the recordings are not public, and accuracy figures are measured on an internal split and not published. The AutowareFoundation/meteor-demo-scenes frames are for research and demonstration use only and are never redistributed or rendered here.
• Pre- and post-processing ported from METEOR's own runtimes, tier4/METEOR deploy/cpp and hf/onnx_smoke_test.py (Apache-2.0); there is no Autoware package.
• Port and serving code (code/): Apache-2.0.
• Sample data: code/tt_meteor/samples/synthetic_8cam* and the preset calib/synthetic_8cam.json were generated by this repository (code/scripts/make_synthetic_sample.py; no third-party data), Apache-2.0. No dataset sample is shipped; nuScenes and the METEOR demo scenes never ship, and a PandaSet sample (CC BY 4.0) is prepared but not yet included.
• Demo media (media/; per-file sources, frames and changes: media/ATTRIBUTION.md):
  • PandaSet renders (media/meteor_ps*): Contains data from PandaSet (Scale AI and Hesai), https://pandaset.org, licensed under CC BY 4.0 and the PandaSet Dataset Terms. Changes: camera JPEGs resized to 768x432 (and a centre crop for the virtual narrow camera), re-encoded, calibration converted to the METEOR layout; downscaled, heads and licence plates of annotated people and vehicles blurred; model outputs drawn. 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/*_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.
  • The synthetic-sample render (media/meteor_synthetic_8cam_tt_vs_cpu.png): generated by this repository, Apache-2.0.

Provenance

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

component	built from
tt-metal	44d66500520fda9f2c7060c0f6b41ec48f7ab37e + patches/tt-metal-eth-dispatch.patch + patches/tt-metal-reshape-rm-sys1419.patch (dirty tree: the image includes both patches; the image build asserts both markers)
weights	AutowareFoundation/meteor@01a5f6d71df5ecbbb5853ec600825481d57b9c6b (tag v1.0), files meteor_v157c3Z.onnx (sha256 50397b4d…b1a7), meteor_v157.param.yaml, LICENSE, SHA256SUMS
pre- / post-processing reference	no Autoware package; METEOR's runtimes, tier4/METEOR dc193a81e9959de57b751e269127ae9b67e3f300 (deploy/cpp, hf/onnx_smoke_test.py)
shared port code	ttaw 0.23.2 @ common 60b6dd7 (vendored in code/tt_meteor/ttaw, VENDORED.json)
code/ digest (image)	40de720599c6b5b9 (sha256, first 16 hex digits; built.code_sha256 of tt_kernel_manifest.json)
image	tt-model/meteor-p150:823dc1fbd4c7 (sha256:823dc1fbd4c7ec836a6e74486495d2801a71d6fa4e18d41011fa873749962afc)
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-10T17:04:30+00:00 by tt-model 0.1.0