Lesson 2 of 6 · 0%Map the local inference boundary and GPU constraintsNext
Course map

Local Models, Performance and Cost Control

0 of 6 complete0 of 6

Lesson 2.2 · 50 minutes

Map the local inference boundary and GPU constraints

Decide what may run locally by mapping data movement, capacity limits, and the operational owner rather than treating “on-device” as a privacy guarantee.

Skip course map
Current lessonMap the local inference boundary and GPU constraints0% complete · 0/6 lessons

Local Models, Performance and Cost Control

0% complete · Current: Map the local inference boundary and GPU constraints

Verifiedon 2026.7.1

Action boundary

Before you act

Expected result
A boundary map identifies every system that receives input, output, logs, caches, credentials, or telemetry and records capacity assumptions.
Failure mode
“Local” is used as a proxy for private, cheap, fast, or reliable without inspecting the full request path.
Rollback
Do not admit the local route; retain the previously approved route while gaps are resolved.

Local is a boundary, not a verdict

A request can be generated on a local host and still cross other boundaries through authentication, updates, observability, remote tools, shared storage, or an operator’s diagnostic export. Treat each movement as a fact to establish, not an assumption to inherit from the word “local.”

Capacity is more than accelerator memory

Record the host profile used for a test: accelerator class and available memory, system memory, storage, CPU, power/thermal envelope, runtime version, queue policy, and competing workloads. The useful question is not “will it load?” but “does it remain within the agreed service boundary when the queue is busy?”

Learner artifact — redacted host readiness panel: Capture a test host’s resource view with hostname, user names, paths, tokens, model names where confidential, and identifiers redacted. Annotate available accelerator memory, system memory, observed queue depth, temperature/power policy if applicable, and the time window. Add alt text describing the observed capacity, not the pixels.

Lab: draw the request path

For one fixture case, draw:

  1. input origin;
  2. policy/approval boundary;
  3. inference host or provider;
  4. tool or retrieval systems, if any;
  5. logs, traces, caches, and exports; and
  6. human reviewer or escalation path.

At each arrow, label data class, retention owner, and whether the transfer is required. Then list the smallest load test that could falsify your capacity assumption: for example, the target concurrency plus one, over a defined interval, with the same fixture mix.

Checkpoint

A test host has spare accelerator memory while one request runs. What does that prove?

It proves only that one observed run fit that moment’s memory state. It does not prove concurrent capacity, tail latency, thermal stability, queue behavior, data handling, or recoverability. Promote none of those claims without their own observation.

Optional video queue — not an embed

The curriculum ledger names Tech With Tim’s Local Models Got a HUGE Upgrade (candidate 73UEJxAWzb0) for hardware discussion around 00:37–04:29. It is conditional only: a human editor must view the segment, recheck availability and embed status, cross-check current documentation, and complete privacy, rights, and accessibility review before it appears on a learner page. This lesson remains complete without it.

Source provenanceVerification and sources

Review receipt rr_local_models_boundary_gpu_fixture

Outcome
approved
Method
source-review
Reviewer
academy-specification-review
Reviewed

Evidence

  • academy-spec — curriculum-local-models-contract; snapshot 1c60fa76ac90…

Limitations

  • Approval covers the original workload, benchmark, routing, quota, and fallback method for 2026.7.1; it makes no universal provider, model, GPU, performance, privacy, or savings claim.

Open the public evidence snapshot

Lesson checkpoint

Ready to move on?

Mark this lesson complete when you can apply its outcome without relying on the examples above.