ai-infra-curriculum/ai-infra-engineer-learning

1. What this repository is

- This is not a runtime application repo; it is an education platform repository for an AI Infrastructure Engineer learning path.

- Its architecture is centered on content delivery: lessons, labs, quizzes, assessments, and three capstone-style projects.

2. Top-level structure

- The repo splits into four main subsystems:

- lessons/ for module-based curriculum content

- projects/ for production-style hands-on systems

- assessments/ for quizzes, exams, rubrics, and answer keys

- resources/ for cheat sheets, FAQs, and reading lists

- Supporting root files (README.md, CURRICULUM.md, GETTING_STARTED.md, VERSIONS.md, Makefile, requirements.txt, pyproject.toml) provide navigation, standards, and repo-wide tooling.

3. Curriculum content subsystem

- lessons/mod-101 through lessons/mod-110 form the core learning spine.

- Each module is organized the same way: lecture docs, lab docs, exercises, quizzes, and a module README.

- The content flows from fundamentals to advanced systems: foundations → cloud → containers → Kubernetes → pipelines → MLOps → GPU computing → observability → IaC → LLM infrastructure.

4. Learning progression boundary

- The lesson modules are static instructional content, not executable product code.

- They establish conceptual and procedural boundaries: what learners should know before touching the projects.

- The repo’s architectural “control plane” is the curriculum sequencing itself, managed through module READMEs and cross-references.

5. Assessment subsystem

- assessments/ provides the evaluation layer for the curriculum.

- It includes coding challenges, practical exams, quiz answer keys, and rubrics.

- This creates a clear separation between teaching content and evaluation artifacts, which is important for diagrams that distinguish learning materials from grading materials.

6. Project 101: Basic model serving

- projects/project-101-basic-model-serving is a compact production-style service architecture.

- Main components:

- src/api.py for the API surface

- src/model.py for inference logic

- src/config.py and src/utils.py for configuration/support code

- Deployment boundaries:

- Dockerfile and docker-compose.yml for local/container execution

- kubernetes/ manifests for cluster deployment

- monitoring/ for Prometheus and Grafana integration

- Data flow is straightforward: client request → API → model inference → response, with metrics exported for observability.

7. Project 102: MLOps pipeline

- projects/project-102-mlops-pipeline is a workflow-oriented system built around orchestration.

- The main control plane is Airflow DAGs in dags/:

- data pipeline

- training pipeline

- deployment pipeline

- Supporting execution layers live in src/:

- data/ for ingestion, preprocessing, validation

- training/ for train/evaluate

- deployment/ for rollout logic

- monitoring/ for health and metrics

- This project’s architecture is a pipeline chain: ingest/validate data → train/evaluate model → register/promote/deploy → monitor.

8. Project 102 external ML platform dependencies

- The README indicates integration with MLflow, DVC, PostgreSQL, Redis, and MinIO.

- Architecturally, that means the repo models a split between:

- orchestration and business logic in the repo

- persistent experiment/data/model state in external services

- This is a classic MLOps boundary: compute is ephemeral, metadata and artifacts are persisted.

9. Project 103: LLM deployment platform

- projects/project-103-llm-deployment is the most complex system in the repo.

- It has three major runtime paths:

- src/llm/ for LLM serving and optimization

- src/rag/ and src/ingestion/ for retrieval-augmented generation and document indexing

- src/api/ for the client-facing API and streaming responses

- Supporting concerns:

- src/monitoring/ for metrics and cost tracking

- prompts/ for template management

- scripts/ and notebooks/ for operational experiments and benchmarking

10. Project 103 data flow

- The LLM project has a multi-stage data path:

- documents are loaded and processed in ingestion

- chunks are embedded and indexed

- retrieval feeds the RAG pipeline

- the API streams generated responses back to clients

- In parallel, monitoring captures runtime metrics and cost signals.

- This project should be diagrammed as ingestion/indexing path + online inference path + observability path.

11. Infrastructure and deployment boundaries across projects

- All three projects use the same deployment patterns:

- containerization via Docker

- local multi-service development via Docker Compose

- Kubernetes manifests for production-style deployment

- The presence of hpa.yaml, GPU node pool manifests, services, config maps, and monitoring configs shows the repo emphasizes operational deployment, not just code.

12. Observability as a first-class subsystem

- Monitoring is not centralized in one shared service; it is embedded per project.

- Prometheus and Grafana appear in Projects 101 and 103, and project 102 adds model/pipeline monitoring.

- This makes observability a recurring architectural concern across the repo, with metrics, dashboards, and alerts attached to each runtime system.

13. Automation and quality gates

- GitHub Actions workflows exist both at the repo level and inside project folders.

- Tests are present in each project, typically using pytest.

- This means the repo has a layered quality model: documentation + tests + CI + deployment artifacts.

14. How to think about the repo in a diagram

- Model the repo as three concentric layers:

- Curriculum content layer: lessons, labs, quizzes, assessments

- Reference system layer: three project implementations showing real architectures

- Operational tooling layer: CI, docs, Docker/Kubernetes, monitoring, scripts

- The most important boundary is between static learning assets and executable project systems.