Private corporate batches, live online cohorts and 1-on-1 mentoring in neural network architectures, training mechanics, transformers and fine-tuning at GPU scale — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Deep Learning from the mechanics outward: autograd and backpropagation implemented before any framework abstraction, then the training controls that decide convergence — initialisation, optimisers, schedules, normalisation and regularisation — and finally scale. Sessions treat GPU memory arithmetic, mixed precision, gradient checkpointing, DDP and FSDP, LoRA fine-tuning, and inference-time quantisation and batching as first-class content, because those are what determine whether a network can actually be trained and served on the hardware a team has.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Deep Learning that means a trainer who has run it in production — neural network architectures, training mechanics, transformers and fine-tuning at GPU scale — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Deep Learning batchDeep Learning is the branch of machine learning that stacks many layers of learned transformations so a model discovers its own representation of the input instead of relying on features an engineer designed. A network is a chain of linear maps and non-linearities; a loss measures its error; automatic differentiation propagates that error backwards through every parameter; and an optimiser adjusts them. Everything from an image classifier to a language model is that same loop repeated at different scales with different architectural priors.
The architecture encodes an assumption about the data. Convolutional networks assume locality and translation invariance, which is why they suit images. Recurrent networks assume sequential dependence, and were bounded by it. Transformers replaced recurrence with self-attention, letting every position attend to every other in parallel, which is what made training on very large corpora practical and produced the current generation of language and multimodal models. Choosing an architecture is choosing the inductive bias you want.
In practice Deep Learning is a systems discipline as much as a modelling one. Whether a network converges depends on initialisation, normalisation, learning-rate schedule, optimiser and regularisation. Whether it can be trained at all depends on GPU memory arithmetic — parameters, gradients, optimiser states and activations — and the techniques that stretch it: mixed precision, gradient checkpointing, accumulation, and distributed strategies such as DDP, ZeRO and FSDP. Whether it can be served depends on quantisation, distillation, export and batching. Most teams now fine-tune pretrained models with parameter-efficient methods such as LoRA rather than training from scratch, which makes those systems concerns the everyday work.
Deep learning stopped being a research speciality and became infrastructure. The models behind search, recommendation, speech, vision, fraud detection and every generative product are neural networks, and the teams running them are increasingly ordinary engineering teams rather than research groups.
The practical need has shifted with that. Very few organisations pretrain a model; almost all of them adapt one. That makes the valuable skills specific and unglamorous: understanding what a transformer actually computes so its context and cost behaviour make sense, fitting a fine-tune into the GPU memory you can afford, choosing between full fine-tuning and LoRA, knowing why a training run diverged at step 4,000, and cutting inference cost through quantisation and batching without destroying quality.
GPU capacity is expensive and usually constrained, which puts a direct commercial value on this knowledge. An engineer who can reduce a training run from eight GPUs to two, or halve serving cost by quantising and batching correctly, pays for the training many times over. That is why deep learning skills now appear in platform and infrastructure job specifications and not only in data science ones.
The mechanics, built before any framework hides them. A neuron, a layer, activation functions and what each one does to gradients, loss functions for regression and classification, then the chain rule applied backwards through a network — first by hand on paper, then in NumPy, then as PyTorch autograd.
Topics: Neurons, layers and the forward pass · Activation functions: sigmoid, tanh, ReLU, GELU, softmax · Loss functions: MSE, cross-entropy and when each applies · The chain rule and backpropagation derived · Computation graphs and automatic differentiation · A network from scratch in NumPy · The same network in PyTorch: tensors, autograd, modules · Datasets, DataLoaders and the training loop · Reading a loss curve
The controls that separate a network that trains from one that does not. Initialisation schemes and why they matter, the optimiser family from SGD to AdamW, learning-rate schedules and warmup, normalisation layers, regularisation, and the gradient pathologies that produce a flat or exploding loss.
Topics: Initialisation: Xavier, He and why defaults matter · SGD, momentum, RMSProp, Adam and AdamW · Learning-rate schedules, warmup and cosine decay · Batch size effects and the LR-batch relationship · Batch, layer and group normalisation · Dropout, weight decay and early stopping · Gradient clipping, vanishing and exploding gradients · Mixed-precision training and numerical stability · Hyperparameter search for neural networks · Debugging: overfit one batch first
The architecture family that made deep learning practical. Convolution, stride, padding and pooling; receptive fields; the progression from LeNet through VGG to ResNet and beyond, and what residual connections solved. Then the workflow most teams actually use: transfer learning with augmentation.
Topics: Convolution, kernels, stride and padding · Pooling, receptive fields and feature hierarchies · LeNet, AlexNet, VGG and the depth problem · ResNet and residual connections · Inception, DenseNet and EfficientNet ideas · Data augmentation strategies and their effect · Transfer learning, layer freezing and discriminative learning rates · Detection and segmentation heads · Vision transformers positioned against CNNs
How networks handled ordered data before transformers, and why they were replaced. Recurrent networks and backpropagation through time, gating in LSTM and GRU, sequence-to-sequence models and the fixed-vector bottleneck that attention was invented to remove. Plus embeddings, which the rest of the course depends on.
Topics: Recurrent networks and backpropagation through time · Vanishing gradients over long sequences · LSTM and GRU gating · Bidirectional and stacked recurrent layers · Sequence-to-sequence encoders and decoders · The fixed-context bottleneck · Attention as a solution, before transformers · Word and sentence embeddings · Where recurrent models are still the right choice
The architecture behind current language and multimodal models, taken apart. Scaled dot-product attention and its cost, multi-head attention, positional encoding schemes, encoder and decoder stacks, masking, and the pretraining objectives that produce a usable base model. Then the practical consequences: tokenisation, context length and the KV cache.
Topics: Scaled dot-product self-attention · Multi-head attention and what heads specialise in · Positional encodings: sinusoidal, learned and rotary · Encoder, decoder and encoder-decoder stacks · Causal masking and padding masks · Feed-forward blocks, residuals and layer norm placement · Pretraining objectives: masked and autoregressive · Tokenisation and vocabulary effects · Context length, quadratic cost and attention variants · The KV cache and why generation is memory-bound
The systems half. Working out GPU memory from first principles, then every technique that buys headroom — accumulation, checkpointing, mixed precision, offload — and the distributed strategies that split work or state across devices. Then parameter-efficient fine-tuning, which is how most teams adapt a model in practice.
Topics: GPU memory arithmetic: parameters, gradients, optimiser states, activations · Gradient accumulation and effective batch size · Gradient checkpointing and the compute-memory trade · Mixed precision: fp16, bf16 and loss scaling · Data parallel vs DistributedDataParallel · ZeRO stages and FSDP sharding · Tensor, pipeline and sequence parallelism in outline · Full fine-tuning vs LoRA and QLoRA · Instruction tuning and dataset construction · Checkpointing, resumption and fault tolerance · Throughput profiling and GPU utilisation
The generative families and then the cost side of running any of them. Autoencoders and VAEs, GANs and their training instability, diffusion and the denoising formulation. Then serving: quantisation, distillation, pruning, export and the batching decisions that dominate throughput and cost.
Topics: Autoencoders and variational autoencoders · GANs, adversarial training and mode collapse · Diffusion models and the denoising objective · Sampling strategies and controllability · Post-training quantisation and quantisation-aware training · Knowledge distillation and pruning · Export to ONNX and runtime compilation · Dynamic and continuous batching for throughput · Latency, throughput and cost per thousand requests · Measuring quality loss from every optimisation
We rebuild the agenda around the tools you actually run.
Request a custom agendaImplement forward and backward passes in NumPy, verify gradients numerically, then rebuild the same network in PyTorch and confirm they agree.
Take a training job that produces NaNs, work through initialisation, learning rate, normalisation, clipping and precision until it trains stably.
Fine-tune a pretrained backbone on a few thousand images, ablate augmentation and layer freezing, and beat a from-scratch baseline convincingly.
Implement scaled dot-product and multi-head attention, assemble a transformer block, and train a small model on a corpus you can inspect by hand.
Compute the memory requirement, then apply accumulation, checkpointing, mixed precision and LoRA until a too-large fine-tune runs on the GPU you have.
Quantise, export and batch a trained model to meet a stated latency and cost target, with the quality loss at each step measured rather than assumed.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.