Interactive labs

How to learn with these labs

Start with a question rather than a score. Search for a system you already know, then open a lab and read the model scope before changing any inputs. The visualization is a controlled thought experiment: it can make a queue, attention weight, retry policy, or resource allocation visible, but it cannot reproduce every timing detail of a production deployment. A useful first pass is to predict the direction of change and then check whether the displayed result agrees with your prediction.

The search field filters topic names and descriptions. Category narrows the collection to a subject area, while Experience distinguishes interactive lessons, exploratory models, and tools. Clear filters restores the full list. On an individual lesson, adjust one labeled parameter at a time, use Run or playback when available, and capture a baseline before changing a second parameter. Pause a timed model to inspect its intermediate state. If a page offers an observation notebook, record the starting inputs, the changed input, the output, and a possible explanation. Export the notes if you want to keep a copy; browser storage is not a durable backup.

For a concrete comparison, open a failure-isolation lesson and compare shared scheduling with reserved tenant capacity while keeping arrivals the same. Watch whether one tenant's long-held resources change the other tenant's queue and timeout count. In a transformer lesson, change a precision or sequence setting and inspect the resulting range or memory trade-off. These are model outputs under stated assumptions, not a benchmark of your hardware or a guarantee that a particular architecture will behave the same way.

Use the articles to understand what the model leaves out. A2A failure isolation adds protocol and operational context, while autoregressive generation explains a transformer execution sequence beyond a single animation. A good lab session ends with a failure case: find an input that contradicts your first intuition, write down which assumption mattered, and decide what evidence you would need from a real workload before changing a live system.