With a fixed runway, don’t compare AI model architectures or edge boards in the abstract. Give each candidate a short spike of fixed length, write its pass/fail test before the spike starts, and commit to whatever passes. For a generative-design product, the default is a constraint solver with an LLM front end, unless diffusion proves it can meet the hard compliance rules. For an edge product, the default is Jetson Orin Nano, unless the cheaper NPU module’s toolchain passes on your exact model.

TechnoLynx’s generative AI R&D team pins down the compliance, latency and power criteria, designs and runs the spikes on the real model and the target board, and then builds and optimises on whichever option passes.

How to time-box a decision so the team actually commits

In a time box, the duration is fixed and the work is adjusted to fit inside it. For a decision, that means the date of the go/no-go gate never moves. If the spike runs short of time, you cut what it tests and keep the date. Jalote’s timeboxing model sizes iterations from a few weeks to a few months, with the exact length usually set by business considerations. A decision spike inside a six-month runway should take a small fraction of that, because every week spent deciding is a week not spent building the thing you decided on.

In an industrial case study of architecture decision-making, architects said time pressure forced quick decisions and sometimes pushed them towards easy-to-implement designs over long-term benefit. The study’s authors attributed the risk of missing a better solution to the lack of a systematic process. Yet they rejected process-heavy tools and asked for something lightweight. A spike with a kill criterion written in advance is about as lightweight as a systematic process can get.

Two rules keep the box honest. First, new ideas that come up mid-spike go to the next box, much as Jalote’s model passes non-critical change requests to a future time box. Second, the box tests feasibility and return first. The first thing to settle is whether the outcome is plausible at current capability.

One caveat sets the order of everything that follows. Jalote states that timeboxing does not suit projects where technology and architecture change frequently. So the architecture spike runs first. The silicon spike needs a frozen model to test, and a board chosen for a model that is still changing is a guess.

Diffusion, constraint solver plus LLM, or hybrid for code-compliant generative design

If the demo has to produce code-compliant output, start from a constraint-solver core with an LLM front end. Diffusion earns a place only if it passes a compliance spike, and even then keep it in the proposal stage rather than the enforcement stage.

How TestFit, Forma and Hypar split generation from constraint solving

One review of AI tools for Revit sorts them into four technical categories: diffusion-based image generation, LLM-mediated automation, machine learning for specific analyses, and parametric or constraint-based computation. TestFit and Hypar sit in the last category. TestFit’s Site Solver produces thousands of feasibility variations, and it is a constraint solver rather than a learned model. AEC Magazine calls it a massive parametric solving engine that is “mostly not AI at all”. Hypar’s co-founders say their platform maps natural-language input onto parametric functions written in Python and C#, and that “this isn’t AI”. Glyph Copilot uses a GPT model to parse intent, while the operations it runs are pre-built scripts. Autodesk Forma, the successor to Spacemaker, uses machine learning narrowly, to predict environmental performance such as sunlight and wind.

Learned models interpret what the user wants or predict a quantity, and a deterministic engine produces the geometry that has to hold. Follow that split unless your spike gives you evidence against it.

What diffusion does with hard constraints

Researchers fine-tuned Stable Diffusion v2.1 for floor plans and raised the share of valid plans from 6% for the untuned model to between 57% and 90%. Even so, the best result on quantity requests did not exceed 68%. Count and recolouring requests usually failed outright, layout instructions such as “kitchen left of living room” were ignored, and requested counts of rooms were met only by chance. One research team found that current diffusion approaches lack the ability to enforce hard spatial constraints such as building boundaries. Getting boundary adherence took an added Boundary Cross-Attention module. They also found that longer training improved FID while their diversity score fell from 52.69 to 33.59, and that the model failed on out-of-distribution layouts it had not seen in training.

An LLM route reports better adherence to numerical and topological constraints. One group fine-tuned Llama-3.3-70B-Instruct on JSON floor plans and then applied reinforcement learning with verifiable rewards. Any output that was invalid or had overlapping rooms received zero reward. On the eight-room task, with best-of-10 sampling, this cut the Compatibility error by 94% relative to HouseDiffusion. The authors are explicit that their rewards leave out egress, accessibility, structure and local building codes, so strong scores are not evidence of code compliance. That is why the compliance checks belong in a solver you control, with the LLM in front of it.

A hybrid still has a role. Work on diffusion as a generic solver (DiffSG) shows it can generalise to problem forms that resist hand-built methods, though its authors concede it may not beat classical algorithms on well-studied problems. In a hybrid, let diffusion or generative search propose layouts and the solver accept, repair or reject them. Expect integration work: the hybrid’s guarantees come only from the solver stage, and joining two systems adds failure modes of its own.

The minimum spike that kills diffusion early

