小吴同学
善良比聪明更重要
LLM 推理系列(四):模型量化——原理与范式 LLM 推理系列(四):模型量化——原理与范式
一、引言你有一张 RTX 4090,24GB 显存。你下载了 Llama-3.1-70B-Instruct,想在本机跑推理。然后发现:模型参数 70B,哪怕用 FP16(2 bytes per param),光是加载参数就需要 70×10⁹
2026-01-31
LLM 推理系列(三):KV Cache 原理与显存占用 LLM 推理系列(三):KV Cache 原理与显存占用
先快速过一遍前向传播:token 先查表变成向量,然后逐层经过 Transformer Block,每层里用 Q、K、V 三个向量做自注意力,最后从词表分布里挑出下一个 token。 我们也知道了生成是自回归(Autoregressive)
2026-01-26
LLM 推理系列(二):运行大型语言模型需要多少 GPU 内存? LLM 推理系列(二):运行大型语言模型需要多少 GPU 内存?
几乎在所有的大型语言模型(LLM)面试中,都有一个经常被问到的问题:”服务一个大型语言模型需要多少GPU内存?” 这个问题并非随意提出——它是检验你对这些强大模型在生产环境中部署和可扩展性理解程度的关键指标。在使用像 GPT、LLaMA 或
2026-01-21
LLM 推理系列(一):讲清 FP64、FP32、TF32、BF16、FP16、FP8、INT8、INT4、NVFP4 LLM 推理系列(一):讲清 FP64、FP32、TF32、BF16、FP16、FP8、INT8、INT4、NVFP4
看 AI 芯片、GPU、模型训练和推理时,经常会看到这些词:FP64、FP32、TF32、BF16、FP16、FP8、INT8、INT4、NVFP4 它们本质上都在回答一个问题:计算机到底用多少 bit 来表示一个数字,以及这个数字怎么被表
2026-01-16
llama.cpp RPC 局域网分布式推理验证 llama.cpp RPC 局域网分布式推理验证
一、RPC 分布式推理的核心原理llama.cpp 的 RPC 模式基于一个非常朴素的想法:大模型是一层一层叠起来的,不同层可以在不同机器上算。 Transformer 模型的每一层计算相对独立——上一层算完把结果传给下一层。这就给了分布式
2026-01-11
LLM 推理系列导读:从数值格式到投机解码 LLM 推理系列导读:从数值格式到投机解码
大模型推理优化是一个层层递进的话题:先搞懂数在硬件上长什么样,再算清模型要占多少内存,然后理解 KV Cache 这个核心机制,接着学会用量化压缩它,最后把带宽、容量这些端侧约束和投机解码这类算法加速串起来。7 篇文章按发文时间顺序读即是推
2026-01-09
llama.cpp 源码解析(二):GGUF 格式与模型加载——从磁盘文件到内存张量 llama.cpp 源码解析(二):GGUF 格式与模型加载——从磁盘文件到内存张量
这是 llama.cpp 源码系列的第二篇。上一篇我们拆解了推理引擎 GGML,理解了张量、Arena、延迟执行、Galloc、KV Cache、线程模型的完整骨架。 但还有一个问题没回答:模型文件本身是怎么设计的? 从磁盘上的一个文件,到
2026-01-06
llama.cpp 源码解析(一):GGML——大模型推理引擎是如何设计的 llama.cpp 源码解析(一):GGML——大模型推理引擎是如何设计的
几周前我开始看 llama.cpp 的源码。想看看”为什么我这台本地的笔记本也能跑得动 7B 甚至 14B 模型”,结果发现——这个项目太有意思了。所以我准备尝试写篇系列文章(又开新坑😂)。 从推理引擎开始,如果你也想知道 llama.c
2026-01-01
llama.cpp 系列导读:源码解析三部曲 llama.cpp 系列导读:源码解析三部曲
想读懂 llama.cpp,最好的路径是从底往上:先看它如何设计推理引擎(GGML),再看模型如何从磁盘走进内存(GGUF),最后看它如何把推理搬到局域网的另一台机器上(RPC)。3 篇文章按发文时间顺序读即是推荐阅读顺序。 全系列 lla
2025-12-25
RPC 系列(四十三):ExecutionQueue 详解 RPC 系列(四十三):ExecutionQueue 详解
类似于 kylin 的 ExecMan,bthread::ExecutionQueue 提供了异步串行执行的功能。ExecutionQueue 的相关技术最早使用在 RPC 中实现多线程向同一个 fd 写数据,在 r31345 之后加入到了
2024-06-25
RPC 系列(四十二):从雪崩看限流 RPC 系列(四十二):从雪崩看限流
“雪崩”指的是访问服务集群时绝大部分请求都超时,且在流量减少时仍无法恢复的现象。下面解释这个现象的来源。 单一服务:过载但可恢复当流量超出服务的最大 qps 时,服务将无法正常服务;当流量恢复正常时(小于服务的处理能力),积压的请求会被处理
2024-06-18
RPC 系列(四十一):自适应并发限流 RPC 系列(四十一):自适应并发限流
服务的处理能力是有客观上限的。当请求速度超过服务的处理速度时,服务就会过载。如果服务持续过载,会导致越来越多的请求积压,最终所有的请求都必须等待较长时间才能被处理,从而使整个服务处于瘫痪状态。 与之相对的,如果直接拒绝掉一部分请求,反而能够
2024-06-11
2 / 24