Skip to content

GPU Infrastructure for ML Workloads - Learning Plan

Target Audience: Infrastructure engineers transitioning to AI/ML infrastructure
Prerequisites: Kubernetes basics, Linux system administration, Python fundamentals
Estimated Time: 8-12 weeks intensive study + hands-on practice

Overview

This learning plan teaches GPU-based infrastructure building and operations for machine learning workloads. The goal is to become capable of: - Operating GPU clusters on Kubernetes - Building ML model serving infrastructure (inference) - Configuring distributed training environments - GPU resource management and cost optimization

Why Relevant: - AI/ML infrastructure engineer roles (e.g., Kraken Senior AI Compute Infrastructure Engineer) - LLM serving infrastructure (backend for ChatGPT-like systems) - Emerging field: few experienced engineers, high demand

10 Modules: From Basics to Production-Ready Infrastructure

Module 1: GPU Fundamentals and CUDA Introduction

Goal: Understand how GPUs work, how they differ from CPUs, and what CUDA is.

Learning Materials:

  1. GPU Architecture Basics
  2. CUDA cores vs. CPU cores (parallelism)
  3. Memory hierarchy: VRAM, L1/L2 cache, registers
  4. Throughput vs. latency optimization
  5. Source: NVIDIA CUDA Programming Guide (official documentation)

  6. Link: https://docs.nvidia.com/cuda/cuda-c-programming-guide/

  7. NVIDIA GPU Hardware Overview

  8. GPU generations: Pascal → Volta → Ampere → Hopper → Blackwell
  9. Datacenter GPUs: A100, H100, L40S
  10. Consumer GPUs for ML use: RTX 3090, RTX 4090
  11. Tensor Cores (FP16, BF16, INT8 support)
  12. Source: NVIDIA Data Center GPU documentation

  13. Link: https://www.nvidia.com/en-us/data-center/

  14. CUDA Basics (from Python)

  15. CUDA toolkit installation
  16. GPU detection: nvidia-smi command
  17. PyTorch/TensorFlow GPU support
  18. Practice: Simple CUDA kernel execution from Python (CuPy library)

Hands-on Assignment (2-3 days): - Install CUDA toolkit (WSL2 or native Linux) - Run nvidia-smi command, interpret output - Simple PyTorch script on GPU (matrix multiplication benchmark) - Blog post: "GPU vs CPU: Why GPUs are faster for matrix multiplication"

Checkpoint: - Can explain why GPUs are suitable for parallel workloads - Understand VRAM vs. system RAM difference - Can identify GPU bottlenecks (from nvidia-smi output)

Module 2: Kubernetes GPU Support and Device Plugins

Goal: Using GPUs in Kubernetes cluster, resource scheduling.

Learning Materials:

  1. NVIDIA GPU Operator
  2. What is NVIDIA GPU Operator (Kubernetes operator pattern)
  3. Components: NVIDIA driver, CUDA runtime, device plugin, monitoring
  4. GPU node labeling and tainting
  5. Source: NVIDIA GPU Operator documentation

  6. Link: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/

  7. Kubernetes Device Plugin Framework

  8. Device plugin API (kubelet integration)
  9. GPU resource request/limit syntax (nvidia.com/gpu: 1)
  10. GPU sharing vs. exclusive allocation
  11. Source: Kubernetes Device Plugin documentation

  12. Link: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

  13. GPU Scheduling and Node Affinity

  14. Node selector by GPU type (A100, H100)
  15. Taints/tolerations for GPU nodes
  16. Gang scheduling (multi-GPU distributed training)
  17. Source: Volcano Scheduler documentation (advanced GPU scheduling)
  18. Link: https://volcano.sh/

Hands-on Assignment (5-7 days): - Kind/minikube cluster + NVIDIA GPU Operator deployment (if GPU available) - Alternative: Cloud GPU instance (GCP n1-standard-4 + 1x T4 GPU, $0.50/hour) - Deploy simple PyTorch pod with GPU resource request - Monitor GPU utilization: kubectl exec + nvidia-smi - Test GPU resource limits: what happens when 2 pods request 1 GPU?

Checkpoint: - Deployed GPU Operator on Kubernetes - Can request GPU in pod manifest - Understand GPU sharing limitations (why exclusive allocation needed)

