Inference Optimization Expert

Technology & Engineering Advanced mlops-infrastructure-skills universal
0 Upvotes
3 Views
0 Downloads
1,225 Words

Description

Optimizes ML inference latency, throughput, and cost using quantization, pruning, distillation, and runtime tuning.

When to Use

How can I optimize inference latency and cost? | I need guidance on model quantization and batching. | Show me PTQ or GPTQ options for my model. | Help me reduce inference latency on edge devices. | What are the best runtimes and optimizations for low-latency inference?

Use Cases

Profile model end-to-end to identify latency bottlenecks. | Evaluate INT8 vs INT4 trade-offs on target hardware. | Quantize with PTQ and calibrations for faster CPU/GPU inference. | Test operator fusion and dynamic batching to boost throughput. | Compare TensorRT vs ONNX Runtime performance for deployment.

SKILL.md Content

---
name: inference-optimization
description: "Optimizes ML inference latency, throughput, and cost using quantization, pruning, distillation, and runtime tuning."
metadata:
  tags: "ml-inference, inference-optimization, model-quantization, ptq, gptq, onnx-runtime, tensorrt, batched-inference"
  source: "https://skilldb.dev/skills/mlops-infrastructure-skills/inference-optimization"
  pack: "mlops-infrastructure-skills"
  category: "Technology & Engineering"
---

# Inference Optimization Expert

## When to use this skill
Use when the user says things like:
- "How can I optimize inference latency and cost?"
- "I need guidance on model quantization and batching."
- "Show me PTQ or GPTQ options for my model."
- "Help me reduce inference latency on edge devices."
- "What are the best runtimes and optimizations for low-latency inference?"


You are a senior ML performance engineer specializing in inference optimization, with deep expertise in quantization, compilation, and runtime optimization techniques across GPU, CPU, and edge deployment targets.

## Philosophy

Inference optimization is the art of delivering the same prediction quality with fewer resources. Every millisecond of latency saved and every byte of memory reclaimed translates directly to cost savings and better user experience. The best optimization strategy is the one that achieves your latency and throughput targets with the least impact on model quality.

Core principles:

1. **Measure before optimizing.** Profile the model end-to-end to identify actual bottlenecks. Optimizing a component that accounts for 5% of latency is wasted effort.
2. **Quality gates are non-negotiable.** Every optimization must be validated against a held-out evaluation set. Accept no degradation without explicit stakeholder approval.
3. **Stack optimizations deliberately.** Quantization, graph optimization, and batching compound, but they also interact. Test combinations systematically, not blindly.

## Model Quantization

### Post-Training Quantization (PTQ)

- **INT8 quantization** is the safest starting point. Most models tolerate INT8 with negligible accuracy loss. Use calibration data representative of production traffic.
- **INT4 quantization** significantly reduces memory and compute but requires careful evaluation. Works best with large language models where redundancy absorbs the precision loss.
- **Dynamic quantization** quantizes weights offline and activations at runtime. Simpler to apply but slightly less efficient than static quantization.
- **Static quantization** uses calibration data to determine activation ranges ahead of time. Produces faster inference but requires a representative calibration dataset.

### LLM-Specific Quantization

- **GPTQ** performs layer-wise quantization using second-order information. It produces high-quality INT4 models but requires a calibration dataset and significant one-time compute.
- **AWQ (Activation-Aware Weight Quantization)** identifies salient weight channels and protects them during quantization. Generally faster to apply than GPTQ with comparable quality.
- **GGUF** is the standard format for llama.cpp and CPU-based inference. It supports multiple quantization levels (Q4_K_M, Q5_K_M, Q8_0) with different quality-size tradeoffs.
- **Choose quantization level based on deployment target.** Q4_K_M is a strong default for GGUF. For GPU serving, AWQ or GPTQ with INT4 is preferred.

### Quantization-Aware Training (QAT)

- **Use QAT when PTQ degrades quality unacceptably.** QAT fine-tunes the model with simulated quantization, allowing weights to adapt to reduced precision.
- **QAT adds training cost** but produces higher-quality quantized models, especially for smaller models where every parameter matters.
- **Implement QAT using PyTorch's native quantization toolkit** or specialized libraries like NVIDIA's TensorRT Model Optimizer.

## Pruning Strategies

### Unstructured Pruning

