cd /news/computer-vision/system-design-for-physical-ai-counti… · home › topics › computer-vision › article
[ARTICLE · art-145306] src=dev.to ↗ pub= topic=computer-vision verified=true sentiment=· neutral

System design for physical AI: counting every billet and rebar at the mill, on hardware the authority owns

An open reference architecture proposes a physical-AI counting system for Pakistan's steel mills, using IP66 HDR cameras and sealed GPU-accelerated industrial PCs running fine-tuned RF-DETR detection and ByteTrack-class tracking under MicroShift and Triton to count billets, ingots, rebars and girders at each casting strand or cooling bed. Counts flow over a one-way link into an operator-owned production record of fourteen typed objects, so a revenue authority can reconcile actual output against declared production rather than relying on mill paperwork and weighbridge tickets. The design estimates about $4.45 million over three years for 300 installation points, with an owned frontier node costing roughly $686,000 versus $751,000 on AWS's deepest three-year plan.

by read3 min views1 publishedOct 5, 2026

This is the engineering summary of an open reference architecture. The paper, its object model as JSON and the model register are free to reuse under CC BY 4.0: https://muhammadumar89.github.io/codeninja-research/steel-production-count-pakistan/. The operator is described by class, never by name.

A revenue authority in Pakistan wants to know how much steel every melting and re-rolling mill actually produced in a filing period, not what the mill declared. Today it cannot: counts live in mill paperwork, weighbridge tickets and filings that never meet. The requirement is a counting system at every mill, in cumulative coverage bands, with a proof of concept whose accuracy is tested against the weighbridge before wider rollout.

Here is how that turns into a system the authority owns.

Each installation point, a casting strand or cooling bed, gets IP66 HDR cameras and one sealed, GPU-accelerated industrial PC. RF-DETR, fine-tuned per product type and per mill, detects billets, ingots, rebars and girders; a ByteTrack-class tracker holds identity across frames so one billet crossing two camera fields counts once. Detection and tracking run on the industrial PC under MicroShift and Triton, so counting survives a slow wide-area link.

Counts leave the mill through a one-way link into one operator-owned production record. The mill never edits a count.

The record holds fourteen typed objects: steel melting and re-rolling unit, installation point, industrial PC, production count event, product type, declared production, discrepancy case, revenue field officer, audit team, steel mill staff, tamper or offline alert, daily uptime record, product calibration record and weighbridge record.

From one count event a traversal reaches the product type it classifies, the calibration record that validates the detector version, the weighbridge record that measured that calibration's accuracy, the installation point and mill, the declared production for the same period, and the officer who owns any discrepancy. That is what makes a count evidence that survives an audit.

The object model ships as JSON (ontology/objects.json, format hyper-ontology/1).

weights = 753B parameters x 1 byte (FP8)      = 753 GB
need    = 753 GB x 1.2 (KV cache, activations) = 904 GB
node    = 8 x 141 GB                           = 1,128 GB -> one node

GLM 5.3 serves the compliance work surface from one node of eight 141 GB HBM-class GPUs. That GPU class is export controlled for Pakistan, so the node runs in a dedicated data center behind a licensing checkpoint, and the design refuses to silently swap in a smaller model that would change what the work surface can reason over.

Role Model Licence
Detection RF-DETR, Nano to Large checkpoints, fine-tuned per mill Apache-2.0
Tracking Roboflow trackers, OC-SORT and ByteTrack class Apache-2.0
Compliance work surface GLM 5.3, 753B mixture of experts at FP8 bespoke; commercial use, fine-tuning and redistribution permitted

The system counts and reconciles; it never assesses. A discrepancy case is opened against declared production and assigned to a named revenue field officer, with the audit team handling escalations. Tamper and offline alerts and a daily uptime record say whether the counting estate itself was honest and awake.

Owning the stack for three years comes to about 4,445,000 US dollars for 300 installation points, an assumed count for the paper's "hundreds of mills". The counting kits are 2,832,000 of that and cannot be rented. The one line a cloud can replace is the frontier node: owning it costs about 686,000 dollars against 751,000 on AWS's deepest three-year plan in the nearest region, about the same money, except that renting moves every mill's counted record outside Pakistan. A closed frontier model by the token matches the owned node at about 33 users. Every price is cited in the paper's Appendix A.

Full design, figures, Appendix A with every price cited, and the object model: the paper.

Designed on Praxis, CodeNinja's platform for designing physical AI systems. The object model imports into Hyper Ontology, which turns it into a living system. Load it yourself with the open hyper-ontology .

── more in #computer-vision 4 stories · sorted by recency
── more on @rf-detr 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/system-design-for-ph…] indexed:0 read:3min 2026-10-05 · —