Module 3: ML Model Serving - vLLM

Goal: Understanding LLM inference serving with vLLM (fastest open-source serving engine).

Learning Materials:

  1. What is ML Model Serving?
  2. Training vs. inference difference
  3. Inference latency, throughput, concurrency
  4. Batching strategies (static vs. dynamic batching)
  5. Source: Google SRE Book - Chapter on Serving Infrastructure

  6. Link: https://sre.google/workbook/

  7. vLLM Basics

  8. PagedAttention (vLLM key innovation - KV cache management)
  9. Continuous batching (dynamic batching for LLMs)
  10. vLLM vs. HuggingFace Transformers (speed comparison)
  11. Source: vLLM official documentation

  12. Link: https://docs.vllm.ai/

  13. vLLM Deployment on Kubernetes

  14. Docker image build with vLLM
  15. Model loading (HuggingFace Hub integration)
  16. GPU memory estimation (model size vs. VRAM)
  17. Source: vLLM Kubernetes deployment guide
  18. Link: https://docs.vllm.ai/en/latest/serving/deploying_with_kubernetes.html

Hands-on Assignment (7-10 days): - Cloud GPU instance (1x A10G or T4) - Deploy vLLM + Llama-3-8B model (or Mistral-7B) - Test API endpoint: /v1/completions (OpenAI-compatible API) - Benchmark: latency, throughput (requests/sec) - Experiment: batch size impact on throughput - Blog post: "vLLM benchmarking - Llama-3-8B on A10G GPU"

Checkpoint: - Ran vLLM server on Kubernetes - Understand PagedAttention concept (KV cache optimization) - Can explain latency vs. throughput trade-off

Module 4: NVIDIA Triton Inference Server

Goal: Multi-model, multi-framework serving (vLLM alternative/complement).

Learning Materials:

  1. Triton Inference Server Overview
  2. Multi-backend support (TensorRT, ONNX, PyTorch, TensorFlow)
  3. Model repository structure (config.pbtxt)
  4. Dynamic batching and sequence batching
  5. Source: NVIDIA Triton documentation

  6. Link: https://docs.nvidia.com/deeplearning/triton-inference-server/

  7. TensorRT Basics

  8. Model optimization (quantization, pruning, kernel fusion)
  9. FP16/INT8 precision (speed vs. accuracy trade-off)
  10. TensorRT engine building workflow
  11. Source: NVIDIA TensorRT Developer Guide

  12. Link: https://docs.nvidia.com/deeplearning/tensorrt/

  13. Triton Kubernetes Deployment

  14. Helm chart usage
  15. Model versioning (A/B testing support)
  16. Metrics endpoint (Prometheus integration)
  17. Source: Triton Kubernetes deployment examples
  18. Link: https://github.com/triton-inference-server/server/tree/main/deploy/k8s

Hands-on Assignment (7-10 days): - Deploy Triton Inference Server on Kubernetes - Convert PyTorch model → ONNX → TensorRT - Serve model on Triton (ResNet or BERT) - Compare performance: PyTorch backend vs. TensorRT backend - Test dynamic batching (1 vs. 4 vs. 8 batch size) - Blog post: "Triton Inference Server - Model optimization with TensorRT"

Checkpoint: - Deployed Triton server - Converted model to TensorRT - Understand dynamic batching mechanics

Module 5: Distributed Training Fundamentals

Goal: Understanding multi-GPU and multi-node training (data parallelism, model parallelism).

Learning Materials:

  1. Distributed Training Strategies
  2. Data parallelism (DDP - DistributedDataParallel)
  3. Model parallelism (Tensor parallelism, Pipeline parallelism)
  4. Hybrid parallelism (FSDP - Fully Sharded Data Parallel)
  5. Source: PyTorch Distributed Training Tutorial

  6. Link: https://pytorch.org/tutorials/beginner/dist_overview.html

  7. NCCL (NVIDIA Collective Communications Library)

  8. All-reduce, all-gather, broadcast operations
  9. InfiniBand vs. Ethernet (GPU node networking)
  10. NCCL performance tuning
  11. Source: NVIDIA NCCL documentation

  12. Link: https://docs.nvidia.com/deeplearning/nccl/

  13. PyTorch FSDP (Fully Sharded Data Parallel)

  14. ZeRO optimization (DeepSpeed origin)
  15. Sharding strategies (full, hybrid, no shard)
  16. Memory efficiency (vs. DDP)
  17. Source: PyTorch FSDP Tutorial
  18. Link: https://pytorch.org/tutorials/intermediate/FSDP_tutorial.html

