一、引言你有一张 RTX 4090，24GB 显存。你下载了 Llama-3.1-70B-Instruct，想在本机跑推理。然后发现：模型参数 70B，哪怕用 FP16（2 bytes per param），光是加载参数就需要 70×10⁹

先快速过一遍前向传播：token 先查表变成向量，然后逐层经过 Transformer Block，每层里用 Q、K、V 三个向量做自注意力，最后从词表分布里挑出下一个 token。 我们也知道了生成是自回归（Autoregressive）

几乎在所有的大型语言模型（LLM）面试中，都有一个经常被问到的问题：”服务一个大型语言模型需要多少GPU内存？” 这个问题并非随意提出——它是检验你对这些强大模型在生产环境中部署和可扩展性理解程度的关键指标。在使用像 GPT、LLaMA 或

看 AI 芯片、GPU、模型训练和推理时，经常会看到这些词：FP64、FP32、TF32、BF16、FP16、FP8、INT8、INT4、NVFP4 它们本质上都在回答一个问题：计算机到底用多少 bit 来表示一个数字，以及这个数字怎么被表

一、RPC 分布式推理的核心原理llama.cpp 的 RPC 模式基于一个非常朴素的想法：大模型是一层一层叠起来的，不同层可以在不同机器上算。 Transformer 模型的每一层计算相对独立——上一层算完把结果传给下一层。这就给了分布式

大模型推理优化是一个层层递进的话题：先搞懂数在硬件上长什么样，再算清模型要占多少内存，然后理解 KV Cache 这个核心机制，接着学会用量化压缩它，最后把带宽、容量这些端侧约束和投机解码这类算法加速串起来。7 篇文章按发文时间顺序读即是推

这是 llama.cpp 源码系列的第二篇。上一篇我们拆解了推理引擎 GGML，理解了张量、Arena、延迟执行、Galloc、KV Cache、线程模型的完整骨架。 但还有一个问题没回答：模型文件本身是怎么设计的？ 从磁盘上的一个文件，到

几周前我开始看 llama.cpp 的源码。想看看”为什么我这台本地的笔记本也能跑得动 7B 甚至 14B 模型”，结果发现——这个项目太有意思了。所以我准备尝试写篇系列文章（又开新坑😂）。 从推理引擎开始，如果你也想知道 llama.c

想读懂 llama.cpp，最好的路径是从底往上：先看它如何设计推理引擎（GGML），再看模型如何从磁盘走进内存（GGUF），最后看它如何把推理搬到局域网的另一台机器上（RPC）。3 篇文章按发文时间顺序读即是推荐阅读顺序。 全系列 lla

类似于 kylin 的 ExecMan，bthread::ExecutionQueue 提供了异步串行执行的功能。ExecutionQueue 的相关技术最早使用在 RPC 中实现多线程向同一个 fd 写数据，在 r31345 之后加入到了

“雪崩”指的是访问服务集群时绝大部分请求都超时，且在流量减少时仍无法恢复的现象。下面解释这个现象的来源。 单一服务：过载但可恢复当流量超出服务的最大 qps 时，服务将无法正常服务；当流量恢复正常时（小于服务的处理能力），积压的请求会被处理

服务的处理能力是有客观上限的。当请求速度超过服务的处理速度时，服务就会过载。如果服务持续过载，会导致越来越多的请求积压，最终所有的请求都必须等待较长时间才能被处理，从而使整个服务处于瘫痪状态。 与之相对的，如果直接拒绝掉一部分请求，反而能够