[2026-09-02] Labs 1–3 (Hello + Cloud) are due September 6.
[2026-08-26] Welcome to Designing End-to-End ML Systems! The Fall 2026 syllabus and course schedule are now available.
Course Goals
The objective is to transition students from “using models” to “engineering systems.” By the end,
students will have built a complete end-to-end ML pipeline and optimized it for real-world deployment constraints.
Comprehend the need for Machine Learning Systems and why ML system is beyond the model.
Trace the end-to-end ML pipeline from data to deployment. Identify throughput, I/O, memory allocations, FLOPs bottlenecks at each pipeline stage.
Experiment with batching strategies for inference (static, dynamic, continuous). Calculate the throughput-latency tradeoff for a given SLA.
Quantify the impact of data quality and quantization on model performance
Comprehend model drift (data drift, concept drift) and explain why it matters for production systems. Design a monitoring pipeline that detects drift before accuracy degrades.
Prerequisites
If you are not sure that you have satisfied the prerequisites, speak to the instructor before the second lecture.
Prerequisite courses and experience include:
This is a programming heavy course. Expertise with Python is a must. Significant expertise in handling infrastructure, debugging, and being able to learn at an abstract level.
Familiarity with basic probability theory and linear algebra.
Student must have taken some introduction class on data science or be willing to take it along with the course.
One class lab a week, following the lectures. Each runs entirely in your browser, so
there is nothing to install and nothing to set up. Work through them in order, because
each one builds on the week before. Every lab ends by writing a short report for you to
download and hand in.
Training a model is the part you already know how to do. This lab is about the part that decides whether anyone ever gets to use it. It ends with a decision you have to defend: 200 people a second, one machine, and a promise about how long they wait.
Learning objectives
Explain why a good accuracy score does not mean a system is ready to use.
Say where the time actually goes when a system answers a request.
Defend a design decision with numbers instead of a hunch.
A trained model is really just a very long list of numbers, and those numbers have to live on a real machine. Will they fit? And once they do, how long does the machine take to read them all before it can answer anyone? Two questions, four machines, and an ending that catches most people out.
Learning objectives
Work out on paper whether a model will fit on a given machine.
Say what to do when it does not fit.
Split the time it takes to answer into three parts and find the slow one.
Explain why the slow part changes when you send more work at once.
Four months of work, a model that scores 95 per cent, and a tablet it was never going to fit on. This lab is about the stages of an ML project, the direction trouble travels along them, and what each stage has to hand the next one so that a problem gets caught by a machine rather than by a patient.
Learning objectives
Name the five stages, and say what makes them a loop rather than a line.
Trace a deployment constraint backwards to the stages that have to absorb it.
Say what one stage owes the next, and what breaks when it is not handed over.
Explain how a system can fail while every log line says it is healthy.
A model can be right ninety-nine times out of a hundred and still be worth nothing. This lab is about the data underneath it: who is in it, who is missing, why a broken field never makes anything crash, and how to read a score that is flattering you.
Learning objectives
Say why a broken piece of data does not make anything crash.
Work out who is missing from a dataset, and what that costs later.
Tell the difference between a rare thing and a small number of examples.
Read accuracy, precision and recall, and say which one a problem needs.
Pick where to set the line between alerting and staying quiet.
A card with three years of small purchases shows a charge for 5,000 pounds. The same row could be a typo, a holiday, a new job, or a terminal that has started double-charging everyone. Work out which, then do it again for values that are missing rather than wrong, and again for a dataset that was accurate until the world moved on.
Learning objectives
Give four reasons a value can be an outlier, and say why the response differs for each.
Apply Tukey's fences and a z-score, and say which breaks on skewed data and why.
Classify missingness as MCAR, MAR or MNAR, and say what each one permits.
Say what complete-case deletion does to the composition of a dataset.
Tell covariate, concept and prior shift apart from monitoring alone.
A 24 GB GPU, 7 GB of weights, and a run that completes the forward pass then dies with CUDA out of memory. Nothing in that error says where the other seventeen gigabytes went. Work down the execution stack until you can name the term responsible, then design the experiment that proves it.
Learning objectives
Classify symptoms into resource, throughput, numerical and correctness failures.
Use the execution stack to turn a symptom into a hypothesis about one layer.
Count MACs and FLOPs for a layer, and say why that does not predict its runtime.
Account for training memory in five terms and say which one dominates.
Design an out-of-memory experiment whose outcome rules something out either way.
You have 100,000 photos from doorbell cameras and can only afford to train on 20,000. And 60,000 of them are the same empty driveway. Delete the right 80,000 and you lose almost nothing. Delete the wrong 80,000 and the model stops working. Run the algorithms that choose for you, then work out whether the choosing cost more than it saved, which is the part nobody budgets for.
Learning objectives
Explain why having lots of compute and little data changes what you work on.
Work out how much accuracy each GPU-hour is actually buying you.
Run a real selection algorithm by hand, and say where it is blind.
Give two very different reasons a model might get an example wrong.
Work out whether choosing a subset cost more than it saved.
Pick the right method when you are short of labels, or short of time.
Last week you deleted 80,000 photos. The doorbell still cannot see people at night in the rain, because you only ever had 100 photos like that and deleting things does not create the ones you are missing. So you make them instead: blend photos together, learn how image generators actually work, then find out what one usable fake photo really costs. Ends with a training run that gets slower when you remove three quarters of the data.
Learning objectives
Tell a "too much data" problem from a "missing data" problem, and pick the right tool.
Blend two photos and say what label the result should get.
Explain how an image generator learns, without the maths.
Work out what one usable generated example costs you.
Say why a realistic picture can still ruin a model.
Find the bottleneck in a training pipeline, and know what will not fix it.
The course project is completed in three phases. Together, the three phases build a complete end-to-end ML pipeline.
Exams
There are two midterm exams, held according to the dates listed in the course schedule.
Grades
Assessment
Component
Weight
Assignments (5 Quizzes, 5 Reflections, Labs)
25%
Midterm
30%
Final Project
40%
Participation
5%
Grade Boundaries
Letter Grade
Percentage ≥
Letter Grade
Percentage ≥
A+
95
C+
77
A
92
C
73
A-
90
C-
70
B+
88
D
60
B
84
F
Below 60
B-
80
—
—
Rules
Course Expectations
Students are expected to complete the labs on a weekly basis as the lectures proceed.
Lecture discussions, lab assignments, and the course project are the core delivery mechanisms for the course material.
Lecture topics may include quizzes and discussions to gauge comprehension and attendance. Missed participation events cannot be made up and receive a grade of zero.
Labs and Deadlines
All labs are an individual effort. Understanding of the labs will be assessed through in-class exercises and quizzes.
Each lab must be submitted by the end of the week. Late submissions are not allowed unless acute circumstances have been communicated in a timely manner.
Exceptions may be made for an illness documented by a medical professional or when the instructor receives advance notice concerning illness, family-related matters, or career-related matters.
Information-technology problems, failures, or challenges are not appropriate excuses for late work.
Communication
The subject of course-related email must contain “CS.” Otherwise, a response is not guaranteed.
All electronic interactions are an extension of the classroom and must remain respectful and professional.
AI and Academic Integrity
Unless explicitly permitted as part of an assignment, students may not use ChatGPT or similar tools to solve course assignments.
All exercises and projects are intended to be an individual effort. Unauthorized collaboration or copying will result in a grade of zero for all students involved.
Academic-dishonesty violations involving programming exercises or projects will be reported to the Office of Academic Integrity.