Hands-on Assignment (10-14 days): - Multi-GPU setup (2-4 GPUs - can use cloud: 1x p3.8xlarge AWS = 4x V100) - Implement simple DDP training (CIFAR-10 dataset) - Compare training time: 1 GPU vs. 2 GPUs vs. 4 GPUs (scaling efficiency) - FSDP experiment: Train Llama-3-8B (smaller model due to budget constraints) - Monitor GPU utilization: nvidia-smi dmon (all GPUs) - Blog post: "Distributed training scaling - DDP vs. FSDP comparison"

Checkpoint: - Ran multi-GPU training - Understand data parallelism concept - Aware of NCCL's role (inter-GPU communication)

Module 6: GPU Observability and Monitoring

Goal: GPU metrics collection, dashboards, alerting.

Learning Materials:

  1. NVIDIA DCGM (Data Center GPU Manager)
  2. GPU metrics: utilization, temperature, power, memory
  3. DCGM exporter (Prometheus integration)
  4. GPU health checks (ECC errors, thermal throttling)
  5. Source: NVIDIA DCGM documentation

  6. Link: https://docs.nvidia.com/datacenter/dcgm/

  7. Prometheus + Grafana GPU Dashboards

  8. DCGM exporter deployment on Kubernetes
  9. GPU metrics scraping (Prometheus ServiceMonitor)
  10. Pre-built Grafana dashboards
  11. Source: DCGM Exporter GitHub repo

  12. Link: https://github.com/NVIDIA/dcgm-exporter

  13. Alerting Strategies

  14. GPU utilization thresholds (underutilization = cost waste)
  15. Temperature alerts (thermal throttling prevention)
  16. Memory saturation (OOM prediction)
  17. Source: Prometheus Alerting Best Practices
  18. Link: https://prometheus.io/docs/practices/alerting/

Hands-on Assignment (5-7 days): - Deploy DCGM exporter on Kubernetes cluster - Configure Prometheus scraping (GPU metrics endpoint) - Import Grafana dashboard (NVIDIA official dashboard) - Create custom alert: GPU utilization <20% for 1h (cost optimization signal) - Test alert: trigger low utilization scenario - Blog post: "GPU observability - DCGM + Prometheus + Grafana setup"

Checkpoint: - See GPU metrics on Grafana dashboard - Can write custom alerts on GPU metrics - Understand GPU health monitoring importance (ECC errors, thermal issues)

Module 7: GPU Cost Optimization

Goal: Minimizing cloud GPU costs, on-prem vs. cloud trade-offs.

Learning Materials:

  1. Cloud GPU Pricing Models
  2. On-demand vs. spot instances (AWS, GCP, Azure)
  3. Reserved instances (1-3 year commitments)
  4. Preemptible instances (GCP) / Spot instances (AWS) - 60-80% savings
  5. Source: Cloud provider pricing pages
  6. Link (GCP): https://cloud.google.com/compute/gpus-pricing

  7. Link (AWS): https://aws.amazon.com/ec2/instance-types/p4/

  8. GPU Utilization Optimization

  9. Time-slicing (NVIDIA MIG - Multi-Instance GPU)
  10. Model quantization (FP16, INT8) - cost savings via smaller GPU
  11. Batch size tuning (throughput maximization)
  12. Source: NVIDIA MIG User Guide

  13. Link: https://docs.nvidia.com/datacenter/tesla/mig-user-guide/

  14. On-Prem GPU ROI Analysis

  15. Hardware cost (GPU servers, networking, cooling)
  16. Break-even point vs. cloud (typically 12-18 months)
  17. Operational costs (power, cooling, maintenance)
  18. Source type: Industry case studies (self-reported data, 3rd party reviews)
  19. Uncertainty: ROI depends on workload pattern (24/7 vs. bursty)

