Deploying large language models into production environments introduces a distinct set of operational hurdles compared to traditional machine learning models. While training focuses on optimizing learning over vast datasets and compute clusters, serving shifts the focus to real-time performance, resource efficiency, and cost management under live traffic. The sheer size and computational intensity of LLMs amplify challenges that might be minor inconveniences for smaller models. Understanding these specific difficulties is fundamental to designing effective deployment strategies.

Memory Footprint

Perhaps the most immediate challenge is the enormous size of LLMs. Models with tens or hundreds of billions of parameters require significant amounts of memory simply to hold the model weights.

GPU VRAM Requirements: A model like Llama 2 70B, using 16-bit precision (FP16 or BF16), requires roughly $70 \times 2 = 140$ GB of GPU memory (VRAM) just for the weights. This often exceeds the capacity of even high-end single GPUs (like NVIDIA A100 80GB or H100 80GB), necessitating multi-GPU configurations or specialized hardware even for inference. Loading these weights from storage into GPU memory can also introduce significant startup latency for the inference server.
Activation Caches (KV Cache): During autoregressive generation, where each new token depends on previously generated tokens, intermediate state known as the Key-Value (KV) cache must be stored. This cache includes attention keys and values for each layer and grows linearly with the sequence length (context + generated tokens) and the batch size. For long contexts or large batches, the KV cache can consume tens or even hundreds of gigabytes, potentially demanding as much or more VRAM than the model weights themselves. This dynamic memory requirement further complicates resource allocation and can become a primary bottleneck.

The autoregressive generation process for LLMs. Each step uses the previous context (partially stored in the growing KV cache) to generate the next token. The KV cache size increases with each generated token, consuming significant memory.

Computational Cost and Latency

Generating text with an LLM is computationally intensive. Each token generated requires a full forward pass through the model's parameters, involving billions or trillions of floating-point operations (FLOPs).

High FLOPs per Token: The computational cost scales significantly with model size. This translates directly into processing time on the hardware (GPUs/TPUs). Even with powerful accelerators, generating tokens takes non-trivial time.
Sequential Generation Latency: Since each token typically depends on the previous ones, generation is largely sequential. While processing the input prompt (prefill phase) can often be parallelized across tokens, generating the output sequence of length $N$ (decoding phase) typically requires $N$ sequential forward passes through the model. This fundamentally limits the minimum achievable latency for generating a complete response. The time-to-first-token might be relatively quick after the prompt processing, but the time-to-last-token (total generation time) increases linearly with the desired output length. Many interactive applications (like chatbots) are highly sensitive to this perceived latency.
Latency vs. Throughput Trade-off: Optimizing for the lowest possible latency for a single request (e.g., using a batch size of 1) often leads to poor hardware utilization, as modern GPUs are designed for massive parallelism. This results in low overall throughput (total tokens generated per second across all concurrent requests) and high cost per token. Conversely, maximizing throughput usually involves processing requests in large batches. While this improves hardware utilization and reduces cost, it increases the latency for individual requests as they may need to wait for a batch to fill or for other requests in the batch to complete. Effectively balancing this trade-off is a central problem in LLM serving.

Throughput and Concurrency

Serving systems must handle potentially many concurrent users efficiently. Achieving high throughput is essential for supporting a large user base cost-effectively.

Batching Complexity: Simple static batching (waiting for a fixed number of requests before processing) introduces significant delays. Dynamic batching strategies aim to group incoming requests more flexibly. However, the variability in input and output lengths across requests makes efficient batching non-trivial. Advanced techniques like continuous batching or paged attention are often required to pack computation effectively and manage the KV cache efficiently for concurrent requests with different sequence lengths.
Resource Allocation and Scheduling: Efficiently scheduling diverse requests (some requiring short responses, others long) across available GPU resources, potentially spanning multiple nodes, requires sophisticated request schedulers and resource management. The goal is to maximize utilization while meeting Service Level Objectives (SLOs) for latency and availability.

Cost Management

The specialized hardware required for LLM serving (typically high-end GPUs with substantial VRAM and memory bandwidth) represents a significant capital or operational expense.

High Infrastructure Cost: GPUs like NVIDIA's H100 or A100 are expensive, and running them continuously incurs substantial costs for energy, cooling, and cloud instance hours.
Cost Efficiency Pressure: Because of the high baseline cost, achieving high hardware utilization is not merely a performance goal but an economic necessity. Every underutilized GPU cycle represents wasted expenditure. This drives the need for aggressive optimization through efficient serving engines, model compression techniques (like quantization), and intelligent autoscaling.

These interconnected challenges related to memory constraints, computational demands, latency expectations, throughput requirements, and operational costs necessitate the specialized deployment and optimization techniques discussed throughout this chapter. Successfully navigating these difficulties is essential for building performant, scalable, and economically viable applications powered by large language models.