Map continuous values to discrete levels:
  x_quantized = round((x - x_min) / scale) * scale + zero_point

  scale = (x_max - x_min) / (2^b - 1)
  where b = number of bits

Example: FP16 weight = 0.3742
  INT8 range: [-128, 127], scale = (max-min)/255
  If max=1.0, min=-1.0: scale = 2/255 = 0.00784
  Quantized: round(0.3742 / 0.00784) = 48
  Dequantized: 48 × 0.00784 = 0.3763
  Error: |0.3742 - 0.3763| = 0.0021 (0.56% relative error)

Insight: 99.9% of weights are well-behaved, but 0.1% are "outliers"
with magnitudes 10-100× larger. Quantizing outliers causes catastrophic errors.

Solution (Dettmers et al., 2022):
  1. Identify outlier dimensions (magnitude > 6.0)
  2. Extract outlier columns → keep in FP16
  3. Quantize remaining 99.9% to INT8
  4. Compute: Y = X_int8 · W_int8 + X_fp16 · W_fp16

Memory: ~50% reduction (vs full INT8's 75%, but much better accuracy)

LLM    | FP16 Size | INT8 Size | LLM.int8() | Perplexity (FP16/int8)
-------|-----------|-----------|-----------|------------------------
7B     | 14 GB     | 7 GB      | 8.5 GB    | 5.68 / 5.70
13B    | 26 GB     | 13 GB     | 15.5 GB   | 5.21 / 5.23
70B    | 140 GB    | 70 GB     | 82 GB     | 3.12 / 3.15

GPTQ (Frantar et al., 2023) quantizes weights layer-by-layer,
compensating quantization error by adjusting remaining weights:

For each column j of weight matrix W:
  1. Quantize column j to INT4
  2. Compute quantization error: delta = W[:, j] - Q(W[:, j])
  3. Distribute error to remaining columns (j+1, j+2, ...):
     W[:, j+1:] -= delta × H_inv[j, j+1:] / H_inv[j, j]
     where H = X^T · X (Hessian of layer output)

Result: error from each column is "absorbed" by subsequent columns
  70B model: 140 GB → 35 GB (4-bit) with only 0.3% perplexity increase
  Runs on single A100 80GB or 2× RTX 4090 (48GB total)

Simplest approach: remove weights with smallest absolute value

def magnitude_prune(weight_matrix, sparsity=0.5):
    """Prune 50% of weights (set to zero)."""
    threshold = np.percentile(np.abs(weight_matrix), sparsity * 100)
    mask = np.abs(weight_matrix) >= threshold
    return weight_matrix * mask, mask

# For a 4096 × 4096 matrix (16.7M params):
#   50% pruning → 8.4M non-zero params
#   With sparse storage: ~50% memory reduction
#   With sparse matrix multiply: ~40% speedup (hardware dependent)

SparseGPT (Frantar & Alistarh, 2023):
  - Prunes 50-60% of weights in LLMs without ANY retraining
  - Uses same Hessian-based error compensation as GPTQ
  - Key result: Llama-2 70B at 50% sparsity loses only 0.5% on benchmarks

OWL (Outlier Weighed Layerwise) pruning:
  - Different sparsity per layer (attention layers less sparse than MLP)
  - Llama-2 7B at 70% overall sparsity: 2.1% accuracy loss vs uniform 70%: 8.3%

2:4 Structured Sparsity (NVIDIA):
  - Every group of 4 weights has exactly 2 zeros
  - Hardware-supported on A100/H100: 2× speedup with zero overhead
  - Built into cuSPARSELt library

Teacher: Large model (e.g., 70B) with logits z_T
Student: Small model (e.g., 7B) with logits z_S

Standard training loss:
  L_hard = CrossEntropy(softmax(z_S), y_true)

Distillation loss (Hinton et al., 2015):
  L_soft = KL_divergence(softmax(z_S / tau), softmax(z_T / tau))

  where tau = temperature (typically 2-5)
  Higher temperature → softer probability distribution → more information

Combined loss:
  L = alpha * L_hard + (1 - alpha) * tau^2 * L_soft

  alpha = 0.1-0.3 (mostly learn from teacher)
  tau^2 scaling: compensates for reduced gradient magnitude at high temperature

Teacher's prediction for "What is the capital of India?":
  Hard label: [Delhi: 1.0, Mumbai: 0.0, Kolkata: 0.0, ...]
  Soft label (tau=3): [Delhi: 0.72, Mumbai: 0.08, Kolkata: 0.06, Bangalore: 0.04, ...]

The soft labels encode "dark knowledge":
  - Mumbai is the most plausible incorrect answer (0.08 vs 0.06)
  - This tells the student about similarity structure between cities
  - Equivalent to many more training examples than hard labels alone

import torch
import torch.nn as nn
import torch.nn.functional as F

class DistillationTrainer:
    def __init__(self, teacher, student, temperature=4.0, alpha=0.2):
        self.teacher = teacher.eval()  # Freeze teacher
        self.student = student
        self.tau = temperature
        self.alpha = alpha
        self.optimizer = torch.optim.AdamW(student.parameters(), lr=2e-5)

    def distillation_loss(self, student_logits, teacher_logits, labels):
        """Combined hard + soft loss."""
        # Hard loss: student vs ground truth
        hard_loss = F.cross_entropy(student_logits, labels)

        # Soft loss: student distribution vs teacher distribution
        student_soft = F.log_softmax(student_logits / self.tau, dim=-1)
        teacher_soft = F.softmax(teacher_logits / self.tau, dim=-1)
        soft_loss = F.kl_div(student_soft, teacher_soft, reduction='batchmean')

        # Combined (tau^2 scales the gradient)
        loss = self.alpha * hard_loss + (1 - self.alpha) * (self.tau ** 2) * soft_loss
        return loss

    def train_step(self, input_ids, labels):
        # Teacher inference (no gradient)
        with torch.no_grad():
            teacher_logits = self.teacher(input_ids).logits

        # Student forward + backward
        student_logits = self.student(input_ids).logits
        loss = self.distillation_loss(student_logits, teacher_logits, labels)

        self.optimizer.zero_grad()
        loss.backward()
        self.optimizer.step()

        return loss.item()

# Distillation results (typical):
# Teacher (70B) → Student (7B): retains 90% of MMLU, 85% of code generation
# Teacher (7B) → Student (1.5B): retains 82% of MMLU, 70% of code generation
# Cost: 10% of pre-training compute for 80-90% of capability

Optimal compression pipeline for deployment:

Step 1: Distillation (70B → 7B)
  - Student retains 90% capability
  - 10× parameter reduction

Step 2: LoRA fine-tuning on domain data
  - Recovers domain-specific performance
  - Only 13M additional parameters

Step 3: GPTQ quantization (FP16 → INT4)
  - 7B model: 14 GB → 3.5 GB
  - 0.3% perplexity increase

Step 4: 2:4 structured pruning
  - 50% weight sparsity → 2× inference speedup on A100
  - 0.5% accuracy loss

Final result:
  Original 70B FP16: 140 GB, 100 tokens/sec on 4×A100
  Compressed 7B INT4 sparse: 2.1 GB, 800 tokens/sec on 1×RTX 4090
  Ratio: 67× smaller, 8× faster, ~85% of original capability

Engineering Perspective: Parameter-Efficient Tuning and Model Compression

When you sit for a technical interview at any top company — whether it is Google, Microsoft, Amazon, or an Indian unicorn like Zerodha, Razorpay, or Meesho — they are not just testing whether you know the definition of parameter-efficient tuning and model compression. They are testing whether you can APPLY these concepts to solve novel problems, whether you understand the TRADEOFFS involved, and whether you can reason about system behaviour at scale.

This chapter approaches parameter-efficient tuning and model compression with that depth. We will examine not just what it is, but why it works the way it does, what alternatives exist and when to choose each one, and how real systems use these ideas in production. ISRO's mission control systems, India's UPI payment network handling 10 billion transactions per month, Aadhaar's biometric authentication serving 1.4 billion identities — all rely on the principles we discuss here.

ML Pipeline: From Raw Data to Production Model

At the advanced level, machine learning is not just about algorithms — it is about building robust pipelines that handle real-world messiness. Here is a production-grade ML pipeline pattern used at companies like Flipkart and Razorpay:

# Production ML Pipeline Pattern
import numpy as np
from sklearn.model_selection import cross_val_score
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler

def build_ml_pipeline(model, X_train, y_train, X_test):
    """
    A standard ML pipeline with validation.
    Works for classification, regression, or clustering.
    """
    # Step 1: Create pipeline (preprocessing + model)
    pipe = Pipeline([
        ('scaler', StandardScaler()),
        ('model', model)
    ])

    # Step 2: Cross-validation (5-fold) — prevents overfitting
    cv_scores = cross_val_score(pipe, X_train, y_train, cv=5)
    print(f"CV Score: {cv_scores.mean():.4f} ± {cv_scores.std():.4f}")

    # Step 3: Train on full training set
    pipe.fit(X_train, y_train)

    # Step 4: Evaluate on held-out test set
    test_score = pipe.score(X_test, y_test)
    print(f"Test Score: {test_score:.4f}")
    return pipe

The key insight is that preprocessing, training, and evaluation should always be encapsulated in a pipeline — this prevents data leakage (where test data information leaks into training). Cross-validation gives you a reliable estimate of model performance. The ± value tells you how stable your model is across different data splits.

In Indian tech, these patterns power recommendation engines at Flipkart, fraud detection at Razorpay, demand forecasting at Swiggy, and credit scoring at startups like CRED and Slice. IIT and IISc researchers are pushing boundaries in areas like fairness-aware ML, efficient inference for mobile (important for India's smartphone-first population), and domain adaptation for Indian languages.

India's Scale Challenges: Engineering for 1.4 Billion

Building technology for India presents unique engineering challenges that make it one of the most interesting markets in the world. UPI handles 10 billion transactions per month — more than all credit card transactions in the US combined. Aadhaar authenticates 100 million identities daily. Jio's network serves 400 million subscribers across 22 telecom circles. Hotstar streamed IPL to 50 million concurrent viewers — a world record. Each of these systems must handle India's diversity: 22 official languages, 28 states with different regulations, massive urban-rural connectivity gaps, and price-sensitive users expecting everything to work on ₹7,000 smartphones over patchy 4G connections. This is why Indian engineers are globally respected — if you can build systems that work in India, they will work anywhere.

Advanced Algorithms: Dynamic Programming and Graph Theory

Dynamic Programming (DP) solves complex problems by breaking them into overlapping subproblems. This is a favourite in competitive programming and interviews:

# Longest Common Subsequence — classic DP problem
# Used in: diff tools, DNA sequence alignment, version control

def lcs(s1, s2):
    m, n = len(s1), len(s2)
    dp = [[0] * (n + 1) for _ in range(m + 1)]

    for i in range(1, m + 1):
        for j in range(1, n + 1):
            if s1[i-1] == s2[j-1]:
                dp[i][j] = dp[i-1][j-1] + 1
            else:
                dp[i][j] = max(dp[i-1][j], dp[i][j-1])

    return dp[m][n]

# Dijkstra's Shortest Path — used by Google Maps!
import heapq

def dijkstra(graph, start):
    dist = {node: float('inf') for node in graph}
    dist[start] = 0
    pq = [(0, start)]  # (distance, node)

    while pq:
        d, u = heapq.heappop(pq)
        if d > dist[u]:
            continue
        for v, weight in graph[u]:
            if dist[u] + weight < dist[v]:
                dist[v] = dist[u] + weight
                heapq.heappush(pq, (dist[v], v))

    return dist

# Real use: Google Maps finding shortest route from
# Connaught Place to India Gate, considering traffic weights

Dijkstra's algorithm is how mapping applications find optimal routes. When you ask Google Maps to navigate from Mumbai to Pune, it models the road network as a weighted graph (intersections are nodes, roads are edges, travel time is weight) and runs a variant of Dijkstra's algorithm. Indian highways, city roads, and even railway networks can all be modelled this way. IRCTC's route optimisation for trains across 13,000+ stations uses graph algorithms at its core.

Research Frontiers and Open Problems in Parameter-Efficient Tuning and Model Compression

Beyond production engineering, parameter-efficient tuning and model compression connects to active research frontiers where fundamental questions remain open. These are problems where your generation of computer scientists will make breakthroughs.

Quantum computing threatens to upend many of our assumptions. Shor's algorithm can factor large numbers efficiently on a quantum computer, which would break RSA encryption — the foundation of internet security. Post-quantum cryptography is an active research area, with NIST standardising new algorithms (CRYSTALS-Kyber, CRYSTALS-Dilithium) that resist quantum attacks. Indian researchers at IISER, IISc, and TIFR are contributing to both quantum computing hardware and post-quantum cryptographic algorithms.

AI safety and alignment is another frontier with direct connections to parameter-efficient tuning and model compression. As AI systems become more capable, ensuring they behave as intended becomes critical. This involves formal verification (mathematically proving system properties), interpretability (understanding WHY a model makes certain decisions), and robustness (ensuring models do not fail catastrophically on edge cases). The Alignment Research Center and organisations like Anthropic are working on these problems, and Indian researchers are increasingly contributing.

Edge computing and the Internet of Things present new challenges: billions of devices with limited compute and connectivity. India's smart city initiatives and agricultural IoT deployments (soil sensors, weather stations, drone imaging) require algorithms that work with intermittent connectivity, limited battery, and constrained memory. This is fundamentally different from cloud computing and requires rethinking many assumptions.

Finally, the ethical dimensions: facial recognition in public spaces (deployed in several Indian cities), algorithmic bias in loan approvals and hiring, deepfakes in political campaigns, and data sovereignty questions about where Indian citizens' data should be stored. These are not just technical problems — they require CS expertise combined with ethics, law, and social science. The best engineers of the future will be those who understand both the technical implementation AND the societal implications. Your study of parameter-efficient tuning and model compression is one step on that path.

Key Vocabulary

Here are important terms from this chapter that you should know:

🏗️ Architecture Challenge

Design the backend for India's election results system. Requirements: 10 lakh (1 million) polling booths reporting simultaneously, results must be accurate (no double-counting), real-time aggregation at constituency and state levels, public dashboard handling 100 million concurrent users, and complete audit trail. Consider: How do you ensure exactly-once delivery of results? (idempotency keys) How do you aggregate in real-time? (stream processing with Apache Flink) How do you serve 100M users? (CDN + read replicas + edge computing) How do you prevent tampering? (digital signatures + blockchain audit log) This is the kind of system design problem that separates senior engineers from staff engineers.

The Frontier

You now have a deep understanding of parameter-efficient tuning and model compression — deep enough to apply it in production systems, discuss tradeoffs in system design interviews, and build upon it for research or entrepreneurship. But technology never stands still. The concepts in this chapter will evolve: quantum computing may change our assumptions about complexity, new architectures may replace current paradigms, and AI may automate parts of what engineers do today.

What will NOT change is the ability to think clearly about complex systems, to reason about tradeoffs, to learn quickly and adapt. These meta-skills are what truly matter. India's position in global technology is only growing stronger — from the India Stack to ISRO to the startup ecosystem to open-source contributions. You are part of this story. What you build next is up to you.

Crafted for Class 10–12 • LLM Engineering • Aligned with NEP 2020 & CBSE Curriculum