Hands-on Assignment (3-5 days): - Cost analysis spreadsheet: - Cloud GPU cost (1x A100 on-demand vs. spot, 1 year) - On-prem equivalent (DGX A100 server + TCO) - Break-even calculation - Test spot instance: AWS p3.2xlarge spot (check interruption rate) - Experiment: FP16 vs. FP32 inference (speed + cost impact) - Blog post: "GPU cost optimization - Cloud vs. on-prem analysis"

Checkpoint: - Can estimate cloud GPU costs (various pricing models) - Understand on-prem vs. cloud trade-offs - Aware of GPU utilization optimization techniques

Module 8: Advanced Kubernetes GPU Scheduling

Goal: Production-grade GPU scheduling (gang scheduling, bin-packing, autoscaling).

Learning Materials:

  1. Gang Scheduling (All-or-Nothing Scheduling)
  2. Distributed training jobs (multi-GPU/multi-node)
  3. Volcano scheduler (Kubernetes job queueing)
  4. PodGroup CRD (gang scheduling primitive)
  5. Source: Volcano Scheduler documentation

  6. Link: https://volcano.sh/en/docs/

  7. GPU Bin-Packing and Fragmentation

  8. Node fragmentation (1x 8-GPU node vs. 8x 1-GPU nodes)
  9. Bin-packing strategies (first-fit, best-fit)
  10. GPU topology awareness (NVLink, PCIe lanes)
  11. Source type: Research papers (Google Borg, Microsoft Singularity)

  12. Uncertainty: Production scheduler algorithms often proprietary

  13. Cluster Autoscaler GPU Support

  14. GKE/EKS/AKS GPU node pools
  15. Scale-up/scale-down policies (min/max nodes)
  16. Spot instance integration (autoscaling + spot = complex)
  17. Source: Kubernetes Cluster Autoscaler documentation
  18. Link: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

Hands-on Assignment (7-10 days): - Deploy Volcano scheduler on Kubernetes cluster - Test gang scheduling: 4-GPU distributed training job - Simulate node fragmentation: deploy jobs sub-optimally - Configure Cluster Autoscaler (GKE GPU node pool) - Test autoscaling: submit large batch jobs, watch nodes scale up - Blog post: "Advanced GPU scheduling - Volcano + Cluster Autoscaler"

Checkpoint: - Deployed Volcano scheduler - Understand gang scheduling use case - Can configure GPU cluster autoscaling

Module 9: Ray Serve and Ray Cluster

Goal: Understanding Ray framework (distributed computing + ML serving).

Learning Materials:

  1. Ray Core Basics
  2. Ray task and actor model
  3. Distributed computing primitives (@ray.remote)
  4. Ray cluster architecture (head node, worker nodes)
  5. Source: Ray documentation

  6. Link: https://docs.ray.io/en/latest/ray-core/walkthrough.html

  7. Ray Serve (ML Model Serving)

  8. Multi-model serving (1 cluster, N models)
  9. Autoscaling replicas (traffic-based)
  10. Ray Serve vs. vLLM (Ray Serve = general framework, vLLM = LLM-specific)
  11. Source: Ray Serve documentation

  12. Link: https://docs.ray.io/en/latest/serve/index.html

  13. KubeRay Operator

  14. Ray cluster Kubernetes deployment
  15. RayCluster CRD
  16. GPU resource allocation (heterogeneous GPU types)
  17. Source: KubeRay documentation
  18. Link: https://docs.ray.io/en/latest/cluster/kubernetes/index.html

Hands-on Assignment (7-10 days): - Deploy Ray cluster on Kubernetes (KubeRay operator) - Simple Ray task: distributed data processing (GPU-accelerated) - Deploy Ray Serve + simple model (BERT fine-tuned model) - Test autoscaling: load test Ray Serve endpoint - Compare: Ray Serve vs. Triton Inference Server (use case fit) - Blog post: "Ray Serve - Distributed ML serving on Kubernetes"

Checkpoint: - Deployed Ray cluster on Kubernetes - Ran Ray Serve for model serving - Understand Ray framework use case (vs. pure Kubernetes jobs)

Module 10: Production Case Study and Capstone Project

Goal: Building real production-like GPU infrastructure end-to-end.

Capstone Project Description:

Task: Build LLM serving infrastructure on Kubernetes (Llama-3-8B model).

