Interactive lab redesign

Activity-Level MLSysIM Lab Blueprint

This page summarizes the implemented labs as ML systems trade-off environments. Each lab opens with a chapter anchor and track-specific scenario, then walks through one or more learning nuggets. Each nugget follows the same rhythm: predict, find the binding constraint, explore the trade-off surface, decide, and reflect.

2Book volumes covered
34Track-aware labs across Volume I and Volume II
4Canonical tracks: iPhone, Oura Ring, RoboTaxi, Cloud Fleet
30-60Expected minutes per full lab, depending on assignment depth

Depth And Narrative Contract

The labs are designed as substantial guided engineering activities, not quick demos. A compact run should take about 30 minutes; a full report-oriented assignment can reasonably take 45 to 60 minutes.

Opening narrative

Every lab should start with volume, chapter, title, chapter recap, learning objectives, track context, scenario brief, and lab map.

Chapter anchor

Each lab maps to a specific book chapter and turns that chapter into a systems decision: constraint, knob, evidence, and defensible choice.

Time-on-task

Default path: 3 to 5 minutes orientation, 20 to 35 minutes prediction/evidence/decision work, 7 to 15 minutes report and reflection.

Student artifact

The target artifact is a local Markdown report with track, scenario, predictions, evidence summary, final decision, residual risk, provenance/caveats, and result snapshot.

Canonical Track Materialization

Students pick one track and carry it through the labs. The track is not just a label: it changes stakeholder, device family, model family, metrics, guardrails, dominant constraints, narrative, and report framing.

Volume Track Arcs

The same chapter goals repeat across all tracks, but the long-form narrative changes. Volume I teaches deployment feasibility for a selected context. Volume II scales that same context into fleet, operations, responsibility, and synthesis questions.

Implemented Volume Coverage

This table shows what each lab is trying to teach, which book chapter it anchors to, and how the four tracks materialize the same pedagogy differently.

Volume Lab Chapter anchor Core concept Track materialization

Core Concepts

These are the cross-cutting ML systems ideas the labs should reinforce repeatedly.

Concept What students need to learn MLSysIM responsibility

Package Boundary

MLSysIM is the reusable engine for both the textbook and labs. The lab helper layer owns pedagogy and UI.

MLSysIM should contain

  • Constants and registries used by the book and labs.
  • Hardware, model, workload, and scenario data.
  • Domain formulas, solvers, sweeps, and result schemas.
  • Book-friendly helpers for reproducible callouts and figures.

Lab helper package should contain

  • Marimo UI components and layout.
  • Track selector and curriculum mapping.
  • Design ledger and browser persistence.
  • CSS, Plotly themes, prompts, and instructor-facing metadata.
Target import boundary: from mlsysim import Engine, Hardware, Models, Scenarios and from mlsysbook_labs import DesignLedger, track_selector, tradeoff_poster, decision_card

Experience System

The labs need a consistent academic shell, not a dark dashboard banner. The interaction should support chapter reading, repeated learning nuggets, prediction, trade-off exploration, reflection, and decision-making.

Visual Direction

  • Light academic interface with restrained borders and readable spacing.
  • Volume I accent: Harvard Crimson #A51C30.
  • Volume II accent: ETH Blue #1F407A.
  • Replace inline dark gradients with a shared lab_header().
  • Use status colors only for feasible, caution, violated, and selected states.

Pedagogical Cycle

  • Lab wrapper: volume, chapter, mini recap, track, scenario, and nugget map.
  • Each nugget names one chapter idea and why it matters.
  • Prediction before instruments are revealed.
  • Binding constraint, trade-off surface, engineering decision.
  • Reflection prompt and design ledger update.
Scope target: one chapter, one selected track, one scenario family, one to three learning nuggets, one main trade-off visual per nugget, and one final synthesis decision. This is enough depth for a 30 to 45 minute learning experience without filling headers with rigid time badges.

Interaction Devices

The device catalog defines which Marimo controls and visuals to use for each pedagogical purpose, so widgets are selected intentionally.

Control devices

Slider cards, range sliders, number predictions, radio/segmented strategy selectors, dropdowns, checklists, switches, and commit forms.

Visual devices