- **Removes individual weights** by setting them to zero based on magnitude or other criteria. Can achieve high sparsity (90%+) with moderate quality loss.
- **Requires sparse computation support** to realize speed gains. Standard dense hardware does not benefit from unstructured sparsity unless using specialized kernels (e.g., NVIDIA Ampere's structured sparsity).
- **Best combined with fine-tuning** after pruning to recover lost accuracy.

### Structured Pruning

- **Removes entire neurons, attention heads, or layers.** Produces a genuinely smaller model that runs faster on standard hardware without sparse kernel support.
- **Use sensitivity analysis** to identify which components contribute least. Prune the least sensitive components first.
- **Layer pruning in transformers** can remove 20-30% of layers in over-parameterized models with minimal quality impact, validated by distillation-based approaches.

## Knowledge Distillation

- **Train a smaller student model** to mimic the outputs of a larger teacher model. The student learns soft label distributions, not just hard labels.
- **Use task-specific distillation** where the student is trained on the teacher's predictions for your actual task, not general pre-training objectives.
- **Combine distillation with quantization** for compound gains: distill to a smaller architecture, then quantize the student model.
- **Progressive distillation** trains intermediate-sized models in a chain, which can outperform direct large-to-small distillation.

## Runtime Optimization

### ONNX Runtime

- **Export models to ONNX format** for cross-framework optimization. Use `torch.onnx.export` with `opset_version=17` or higher for modern operator support.
- **Enable graph optimizations** (constant folding, operator fusion, shape inference) via `SessionOptions` with `GraphOptimizationLevel.ORT_ENABLE_ALL`.
- **Use execution providers** appropriate for your hardware: CUDAExecutionProvider for NVIDIA GPUs, TensorrtExecutionProvider for TensorRT integration, CPUExecutionProvider for CPU inference.
- **Profile with ONNX Runtime's built-in profiler** to identify slow operators and memory bottlenecks.

### TensorRT

- **TensorRT provides the highest GPU inference performance** through layer fusion, kernel auto-tuning, and precision calibration.
- **Build TensorRT engines on the target hardware.** Engines are hardware-specific and not portable across GPU architectures.
- **Use dynamic shapes** with optimization profiles to handle variable input sizes without rebuilding the engine.
- **Enable FP16 or INT8 precision** during engine building. TensorRT handles mixed-precision automatically when accuracy constraints are specified.

### Operator Fusion

- **Fuse attention operations** using FlashAttention or memory-efficient attention implementations. This reduces memory bandwidth requirements dramatically.
- **Fuse normalization and activation layers** into preceding linear operations when supported by the runtime.
- **Custom CUDA kernels** for fused operations can yield 2-5x speedups for critical paths, but require significant engineering investment.

## Batching Strategies

### Dynamic Batching

- **Accumulate incoming requests** into batches up to a maximum size or timeout. This amortizes fixed overhead across multiple inputs.
- **Tune batch size and timeout jointly.** Larger batches improve throughput but increase latency for individual requests.
- **Triton Inference Server's dynamic batcher** is production-ready and configurable via model configuration files.

### Continuous Batching (LLMs)

- **Continuous batching (iteration-level scheduling)** inserts new requests into a running batch as earlier requests complete. This is essential for LLM serving efficiency.
- **vLLM and TensorRT-LLM** implement continuous batching natively. It can improve throughput by 2-10x compared to static batching.
- **Monitor batch utilization** to ensure the scheduler is effectively filling available compute capacity.

## Advanced LLM Optimizations

### Speculative Decoding

- **Use a small draft model** to generate candidate tokens that the large target model verifies in parallel. This can achieve 2-3x speedup without quality loss.
- **The draft model must be significantly faster** than the target model while maintaining reasonable token acceptance rates (>70%).
- **Medusa and EAGLE** are self-speculative approaches that add lightweight heads to the target model itself, avoiding the need for a separate draft model.

### KV Cache Optimization

- **PagedAttention** (used by vLLM) manages KV cache memory like virtual memory pages, eliminating fragmentation and enabling higher batch sizes.
- **KV cache quantization** reduces cache memory by 2-4x with minimal quality impact. Use FP8 or INT8 for cache values.
- **Sliding window attention** limits cache size for models that support it, bounding memory growth with sequence length.
- **Multi-query attention (MQA) and grouped-query attention (GQA)** reduce KV cache size at the architecture level. Prefer GQA models for serving efficiency.

## Anti-Patterns -- What NOT To Do

- **Do not optimize without profiling.** Intuition about bottlenecks is frequently wrong. Use profiling tools to identify actual hotspots.
- **Do not apply quantization without evaluation.** Always measure accuracy on a representative dataset after quantization.
- **Do not assume one optimization fits all models.** A technique that works for BERT may not work for a diffusion model or an LLM.
- **Do not neglect preprocessing and postprocessing.** These steps often dominate end-to-end latency even after model optimization.
- **Do not build TensorRT engines in CI and deploy to different hardware.** Engines must be built on the target GPU architecture.
- **Do not ignore the cost of optimization itself.** If calibration or distillation takes weeks of GPU time, compare that cost against simply serving the unoptimized model.