Requirements: 1. Infrastructure: - Kubernetes cluster (GKE or EKS, 2x GPU nodes - A10G or L4) - NVIDIA GPU Operator installation - Prometheus + Grafana monitoring

  1. ML Serving:
  2. vLLM deployment (Llama-3-8B model)
  3. OpenAI-compatible API endpoint

  4. HorizontalPodAutoscaler (HPA) - based on CPU/GPU metrics

  5. Observability:

  6. GPU metrics (DCGM exporter)
  7. Latency/throughput metrics (Prometheus)

  8. Grafana dashboard (custom + pre-built)

  9. Cost Optimization:

  10. Spot instance usage (node pool)
  11. Cluster Autoscaler (scale-to-zero capable)

  12. Cost report (estimated $/month, $/request)

  13. Documentation:

  14. Architecture diagram (Kubernetes resources, data flow)
  15. Runbook (deployment, troubleshooting, scaling)
  16. Blog post series (3-5 posts, publish on Medium/Dev.to)

Timeline: 14-21 days

Success Criteria: - Working vLLM API endpoint (<2s latency, 95th percentile) - GPU utilization >60% (efficient resource use) - Autoscaling works (scale-up under load, scale-down after) - Documentation publication-ready (blog posts, GitHub repo)

Checkpoint: - Full end-to-end GPU infrastructure deployed - Blog posts published (LinkedIn share, portfolio) - GitHub repository public (resume/CV reference)

13 Practices: Hands-On Skill Development

Practice 1: Daily nvidia-smi Habit

  • What: Run nvidia-smi command daily, interpret output
  • Why: Develop GPU monitoring intuition
  • Time: 5 minutes/day
  • Tool: Terminal + NVIDIA GPU (cloud or local)

Practice 2: Weekly GPU Benchmark Runs

  • What: Weekly benchmarks on different GPUs (T4, A10G, A100)
  • Why: Understand hardware performance characteristics
  • Time: 1-2 hours/week
  • Tool: Cloud GPU instances (GCP, AWS free tier credits)

Practice 3: Model Serving Latency Optimization

  • What: vLLM or Triton latency tuning (batch size, precision)
  • Why: Production serving performance tuning skill
  • Time: 3-4 hours/week
  • Tool: vLLM + load testing tool (Locust, k6)

Practice 4: Kubernetes GPU Troubleshooting Scenarios

  • What: Simulated failure scenarios (GPU OOM, driver crash, pod eviction)
  • Why: Incident response preparation
  • Time: 2-3 hours/week
  • Tool: Kubernetes cluster + Chaos Engineering tools (Chaos Mesh)

Practice 5: GPU Cost Tracking Spreadsheet

  • What: Weekly GPU cost tracking (cloud spend, utilization)
  • Why: Cost awareness, optimization habit
  • Time: 30 minutes/week
  • Tool: Google Sheets + cloud billing API

Practice 6: Read GPU Performance Papers

  • What: Weekly 1 research paper on GPU optimization
  • Why: Learn cutting-edge techniques
  • Time: 2-3 hours/week
  • Sources: arXiv.org (cs.DC, cs.LG categories), NVIDIA Technical Blog

Practice 7: Contribute to Open-Source GPU Projects

  • What: Issue filing, documentation PR, small bug fix (vLLM, Triton, KubeRay)
  • Why: Community engagement, code review exposure
  • Time: 2-4 hours/week
  • Platform: GitHub (vLLM, NVIDIA Triton repos)

