brightlab.Made for curious mindsBrightlab
Year 11 · Deployment
What is the best system when quality is only one constraint?
Go to the investigation ↓A deployment decision brief with routing diagram, scenario results, fallback and benchmark plan.
Take this investigation into Python: open the interactive Marimo notebook →
Which deployment meets this school’s constraints?
Deployment design combines model quality with capacity, latency, privacy and cost. This simulation routes synthetic requests between local and hosted queues using explicitly supplied scenario coefficients. It calculates queue completion times, budget use and exposed data categories. These are modelled outcomes, not hardware benchmarks, vendor prices or measured quality. The exercise is to defend choices under constraints and test sensitivity to assumptions.
Before this lesson: Interpret latency distributions and compare cost and quality trade-offs. Useful earlier investigations: The cost of an alarm; Confidence meets its evidence.
Deployment design combines model quality with capacity, latency, privacy and cost. This simulation routes synthetic requests between local and hosted queues using explicitly supplied scenario coefficients. It calculates queue completion times, budget use and exposed data categories. These are modelled outcomes, not hardware benchmarks, vendor prices or measured quality. The exercise is to defend choices under constraints and test sensitivity to assumptions.
Interpret latency distributions and compare cost and quality trade-offs. Useful earlier investigations: The cost of an alarm; Confidence meets its evidence.
Plan two 60-minute sessions. Read the supplied fictional local/hosted coefficients and request sensitivity labels. State a school data boundary and budget before optimisation. Make clear that hardware names denote extension targets, not measured browser simulation performance.
ACARA V9 AI curriculum connection ↗ · Technologies ↗
A complete teaching sequence · 120 minutes
Teams rank functional requirements and distinguish hard privacy boundaries from preferences.
Ask: “Can a cheaper option compensate for a prohibited data transfer?”
Listen for: “No, a hard boundary rules it out.”
Predict queue delay when arrival rate approaches local capacity.
Ask: “Why might per-request compute time understate user wait?”
Listen for: “Requests can wait behind others.”
Allocate local and hosted capacity and routing proportion. Inspect the queue timeline, cost and quality coefficients. Hold requests fixed during comparisons.
Ask: “Which result is calculated from assumptions rather than measured?”
Listen for: “All displayed deployment outcomes in this simulation.”
Introduce a sensitive request during local overload; inspect why capacity pressure must not silently send it externally.
Ask: “Which constraint takes precedence?”
Listen for: “The stated data boundary; the request may need to wait or fail safely.”
In session two, choose a policy, test low and peak loads, vary one uncertain coefficient and draft a fallback procedure. Record queue delay, cost and unmet requirements.
Ask: “Does the policy remain acceptable when your optimistic assumption changes?”
Listen for: “We need a sensitivity test to know.”
Present routing, assumptions, required real benchmarks and accountable owner.
Ask: “What must be measured before a real launch?”
Listen for: “Actual latency, quality, failure behaviour, data handling and costs.”
The biggest model is always the best system.
A sensitive request cannot be routed to an otherwise fast hosted service when policy forbids that data transfer; the system needs a safe overload outcome.
Create a policy satisfying the data boundary, evaluate peak load and document any budget or latency failures with a fallback.
Require labels distinguishing simulated coefficients from real measurements. Check the overload policy preserves privacy and communicates failure.
| Criterion | Beginning | Secure | Extending |
|---|---|---|---|
| Constraint analysis | Optimises quality alone | Separates hard constraints and preferences | Tests conflicts and overload explicitly |
| Deployment evidence | Treats scenario values as benchmarks | Reports calculated outcomes and assumptions | Performs sensitivity tests and specifies real validation work |
Start with two queues, one request type and a fixed budget; introduce sensitivity labels after learners can trace completion times.
Compare queue policies such as first-come-first-served and prioritised short requests, including who bears increased waiting time.
All requests, quality values and costs are synthetic. No cloud service is contacted and no procurement claim should be inferred. Senior syllabus mapping must be verified locally.
Shared device? Turn remembering off. A project file lets you continue on another device.
Your browser is the laboratory
Increase arrival rate with compute capacity fixed. Predict how waiting time changes before viewing the queue.
Twenty-four requests arrive one second apart. Local service takes two seconds at cost 1 and quality coefficient 0.8. Hosted service takes 0.7 seconds at cost 4 and quality 0.9. All are fictional assumptions; sensitive requests must stay local.
The experiment opens after your prediction.
There is no penalty for being surprised.
Apple Silicon · PyTorch MPS
Run a real device matrix workload and a vectorised FIFO queue sensitivity study. Change arrival spacing and compare scenario service times and latency; measured execution time is reported separately from simulated service latency.
Students extend the experiment in teams, documenting parameters, outputs and limitations.
The bundle contains lesson-specific working code, a configuration file, a reactive notebook, a deterministic CPU check and hardware setup instructions. Acceleration is reported only after a tensor operation and result read-back succeed.
Download Mac Studio investigation ↓unzip y11-deploy-mac-pathway.zip -d y11-deploy-mac cd y11-deploy-mac bash setup-mac.sh source .venv/bin/activate python experiment.py --device mps --output results marimo edit notebook.py
CPU and available-device execution status is recorded in the downloaded README and validation report. DGX Spark execution requires that hardware; static validation alone does not establish GPU compatibility or performance. The browser lesson remains fully available without this extension.
NVIDIA DGX Spark · PyTorch CUDA
Run a real device matrix workload and a vectorised FIFO queue sensitivity study. Change arrival spacing and compare scenario service times and latency; measured execution time is reported separately from simulated service latency.
Students extend the experiment in teams, documenting parameters, outputs and limitations.
The bundle contains lesson-specific working code, a configuration file, a reactive notebook, a deterministic CPU check and hardware setup instructions. Acceleration is reported only after a tensor operation and result read-back succeed.
Download DGX Spark investigation ↓unzip y11-deploy-dgx-pathway.zip -d y11-deploy-dgx cd y11-deploy-dgx bash run-dgx.sh # Open the localhost notebook URL printed by the container.
CPU and available-device execution status is recorded in the downloaded README and validation report. DGX Spark execution requires that hardware; static validation alone does not establish GPU compatibility or performance. The browser lesson remains fully available without this extension.
A deployment decision brief with routing diagram, scenario results, fallback and benchmark plan.
Download the editable handout →