Constraint budgets, stacked bars, curves, Pareto frontiers, heatmaps, rooflines, queueing charts, timelines, world maps, topology diagrams, and tables.

Pedagogical devices

Prediction locks, method notes, failure boundary callouts, reflection cards, decision cards, before/after comparisons, and ledger timelines.

Critical lens

Each device must help students identify a knob, constraint, trade-off, decision, assumption, or residual risk.

Design Completeness

Before implementation, each lab should capture the ML systems translation, thematic nuggets, misconceptions, student artifacts, rubrics, and instructor use.

ML to systems

For every chapter: name the ML concept, systems translation, knob, binding resource, failure mode, and defensible decision.

Thematic nuggets

Reinforce durable ideas: D.A.M coupling, Iron Law, resource budgets, bottleneck migration, data movement, tails, scale, reliability, and responsibility.

Misconceptions

Each nugget should correct a specific wrong intuition, such as smaller is always faster or more GPUs always means linear speedup.

Artifacts and rubric

Capture prediction, bottleneck diagnosis, trade-off interpretation, selected configuration, residual risk, chapter principle, and result snapshot.

Downloadable report

Each lab should export a lightweight Markdown report and optional JSON ledger snapshot so students can submit evidence of completion.

Instructor guide

Use one consolidated guide organized by volume and chapter, with optional local notes beside each lab for maintenance.

Instructor Adoption

The labs should be easy to adopt as global teaching material. An instructor should understand why to assign a lab, where it fits, what students submit, and how to evaluate the result.

Mini recap

Every lab opens with the chapter emphasis, key terms, ML-to-systems translation, what to watch, and the common trap the lab corrects.

Assignment-ready

Each lab should include copy-ready assignment text, expected report contents, and a lightweight rubric.

Adoption modes

Standalone homework, lecture companion, module sequence, and capstone preparation should all be supported without redesigning the lab.

Instructor value

Students practice ML systems judgment without requiring a custom cluster, hardware kit, long build project, or instructor-authored simulator.

Student Report

Every lab should end with a simple downloadable artifact that a student can submit to show they completed the lab and made a reasoned ML systems decision.

What it proves

The student selected a track, completed the nuggets, interpreted the binding constraints, and made a defensible engineering decision.

Required fields

Student identifier, lab ID, volume/chapter, track, scenario, predictions, constraints, selected policy, trade-off interpretation, residual risk, timestamp, and MLSysIM version.

Format

Markdown first for easy submission and inspection. JSON ledger snapshot is optional for automated checks. HTML can come later if polish is needed.

Implementation boundary

mlsysbook_labs builds and downloads the report. MLSysIM provides typed, serializable result snapshots from the core engine.

This keeps completion evidence simple: the report is a lab artifact, not a grading platform. Advanced knobs may enrich the report when used, but they are never required for submission.

Versioning

The labs should be versioned like instructional infrastructure so instructors can assign stable material and students can submit reports that identify exactly what they completed.

Visible metadata

Each lab should expose lab ID, lab version, updated date, book anchor, MLSysIM version, helper package version, report schema version, and ledger schema version.

Report provenance

Downloaded reports must include lab version, MLSysIM version, report schema version, timestamp, track, scenario, and result snapshot.

Release channels

Stable for courses, preview for redesigned labs, and dev for active work. Stable releases need tests, changelog, instructor guide snapshot, and known limitations.

Change policy

Major changes alter assignment meaning, minor changes add supported capability, and patch changes fix defects without changing learning objectives.

Activity Matrix

Use the controls to filter by volume or search for concepts such as latency, compression, fairness, serving, or collective communication.

Volume Chapter / Lab Activity What will be covered How it will be covered MLSysIM needs

Volume 2 Mapping Decision

Decision: Volume 2 should add a dedicated Collective Communication lab and realign downstream lab numbering with the book sequence.

Option What it means Trade-off
Chosen Add a dedicated Collective Communication lab after Distributed Training and renumber downstream labs. Best chapter alignment and cleaner pedagogy. The implementation must update lab IDs, links, index entries, and ledger keys together.

MLSysIM Engine Plan

These APIs or model families should be added or consolidated so labs and textbook examples share one source of truth.