1. Encode the hard rules as automated checks: room counts, adjacency, boundary adherence and every code clause you can compute from geometry.
2. Fix the pass rate and the end date of the spike before you generate anything.
3. Fine-tune with the cheapest method that works. The Rostock team used textual inversion because it trains quickly and produces a very small model.
4. Generate across your real prompt range, including inputs the training data does not cover, since one diffusion floor-plan model failed on out-of-distribution layouts.
5. Score every sample against the checks. If counts or contextual constraints come out right only by chance, treat that as the kill signal and default to the solver plus LLM.

The spike is only as good as the checks inside it. A compliance suite that covers half the rules will pass a model that breaks the other half.

When a cheaper NPU module beats a Jetson Orin Nano, and when it doesn’t

A cheaper NPU module wins in three conditions together. The model is a mainstream CNN detector or classifier already validated on the vendor’s toolchain, the frame rate target is modest, and power, enclosure or bill of materials dominate the product. Jetson Orin Nano wins when the model is a transformer, an LLM or VLM, or carries custom operators, or when the runway cannot absorb toolchain debugging.

Headline throughput is lopsided. ieeker, which sells RK3588 boards, quotes 6 TOPS for the RK3588 against 67 TOPS for the Jetson Orin Nano Super. NVIDIA states its figure as 67 sparse TOPS, and cross-vendor TOPS comparisons are usually invalid unless precision, operation counting and sparsity all match. What matters is the workload. ieeker reports YOLOv5s at about 22 fps and YOLOv5m at 12 to 15 fps on the RK3588 NPU alone. It calls 6 TOPS sufficient for YOLOv5/v8-class detection at up to 30 fps, at 5 to 8 W of system power against 15 to 25 W for the Orin Nano Super. Idein’s benchmark of YOLOX-S found the Hailo-8 gave the highest FPS, with inference latency nearly identical to Orin Nano in INT8.

Transformers change the picture. Covision Lab’s evaluation of ten accelerators found that all three ASIC NPUs failed on the transformer-based models, and that the Hailo-8 failed on four of the twelve reference models. A University of Florida lab engineer found YOLO models compiled well on Hailo but a vision transformer struggled, and concluded that Jetson with TensorRT remains the tool for anything large or transformer-heavy. For language models the sources disagree because they measure different paths. ieeker reports 2 to 5 tokens/s for small LLMs on the RK3588 CPU via llama.cpp and says the NPU does not accelerate attention efficiently. A tinycomputers.io benchmark reports 10 to 15 tokens/s for TinyLlama 1.1B in W8A8 on the RK3588 NPU. The tinycomputers.io figure covers only one model at 1.1B parameters. The Cloud to Edge benchmark found the Jetson Orin GPU led raw throughput at 9 to 10 tokens/s. It also suggested that NPU efficiency is more sensitive to model architecture than GPU inference is.

Batch size matters as well. On Intel’s integrated AI PC platform, for MobileNetV2 at FP16, the NPU gave about three times lower latency at batch size one, while the GPU overtook it at larger batches. That study used Intel’s integrated AI PC platform rather than an edge board, so read it as a direction to test rather than a figure to carry over.

Your situation	Lean towards
YOLOv5/v8-class CNN at up to 30 fps	Cheaper NPU module, after the spike
Vision transformer, VLM or LLM on device	Jetson Orin Nano
Custom or unusual operators, dynamic shapes	Jetson Orin Nano
Sealed fanless enclosure, tight power budget	NPU module, if the model passes
Small team, runway too short to absorb debugging of the board support package (BSP)	Jetson Orin Nano

What NPU toolchain risk looks like in practice

The software stack is part of the chip. An ONNX file is only the handoff, and static shapes, operator support, quantisation rules and host fallback decide what actually runs on the NPU. On the RK3588, one reviewer budgets 2 to 3 days of operator compatibility debugging per model and warns that unsupported operators fall back to the CPU silently, which tanks inference speed. Google’s Coral documentation is blunter. Its compiler can split the graph only once, so everything after the first unsupported operator runs on the CPU. On the Edge TPU, even a small CPU share can slow inference by an order of magnitude.

Quantisation is the second trap. Calibration with random or unrepresentative images can still produce a compiled artifact while damaging task accuracy. Qualcomm’s migration guide says 100 to 500 ordinary product frames usually make a better calibration set than 5,000 generic internet images. Versions are the third. RKNN-Toolkit2 and its runtime must match versions. Hailo’s final compile step can take hours and then fail on large models that don’t fit the accelerator. Board support matters too: one integrator ties BSP maturity directly to schedule risk for startups on fixed timelines. Also check access separately from availability, since a board can be easy to buy while its current compiler requires a customer agreement.

Jetson is not risk-free. TensorRT can build engines for the Orin DLA, but layers the DLA does not support run on the GPU only when GPU fallback is explicitly enabled.

Run the silicon spike in this order

LibreYOLO’s selection guide sets out an order that keeps cost from being compared before correctness:

