↓ Skip to main content
111qqz’s blog
  1. Tags/

Inference

2026

从投机解码到 Rand5 模拟 Rand7：跨越十年的拒绝采样直觉

·6446 words·13 mins
Deep-Learning LLM Inference Speculative-Decoding Algorithm Probability Ml-Infra
上一篇理清了 Prefill 和 Decode 的因果链之后，我开始翻 Decode 阶段的加速方案。结论已经很清楚了：在单请求、小 Batch 的典型场景下，Decode 阶段是 memory-bound 的——每生成一个 token 就要把整个模型权重从显存搬一遍，计算单元大部分时间在等数据（Batch 较大或模型结构不同时，瓶颈也可能转向 compute-bound，但单次请求的延迟优化场景下 memory-bound 是常态）。

PagedAttention：为什么 KV Cache 需要自己的内存管理系统？

·5975 words·12 mins
Deep-Learning LLM KV-Cache Inference Ml-Infra Serving VLLM
前一篇写完之后，KV Cache 在我脑子里的形象已经变了——它不再是一次 forward 里的临时中间量，而是一个跨多轮存活、随 Decode 持续增长、每个请求各自独立的状态。 但"知道它是有状态的"和"知道怎么管它"是两件事。当我开始想具体的内存管理问题的时候，发现事情比想象的复杂。

从一次 Forward 到持续生成：LLM Inference 为什么不一样？

·5127 words·11 mins
Deep-Learning LLM Inference KV-Cache Ml-Infra Serving
最近在从传统模型 Serving 转向 LLM Inference，一个让我停下来想了很久的问题是：为什么 LLM 的推理系统看起来和我之前熟悉的那套完全不一样？ 我之前做推荐模型和 CV 模型的部署，排序模型的 Serving 架构虽然在工程上也有不少复杂性（远程 embedding 读取、稀疏参数缓存等），但核心计算模式不难概括：一个请求进来，跑一次 forward，返回结果。LLM Serving 里冒出来一大堆新概念——推理要分成 Prefill 和 Decode 两个阶段，中间要维护 KV Cache，请求调度要做 Continuous Batching，显存管理要用 PagedAttention——我花了些时间才把它们背后的因果链串起来。

从 CS336 到 ML Infra：理解 Arithmetic Intensity、Accelerator Intensity，以及 Compute Bound / Memory Bound

·6012 words·12 mins
Deep-Learning CS336 Arithmetic-Intensity Roofline Gpu-Performance Inference Ml-Infra
起因 # 这是 CS336 系列的又一篇。 之前那篇讨论了 FLOPs 到 Latency 之间的鸿沟：FLOPs 相同的两个 GEMM，latency 可能差几倍甚至十几倍。那篇文章的核心结论是 FLOPs 是 workload metric，不是 performance metric，并且引入了 Arithmetic Intensity 和 Roofline Model 作为分析工具。

从线上模型切换问题理解 PyTorch CUDA Caching Allocator：为什么显存管理需要理解生命周期

·6437 words·13 mins
Deep-Learning CUDA PyTorch Gpu-Memory Memory-Allocator Inference Ml-Infra
起因 # 我们的线上推理系统中存在大量模型——MLP、GNN、MoE，以及它们的各种组合。这个 workload 有几个重要特点： 单张 GPU 上可能同时存在多个模型； 很多模型的 architecture 相同或者高度相似； 模型会随着业务时间轴不断上线、下线和切换； 模型切换过程对 latency 比较敏感。 随着模型数量增加以及动态上下线越来越频繁，我们逐渐观察到两个问题：GPU memory fragmentation，以及 model loading / switching latency。