Practice 8: LinkedIn GPU Content Sharing

  • What: Weekly post: learning insight, benchmark result, tool comparison
  • Why: Personal brand building, network expansion
  • Time: 30 minutes/week
  • Platform: LinkedIn (tech hashtags: #GPUComputing, #MLOps, #Kubernetes)

Practice 9: Mock Interview Practice

  • What: Practice GPU infra interview questions (technical + behavioral)
  • Why: Interview readiness
  • Time: 1 hour/week
  • Format: Self-recorded video or peer mock interview

Practice 10: Architecture Review Sessions

  • What: Review existing GPU infra architectures (open-source, blog posts)
  • Why: Design pattern recognition, trade-off analysis skill
  • Time: 2 hours/week
  • Sources: Company engineering blogs (OpenAI, Anthropic, Cohere)

Practice 11: Failure Log Analysis

  • What: Collect GPU failure logs (OOM, CUDA errors), analyze root cause
  • Why: Debugging skill, common failure patterns knowledge
  • Time: 1-2 hours/week
  • Tool: Kubernetes logs, DCGM logs, application logs

Practice 12: GPU Tech News Curation

  • What: Weekly GPU tech news summary (new hardware, framework releases)
  • Why: Industry trend awareness
  • Time: 1 hour/week
  • Sources: NVIDIA Blog, The Register (HPC section), Hacker News

Practice 13: Certification Path Tracking

  • What: Track progress: NVIDIA DLI courses, CKA (Certified Kubernetes Administrator)
  • Why: Formal credentials (resume value)
  • Time: Variable (certification-dependent)
  • Platform: NVIDIA DLI, CNCF (Kubernetes certifications)

Source Hierarchy and Reliability

Primary Sources (Most Reliable)

  1. NVIDIA official documentation (CUDA, DCGM, GPU Operator, TensorRT)
  2. Kubernetes official documentation (Device Plugins, Scheduling)
  3. Cloud provider documentation (GCP, AWS, Azure GPU offerings)
  4. PyTorch/TensorFlow official tutorials (Distributed training)

Professional Analyses (High Reliability)

  1. NVIDIA Technical Blog - GPU performance optimization articles
  2. Google Research publications - TPU/GPU scheduling papers
  3. Microsoft Research - Azure ML infrastructure papers
  4. Meta Engineering Blog - PyTorch FSDP, distributed training

Community Sources (Medium Reliability)

  1. GitHub repositories (vLLM, Triton, KubeRay - code + issues + discussions)
  2. Reddit r/MachineLearning - Practitioner insights (consider bias)
  3. Hacker News - Industry discussions (multiple perspectives)
  4. Medium/Dev.to blog posts - Hands-on tutorials (verify claims)

Sources to Verify (Low Reliability)

  1. Marketing materials (vendor bias - NVIDIA vs. AMD vs. Intel)
  2. Anecdotal Reddit comments - Useful starting point, but verify!
  3. Outdated tutorials (GPU tech changes fast - check publish date)

Possible Biases and Uncertainties

Technological Biases

  • NVIDIA dominance: Curriculum is NVIDIA-centric (CUDA ecosystem)
  • Alternatives: AMD ROCm, Intel oneAPI (less mature, but exist)
  • Bias: NVIDIA marketing materials may influence objectivity

Cost Uncertainties

  • Cloud GPU pricing volatility: Spot instance prices fluctuate (supply/demand)
  • Mitigation: Always check current pricing, use cost calculators
  • On-prem ROI assumptions: TCO calculation depends on workload pattern
  • Uncertainty: 12-18 month break-even is speculation (no universal rule)

Learning Curve Uncertainties

  • 8-12 week estimate: Assumption of daily 3-4 hours intensive study
  • Variance: Depends on individual background (ML knowledge, Kubernetes experience)
  • Reality check: Production-ready skillset may take 6-12 months (part-time)

Practical Constraints

  • GPU access cost: Cloud GPU practice costs $200-500 (budget-dependent)
  • Alternative: Google Colab Pro ($10/month, limited GPU time)
  • Trade-off: Cheaper, but less production-like environment

Source Freshness

  • Rapid GPU tech evolution: 6-month-old tutorial may be outdated
  • Mitigation: Always check documentation publish date
  • Best practice: Official docs > blog posts (docs maintained, blogs static)

Next Steps (Using This Learning Plan)

  1. Assess commitment:
  2. Do you have 8-12 weeks for intensive learning?
  3. Do you have $200-500 budget for cloud GPU practice?

  4. If NO: Consider part-time schedule (3-6 months, daily 1-2 hours)

  5. Start with Module 1:

  6. Don't skip ahead (fundamentals are critical)

  7. Hands-on assignments are mandatory (passive reading ≠ skill)

  8. Track progress:

  9. Markdown checklist (checkbox after each module)

  10. Blog posts = public accountability

  11. Adjust as needed:

  12. If a module is too fast/slow → customize

  13. If a tech stack isn't relevant (e.g., Ray Serve) → skip or replace

  14. Portfolio building in parallel:

  15. GitHub repo for every capstone project
  16. LinkedIn posts at every milestone
  17. Goal: 3-6 months later, credible "GPU Infrastructure Engineer" profile