1. Prove graph compatibility by compiling the exact exported model, not a similarly named zoo checkpoint.
2. Measure accuracy of the compiled artifact on the real task dataset after calibration and quantisation.
3. Measure end to end, including input conversion, transfers, decode and NMS.
4. Check software access: public, registration-only or behind a commercial agreement.
5. Freeze the version matrix: compiler, runtime, driver, firmware and target identifiers.
6. Check operating-system reality for your target (Yocto, Debian, Android and so on).
7. Check supply and lifecycle.
8. Only then compare cost, power and performance.

For the pass condition at the end of the spike, use the first-migration gate from the same Qualcomm migration guide. The ONNX output must match the training baseline, the converted and quantised artifacts must pass similarity thresholds, and the product metric must sit inside agreed tolerance. Latency, FPS and power are measured only after correctness passes, and the calibration set and version manifest are archived with the build. The same guide’s pre-migration list adds that accuracy, latency, power and thermal gates must be defined before work starts.

How costly is it to switch edge AI boards after you commit?

Switching boards rarely means retraining, but a compiled engine does not carry over. Every compiled artifact has to be rebuilt for the new stack and re-quantised from the source model. Qualcomm’s migration guide describes the job as turning a trained model into a production artifact for a different accelerator stack, not retraining from scratch. It also states that a TensorRT engine file does not migrate, because it is tied to TensorRT, CUDA, JetPack and the GPU architecture it was built for. A TensorRT calibration cache does not carry over either, so you re-quantise from the source model. The general rule from the LibreYOLO guide is to keep the original model and calibration data. Native NPU artifacts usually cannot be moved to another NPU generation or reliably rebuilt with another SDK release.

Per-model effort estimates vary by source. ieeker puts a standard YOLO conversion with RKNN-Toolkit2 at 1 to 3 engineer-days, covering ONNX export, calibration, accuracy validation and pipeline integration. The qscompute review expects 2 to 3 days of operator debugging per model. ieeker’s figure covers a standard YOLOv5 or YOLOv8 model. Multiply by every model in the product, and expect custom models to add export, quantisation and operator-debugging gates. Migration failures are also hard to read: an incorrect export, unrepresentative calibration data and an artifact built for the wrong runtime all look like “the model is bad”.

Staying inside the Jetson family is not free either. NVIDIA states that Jetson modules are software compatible, but a JetPack version change may need porting, and connector pin-outs and footprints vary between modules. Once the board is settled, the next problem is keeping requantised models safe in the field, which belongs to reliable edge AI deployment: compression, updates and observability. All of these switching estimates are workload-specific, so a different model can change the relative difficulty of a migration.

Unit cost, ROI and lifecycle

ieeker, which sells RK3588 boards, estimates a system cost of about $132 to $158 for its RK3588 board against $233 to $303 for a Jetson Orin Nano production system at 500 units a year. That works out to $75 to $145 saved per unit, or $37,500 to $72,500 a year. A qscompute comparison of all-in dev kit costs puts the gap at only $49, with the Orin Nano Super at $314 against $265 for the RK3588. An RK3588 board such as the Orange Pi 5 Max is quoted at about $150 to $180. NVIDIA’s own pages give different prices. Its launch blog gives $249 for the Super Developer Kit and its FAQ lists $399 for both the dev kit and the Orin Nano 8GB module at 1KU+, while the Cloud to Edge paper lists $304.78. Get a current quote for the module you would actually ship.

The ROI test is simple arithmetic. Divide the one-off cost of the NPU toolchain work and any later migration by the per-unit saving to get the break-even volume.

Lifecycle belongs in the same calculation. NVIDIA lists Jetson Orin Nano 8GB and 4GB availability through January 2032 and commits to an end-of-life notice at least eight months before last shipment. Developer kits carry no lifecycle commitment, so production designs should be built around modules. Modules ship with no software and attach to a carrier board you design or buy. Ask any NPU vendor for the equivalent commitment in writing. Qualcomm, for example, states a supply horizon of more than ten years for its IQ-9075 under its longevity programme.

The go/no-go gates for both decisions

Gate	Architecture spike	Silicon spike
Written before starting	Compliance checks, pass rate, end date	Accuracy, latency, power and thermal gates
First test	Hard-constraint checks on generated samples	Exact model compiles with no silent CPU fallback
Kill signal	Counts or layout constraints met only by chance	Product metric outside tolerance after quantisation
Default if killed or out of time	Constraint solver with LLM front end	Jetson Orin Nano module
Must be archived	Check suite and sample outputs	Source model, calibration set, version manifest
Commit trigger	Model frozen for the silicon spike	Lifecycle and unit cost checked on the production module

These gates still leave open questions. A hybrid that passes the architecture spike can still lose weeks in integration. An NPU that passes today can fail on next year’s transformer-based model. A decision gate settles the runway you have, not every runway after it. That is the real argument for the Jetson default under time pressure: it is not always the better board, but it runs a wider range of model families, including transformers, LLMs and VLMs.