LLM Inference Notes

VRAM planning for LLMs is not just about model weights. Long context windows can make the KV cache as expensive as the model itself.

A small model can still need a large GPU once you account for KV cache at long context length.

Bigger GPUs help, but fast LLM serving is mostly a scheduling and KV cache problem. PagedAttention, block allocation, batching, and prefix caching decide how much useful work fits in memory.

The serving loop is constantly asking which requests can run, how many tokens fit, and whether there is enough KV cache memory.

If language models can be compiled directly into silicon, inference stops looking like software running on a GPU and starts looking like the computer itself.

The next serving bottleneck may not be bigger GPUs. It may be whether the model is still software at all.

Analytical databases like BigQuery and Redshift are fast because they stop pretending every query needs every field. They read columns, compress patterns, and skip the bytes your question never asked for.

If your query asks for average transaction value, a row database may drag every field through memory. A columnar database can go straight to the one column that matters.

Before KRaft, Kafka used ZooKeeper as its coordination layer: broker membership, controller election, topic metadata, partition leaders, and ISR state all needed a consistent place to live.

ZooKeeper was not just extra infrastructure. It was the consensus-backed metadata brain that kept Kafka brokers from disagreeing about cluster state.

Speculative decoding speeds up LLM inference by letting a cheap draft model guess several tokens, then asking the expensive target model to verify those guesses in one parallel pass.

The trick is not making the large model smaller. It is making each expensive target-model pass confirm more than one token when the draft model guessed correctly.

Before transformers, KV cache, and GPU serving, language models had a smaller job: look at context and predict what text should come next.

The core language-modeling problem is prediction. Given the text so far, estimate the next likely token, then repeat.

Transformers were not the first attempt to model language. They arrived after rules, n-grams, recurrent networks, LSTMs, seq2seq models, and attention exposed the same bottleneck: sequence processing was too slow and too forgetful.

Before transformers, language systems moved from hand-written rules to statistical counts, then to neural models that read text one step at a time.

N-gram models were useful because they turned language into counts. They failed because a fixed local window cannot remember distant context, understand meaning, or generalize well to unseen phrases.

An n-gram model predicts from nearby words. That makes it simple, but the same simplicity creates sparsity, short memory, and brittle predictions.

RNNs improved on local n-gram counting by carrying a hidden state through the text. The tradeoff was dependency: token 10 cannot be processed until token 9 has updated the state.

A recurrent neural network reads text step by step, updating a hidden state after every token. That gives it memory, but also makes the sequence hard to parallelize.

Plain RNNs rewrote one hidden state at every step. LSTMs added gates and a cell state, giving the model a cleaner path for preserving useful information over longer spans.

An LSTM is still recurrent, but it controls memory more deliberately. Gates decide what to forget, what to write, and what to expose.

RNNs and LSTMs gave language models memory, but that memory still had to pass through one step after another. Long context made useful clues fade, compete, and arrive too slowly.

Sequence models struggled with long context because old information had to survive many updates inside a small running state.

Attention changed the sequence-model bottleneck. Instead of forcing every old clue through one running state, it let the model look back and score which earlier tokens mattered now.

Attention helped sequence models use distant context by letting the current step look back at relevant earlier tokens.

Self-attention is attention applied inside one sequence. Each token builds a better representation by comparing itself with the other tokens in the same input.

Self-attention lets tokens in the same sentence look at each other, score what matters, and mix useful context into each token representation.

Redis, Flink, databases, and Bloom filters can all remove duplicates, but they are not interchangeable. The right choice depends on where the duplicate appears, how long you must remember it, and what happens if you are wrong.

Streaming deduplication is not one trick. It is a state-management problem: pick the event identity, choose the memory horizon, and put the dedup state where the failure mode is acceptable.

Resolution is only the pixel count. The picture also needs enough bits to describe those pixels. A 4K stream can have more pixels than a theater image and still give each pixel far less data.

4K streaming is not automatically better than a lower-resolution theater image. Bitrate, compression, mastering, color, motion, and viewing conditions all decide how much detail survives.

Flink is not just a library that runs a loop over events. It turns a streaming program into a distributed dataflow, splits operators into parallel subtasks, places those subtasks into task slots, and keeps state recoverable with checkpoints.

A practical walkthrough of Flink internals: what problem Flink solves, how operators become tasks and subtasks, how parallelism and keyBy scale a job, and how TaskManagers, slots, state, and checkpoints fit together.

OpenAI kept one PostgreSQL primary alive for a massive read-heavy workload by moving reads to replicas, pooling connections, protecting caches, rate limiting spikes, and pushing write-heavy workloads elsewhere. The useful lesson is not "Postgres scales forever." It is knowing which pressure you are actually under.

A practical guide to the OpenAI PostgreSQL scaling story: what they did, why it worked, and what normal engineering teams can do with batching, Kafka, idempotent writes, read replicas, caches, and workload isolation.