企业官网建设流程全解析

1. 项目概述：为什么说 llama.cpp 是本地大模型的“裸引擎”

你有没有试过在自己笔记本上跑一个真正意义上的大语言模型？不是调用某个网页接口，也不是依赖云服务API，而是把模型文件下载到本地硬盘，双击启动一个命令行程序，然后看着终端里一行行 token 慢慢吐出来——那种“模型真正在我机器里呼吸”的实感。llama.cpp 就是干这个事的。它不包装、不抽象、不加中间层，连 Python 解释器都不需要，直接用纯 C/C++ 把 Transformer 的前向推理过程一帧一帧写死在内存里。它不叫“框架”，也不叫“平台”，它就叫“引擎”——而且是剥掉所有外壳、露出活塞与曲轴的裸引擎。

核心关键词“llama.cpp”和“GGUF 格式”不是并列关系，而是一体两面：llama.cpp 是执行者，GGUF 是它唯一认的“燃料规格”。就像柴油发动机只烧符合 EN 590 标准的柴油，llama.cpp 只加载符合 GGUF 规范的模型文件。这不是兼容性妥协，而是设计哲学——放弃通用性，换取极致可控性。它不支持 PyTorch 的 .pt 文件，不读取 Hugging Face 的 safetensors，甚至不碰 ONNX；它只认 GGUF，因为只有 GGUF 能把模型权重、量化参数、元数据、词表、甚至自定义 KV 缓存策略全部打包进一个二进制块里，且结构完全可解析、可 mmap、可零拷贝访问。

这个项目解决的不是“能不能跑”的问题，而是“怎么跑得最稳、最省、最透明”的问题。它面向三类人：第一类是嵌入式/边缘开发者，要在 4GB 内存的树莓派上部署对话助手；第二类是安全敏感型用户，拒绝任何远程调用、拒绝模型权重离开本地；第三类是算法工程师，想绕过 PyTorch 的自动微分和动态图调度，亲手调试 attention mask 的内存布局、观察 kv cache 的实际增长曲线、验证某一层 FFN 的 int4 量化误差是否真的可控。它不适合想“一键生成小红书文案”的新手，但特别适合那些愿意为省下 300MB 显存、多撑住 2 秒推理延迟、少一次 memcpy 而花两小时读源码的人。

我第一次在 M1 MacBook Air 上用 llama.cpp 跑通qwen2-0.5b的时候，没有 GPU 加速，全程 CPU 推理，但输出延迟稳定在 800ms/token 左右。更关键的是，我打开htop，能清清楚楚看到llama-server进程占用了多少物理内存、多少 swap、CPU 使用率如何随生成长度线性爬升——这种“全栈可见性”，是任何封装好的 Python 包都给不了的。它不隐藏成本，也不美化瓶颈，它把大模型运行的每一克资源消耗，都摊开在你面前。

2. 整体设计思路：为什么必须是 C/C++ + GGUF？而不是别的方案

2.1 放弃 Python 生态，是主动选择，不是技术退化

很多人看到 llama.cpp 第一反应是：“怎么不用 PyTorch？不是有torch.compile了吗？”——这恰恰是理解它设计逻辑的关键岔路口。PyTorch 的优势在于训练灵活性和生态丰富性，但它的推理路径天生带着三重开销：Python 解释器的 GIL 锁、Tensor 对象的引用计数与内存管理、以及 Autograd 引擎残留的计算图追踪逻辑。哪怕你只做 inference，model.forward()调用背后仍有至少 5 层函数跳转、多次内存分配与释放、以及无法避免的跨语言边界（C++ backend ←→ Python binding）。

llama.cpp 的 C/C++ 实现绕开了这一切。它把整个推理流程压进一个扁平化的 C 函数调用链：llama_eval()→llama_decode()→llama_attention()→llama_matmul(). 每个函数都明确知道自己的输入 buffer 地址、输出 buffer 地址、以及要操作的 float/int 数据长度。没有对象生命周期管理，没有异常传播，没有 JIT 编译等待时间。我在某次实测中对比了相同模型（phi-3-mini-4k-instruct，Q4_K_M 量化）在 PyTorch（transformers+optimum）和 llama.cpp 下的首次 token 延迟：PyTorch 平均 1200ms，llama.cpp 稳定在 410ms。差值里，有 320ms 来自 Python 初始化开销（import torch, load tokenizer, instantiate model class），210ms 来自 PyTorch 自身的 tensor 创建与 layout 验证，剩下才是真正的 matmul 计算。llama.cpp 把这 530ms 全部砍掉了。

提示：这不是贬低 PyTorch，而是场景错配。PyTorch 是“实验室显微镜”，llama.cpp 是“工厂流水线上的专用夹具”。你要做模型结构探索，用 PyTorch；你要把模型塞进路由器固件里，用 llama.cpp。

2.2 GGUF 不是格式升级，而是运行时契约的重新定义

GGUF 的出现，直接终结了此前大模型本地部署的“格式战国时代”。在它之前，我们有 GGML（llama.cpp 的上一代格式）、SafeTensors（Hugging Face 主推）、PyTorch.bin、甚至有人手动导出为 NumPy.npy。每种格式都带着自己的包袱：GGML 缺少元数据描述能力，无法区分“这是 LLaMA-3 还是 Qwen2 的 tokenizer”；SafeTensors 虽然安全，但仍是键值对集合，无法表达 tensor 的 block-wise 量化策略；.bin文件则完全不带任何 schema，全靠代码硬编码解析逻辑。

GGUF 的核心突破，在于它把“模型是什么”和“模型怎么跑”合并成一份可执行说明书。它的文件结构像一本装订好的技术手册：

• Header Section：固定 32 字节，声明 magic number (0x67677566) 和版本号，确保 loader 能第一时间识别“这是 GGUF，不是别的”；
• KV Pair Section：用变长整数编码存储所有元数据——模型架构名（llama,qwen2,gemma2）、层数（llama.n_layer）、隐藏层维度（llama.hidden_size）、词表大小（tokenizer.ggml.vocab_size），甚至包括作者信息（general.author）和许可证（general.license）；
• Tensor Info Section：不再只是“tensor 名字+shape”，而是精确到每个 tensor 的数据类型（f32,q4_0,q5_k,q6_k）、数据偏移量（data_offset）、以及量化参数（如q4_0的 block size = 32, scale offset = 0x1234）；
• Tensor Data Section：所有 tensor 数据按顺序紧挨着存放，无 padding，可直接mmap()到内存，memcpy零次即可开始计算。

这意味着，当你执行./main -m models/qwen2-1.5b.Q4_K_M.gguf -p "今天天气怎么样"，llama.cpp 的 loader 不需要“猜测”模型结构，它直接从 Header 读出llama.n_layer=28，从 KV 区读出tokenizer.ggml.model=qwen2，从 Tensor Info 区定位到output.weight的起始地址和量化方式，然后调用对应的dequantize_row_q4_0()函数解码——整个过程没有反射、没有动态 dispatch、没有配置文件解析，全是编译期确定的指针运算。

2.3 为什么不做 GPU 加速？——不是不能，而是“不必要”地克制

llama.cpp 官方长期只维护 CPU 后端（AVX2/AVX-512/ARM NEON），直到 2024 年初才实验性加入 CUDA 支持（LLAMA_CUDA）。这不是技术滞后，而是刻意为之的工程克制。GPU 加速带来三个隐性代价：第一，显存与内存之间的 PCIe 带宽成为新瓶颈，尤其在小模型、短上下文场景下，数据搬运时间可能超过计算时间；第二，CUDA kernel 启动有毫秒级延迟，对单 token 生成不友好；第三，GPU 显存管理复杂，OOM 错误难以 debug，且不同卡型号（RTX 3090 vs RTX 4090）的 tensor core 利用率差异巨大，导致性能不可预测。

我做过一组对照实验：在 RTX 4090 上跑qwen2-0.5b.Q4_K_M，分别测试 CPU-only 和 CUDA 后端的吞吐量（tokens/sec）：

• CPU（16 线程，AVX2）：18.2 tokens/sec
• CUDA（默认配置）：21.7 tokens/sec
• CUDA（手动调优LLAMA_N_THREADS=8,LLAMA_N_GPU_LAYERS=20）：24.1 tokens/sec

提升仅 32%，但代价是：CUDA 版本编译耗时增加 3 倍，二进制体积膨胀 40%，且一旦n_gpu_layers设错，就会触发显存碎片错误，报错信息晦涩难懂。而 CPU 版本，只要内存够，就能跑，报错永远是清晰的std::bad_alloc或segmentation fault (core dumped)，配合gdb一把就能定位到哪行malloc失败。

所以 llama.cpp 的选择很务实：把 80% 的用户场景（<7B 模型、<4K 上下文、消费级 CPU）做到极致稳定，剩下的 20% 高性能需求，交给用户自己权衡——你要不要为那 30% 的吞吐提升，承担额外的编译、调试、部署复杂度？

3. 核心细节解析：GGUF 文件结构、量化原理与内存布局

3.1 GGUF 文件的“四段式”物理结构详解

GGUF 文件不是抽象容器，而是一份严格对齐的二进制地图。它的结构设计直指两个目标：零拷贝加载和跨平台可移植。下面以一个真实qwen2-0.5b.Q4_K_M.gguf文件（大小 482,192,896 字节）为例，逐段拆解其物理布局：

这个结构带来的直接好处是：加载速度与模型大小无关，只与 header/kv/tensor-info 三部分总和相关。无论你加载的是 500MB 的 0.5B 模型，还是 3.2GB 的 7B 模型，llama.cpp 的llama_model_load()函数前 10ms 做的事完全一样——读 32 字节 header，解析出有多少 kv 对、多少 tensor，然后跳转到对应 offset 开始 mmap。我在一台机械硬盘老笔记本上测试，加载 3.2GB 的llama-3-8b-instruct.Q5_K_M.gguf，从./main -m ...执行到打印出system_info: n_threads = 8 / 16 | AVX = 1 | AVX_VNNI = 0 | AVX2 = 1 | ...仅耗时 112ms，其中磁盘 IO 占 98ms，解析逻辑仅 14ms。

注意：GGUF 的data_offset是相对于文件开头的绝对偏移，不是相对偏移。这意味着你可以把 GGUF 文件切成两半——前半部分（header+kv+info）单独拿出来，用十六进制编辑器打开，就能人工验证模型架构、层数、量化类型，无需任何工具。这是对模型“可审计性”的底层保障。

3.2 Q4_K_M 量化：不是简单截断，而是分块自适应缩放

提到 GGUF，绕不开它的量化方案。Q4_K_M是目前最主流的平衡型量化，它不是把 FP16 权重粗暴截断成 4-bit 整数，而是一套精密的分块压缩协议。其核心思想是：同一 block 内的 weight，共享一个 scale 和 zero point，但不同 block 可以用不同的 scale，从而适应 weight 分布的局部变化。

具体来说，Q4_K_M的一个 block 包含 32 个 weight（即block_size = 32），每个 weight 用 4-bit 表示（0~15）。但它实际存储的是x_i = round((w_i - zp) / scale)，其中scale和zp（zero point）是该 block 的两个 FP16 参数。Q4_K_M的特殊之处在于，它把 32 个 weight 分成 2 组，每组 16 个，并为每组独立计算scale和zp。这样，一个 block 实际存储：

• 2 个 FP16scale（4 字节）
• 2 个 FP16zp（4 字节）
• 32 个 4-bitx_i（16 字节）
• 总计 24 字节，表示 32 个 FP16 weight（64 字节），压缩比 2.67x

我用 Python 手动实现过Q4_K_M的 dequantize 逻辑（用于 debug）：

import numpy as np def dequantize_q4_k_m(q_data: np.ndarray, block_size=32) -> np.ndarray: # q_data shape: (n_blocks, 24), dtype=np.uint8 deq = np.zeros((q_data.shape[0], block_size), dtype=np.float32) for i in range(q_data.shape[0]): block = q_data[i] # 解析前 4 字节：2 个 FP16 scale scale0 = np.frombuffer(block[0:2], dtype=np.float16)[0] scale1 = np.frombuffer(block[2:4], dtype=np.float16)[0] # 解析 next 4 字节：2 个 FP16 zp zp0 = np.frombuffer(block[4:6], dtype=np.float16)[0] zp1 = np.frombuffer(block[6:8], dtype=np.float16)[0] # 解析后 16 字节：32 个 4-bit x_i，每字节存 2 个 nibbles = np.unpackbits(block[8:24], bitorder='little').reshape(-1, 8) x0 = (nibbles[:, 0] | (nibbles[:, 1] << 1) | (nibbles[:, 2] << 2) | (nibbles[:, 3] << 3)).astype(np.int8) # 16 个 x1 = (nibbles[:, 4] | (nibbles[:, 5] << 1) | (nibbles[:, 6] << 2) | (nibbles[:, 7] << 3)).astype(np.int8) # 16 个 # 还原为 float deq[i, 0:16] = x0.astype(np.float32) * scale0 + zp0 deq[i, 16:32] = x1.astype(np.float32) * scale1 + zp1 return deq

这段代码的关键启示是：Q4_K_M的误差不是均匀分布的，而是block-local 的。如果某个 block 的 weight 全是接近 0 的小数，它的scale就会很小，x_i的量化步长也小，精度高；如果某个 block 的 weight 有极端大值（比如 attention 的o_proj.weight最后几行），它的scale就会拉大，x_i步长变宽，但整体动态范围保住了。这就是它比全局Q4_0更鲁棒的原因——它承认模型内部的 weight 分布是不均匀的，并用分块策略去适配它。

3.3 内存布局：从 mmap 到 kv_cache，每一字节都可控

llama.cpp 的内存使用哲学是：“能 mmap 就不 malloc，能 stack 就不 heap，能 reuse 就不 new”。这直接体现在它的三大内存区设计上：

1. Model Memory（只读，mmap）：整个 GGUF 文件被mmap()到进程虚拟地址空间，标记为PROT_READ。所有权重 tensor 的数据指针，都直接指向 mmap 区域内的&data[tensor_info.data_off]。这意味着：

   • 没有memcpy开销，加载瞬间完成；
   • 多个进程可以共享同一份 mmap，物理内存只存一份（Linux 的 copy-on-write 机制）；
   • 如果你用llama-server启动 HTTP 服务，10 个并发请求，模型权重内存占用仍是 1 份。

2. Context Memory（读写，malloc）：这是推理的核心工作区，包含：

   • embd：输入 token ID 数组（int32_t*），最大长度由-c参数控制（default 2048）；
   • logits：最后 layer 的输出 logits（float32_t*），大小为vocab_size；
   • kv_self.k/kv_self.v：Key-Value Cache，大小为n_layer * n_kv * n_embd * sizeof(float16)，是内存大户。

3. Scratch Memory（临时，stack 或 malloc）：用于 matmul 中间结果、rope 计算 buffer、attention softmax 的临时数组。llama.cpp 默认用malloc，但允许用户通过llama_context_params.offload_kqv = true把 K/V cache offload 到 GPU，而 scratch 仍留在 CPU RAM。

我曾用valgrind --tool=massif监控llama-cli运行时的内存峰值，发现一个典型现象：对于qwen2-0.5b.Q4_K_M（482MB 文件），mmap占用恒为 482MB；context占用约 1.2GB（主要来自 kv cache）；scratch峰值仅 18MB。这意味着，只要你有一块 2GB 的空闲内存，就能跑起来——mmap的 482MB 是“懒加载”的，实际物理内存只在第一次访问某个 block 时才分配。

实操心得：如果你的机器内存紧张，不要盲目调小-c（context size），而应优先检查n_batch（每次 eval 的 token 数）。n_batch默认是 512，意味着即使你只输入 10 个 token，llama.cpp 也会预分配 512 个 embd slot 和对应的 kv cache slot。把它设为--batch-size 32，内存峰值能立刻下降 40%。

4. 实操过程：从编译、量化到部署的完整闭环

4.1 编译 llama.cpp：不是make一下就完事

llama.cpp 的编译看似简单，但几个关键 flag 直接决定你的体验上限。官方Makefile提供了AVX2,AVX512,CUDA等 target，但生产环境推荐手动指定：

# 推荐：针对现代 Intel/AMD CPU（支持 AVX2 + FMA） make LLAMA_AVX=1 LLAMA_AVX2=1 LLAMA_F16C=1 LLAMA_FMA=1 -j$(nproc) # 针对 Apple Silicon（M1/M2/M3） make LLAMA_METAL=1 -j$(nproc) # 针对 NVIDIA GPU（需先装好 CUDA toolkit） make LLAMA_CUDA=1 CUDA_PATH=/usr/local/cuda -j$(nproc)

关键点解析：

• LLAMA_AVX2=1：启用 AVX2 指令集，matmul 速度比基础 AVX 快 1.8 倍（实测qwen2-0.5b）；
• LLAMA_FMA=1：启用融合乘加指令，让a*b + c变成单条指令，减少浮点误差累积；
• LLAMA_METAL=1：这是 Apple Silicon 的灵魂选项。它把llama_eval()中的 matmul 和 rope 计算 offload 到 GPU，CPU 只负责调度和 tokenization。在 M2 Max 上，qwen2-1.5b.Q5_K_M的吞吐从 CPU 的 12.3 tokens/sec 提升到 Metal 的 38.7 tokens/sec，且 CPU 占用率从 95% 降到 15%。

编译后你会得到bin/main,bin/server,bin/llama-bench等可执行文件。注意：bin/main是命令行交互版，bin/server是 HTTP API 版（兼容 OpenAI 格式），二者二进制完全独立，server会链接libuv，而main不依赖任何外部库。

注意：不要用cmake编译。llama.cpp 的Makefile是经过千锤百炼的，cmake版本在某些旧系统上会漏掉LLAMA_AVX2的编译宏，导致 runtime 报Illegal instruction。我踩过这个坑——在一台 CentOS 7 的旧服务器上，cmake编译的 binary 在llama_matmul_nc函数里直接 segfault，换成make就好了。

4.2 模型获取与量化：GGUF 不是终点，而是起点

llama.cpp 官方不提供模型，它只提供转换工具convert-hf-to-gguf.py。你必须先从 Hugging Face 获取原始模型（如Qwen/Qwen2-0.5B-Instruct），再转换。标准流程如下：

# 1. 克隆转换脚本（在 llama.cpp 仓库根目录） git clone https://huggingface.co/Qwen/Qwen2-0.5B-Instruct ./models/qwen2-0.5b-hf # 2. 转换为 GGUF（会自动下载 tokenizer 和 config） python3 convert-hf-to-gguf.py ./models/qwen2-0.5b-hf --outfile ./models/qwen2-0.5b.F16.gguf # 3. 量化（推荐 Q5_K_M，平衡精度与速度） ./quantize ./models/qwen2-0.5b.F16.gguf ./models/qwen2-0.5b.Q5_K_M.gguf Q5_K_M

这里有两个极易被忽略的细节：

• convert-hf-to-gguf.py会自动识别config.json中的architectures字段（如["Qwen2ForCausalLM"]），并映射到 GGUF 的general.architecture="qwen2"。如果你的模型 config 里写的是"LlamaForCausalLM"，它就会打上llama标签，后续llama.cpp就会用 llama 的 RoPE 公式，而不是 qwen2 的yarnRoPE，导致输出乱码。务必检查转换后的 GGUF 文件 KV 区：gguf dump ./models/qwen2-0.5b.Q5_K_M.gguf | grep architecture。
• quantize工具的Q5_K_M参数不是魔法，它背后有严格的量化误差测试。Q5_K_M会在每个 block 内计算scale和zp，并保证max(|w_i - w_i_deq|) < 0.005。而Q4_K_S（small）会放宽到< 0.012，适合对精度要求不高的摘要任务。别迷信“越小越好”，Q3_K_M在qwen2-0.5b上会让数学题准确率从 72% 掉到 41%。

4.3 本地部署：从 CLI 到 Web API 的三种姿势

姿势一：main—— 最纯粹的命令行交互

./main -m ./models/qwen2-0.5b.Q5_K_M.gguf \ -p "请用中文解释量子纠缠" \ -n 256 \ -t 8 \ -c 2048 \ --temp 0.7 \ --repeat_penalty 1.1

参数详解：

• -n 256：最多生成 256 个 token，防无限循环；
• -t 8：用 8 个线程，匹配你的 CPU 核心数；
• -c 2048：context size，即模型能看到的历史 token 数；
• --temp 0.7：temperature，控制随机性，0.7 是通用推荐值；
• --repeat_penalty 1.1：重复惩罚，1.0=不惩罚，>1.0=抑制重复。

姿势二：server—— OpenAI 兼容的 HTTP API

./server -m ./models/qwen2-0.5b.Q5_K_M.gguf -c 4096 -t 8 --port 8080

启动后，你就可以用标准 OpenAI SDK 调用：

from openai import OpenAI client = OpenAI(base_url="http://localhost:8080/v1", api_key="sk-no-key-required") response = client.chat.completions.create( model="qwen2-0.5b", messages=[{"role": "user", "content": "你好"}] ) print(response.choices[0].message.content)

server的优势是：它内置了 request queue、rate limiting、streaming response（SSE），且返回 JSON 完全兼容openai.ChatCompletion。缺点是：它会常驻内存，且每个请求都会创建新的llama_context，内存占用比main高 20%。

姿势三：llama-bench—— 你的私人性能实验室

./llama-bench -m ./models/qwen2-0.5b.Q5_K_M.gguf -p "A" -n 128 -t 1 -b 32 -r 5

这个工具专为 benchmark 设计：

• -p "A"：输入一个 token，消除 prompt processing 影响；
• -n 128：生成 128 个 token；
• -t 1：单线程，排除多线程调度干扰；
• -b 32：batch size = 32，测试吞吐；
• -r 5：重复 5 次取平均。

它会输出精确到微秒的eval time（prompt 处理）、sample time（token 生成）、ms per token、tokens per second。这是我每次升级 CPU 或换量化格式后必跑的测试，数据比任何博客文章都可靠。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “Segmentation fault (core dumped)” —— 最常见的三类原因

这个错误不是代码 bug，而是内存越界或非法访问的通用信号。根据我的实测，90% 的 case 属于以下三类：

实操心得：遇到 segfault，第一件事不是重装，而是ulimit -c unlimited，然后./main ...让它生成 core dump，再用gdb ./main core查看bt full。90% 的 case，bt的第一行就告诉你错在哪——是llama_kv_cache_update还是llama_decode，这比瞎猜高效十倍。

5.2 “Out of memory” 但free显示内存充足？—— mmap 的隐形限制

这是一个经典误区。free -h显示还有 4GB free，但./main仍报std::bad_alloc。原因在于：Linux 对单个进程的mmap区域有默认限制（vm.max_map_area），通常为 65536（64K）个 memory mapping areas。一个 GGUF 模型会创建多个 mmap 区（model weights + kv cache + scratch），很容易触顶。

验证方法：

cat /proc/sys/vm/max_map_count # 查看当前限制 grep -i "map" /proc/$(pidof main)/status # 查看 main 进程已用 mmap 数

解决方案（永久生效）：

echo 'vm.max_map_count = 262144' | sudo tee -a /etc/sysctl.conf sudo sysctl -p

注意：这不是内存不足，而是“内存管理单元”的句柄耗尽。调高max_map_count不会增加物理内存，只是放宽了进程能创建的虚拟内存区域数量上限。

5.3 生成质量差：不是模型不行，可能是 RoPE 配置错了

很多用户反馈：“我用的明明是 Qwen2 官方模型，为什么生成中文总是断句奇怪、逻辑跳跃？”——大概率是 RoPE（Rotary Position Embedding）的freq_base或freq_scale参数没对上。

Qwen2 使用yarnRoPE，其freq_base默认是500000.0，而 LLaMA-3 是500000.0，Phi-3 是10000.0。如果 GGUF 文件里qwen2.rope.freq_base写成了10000.0，那么位置编码就会错位，模型“以为”自己在看第 1000 个 token，实际才第 100 个，导致注意力头混乱。

修复方法（需gguf工具）：

# 先安装 gguf 工具 pip install gguf # 查看当前 freq_base python3 -c "import gguf; print(gguf.GGUFReader('./model.gguf').kv['qwen2.rope.freq_base'])" # 修改为正确值（Qwen2 应为 500000.0） python3 -c " import gguf r = gguf.GGUFReader('./model.gguf') r.kv['qwen2.rope.freq_base'] = 500000.0 r.write('./model-fixed.gguf') "

这个操作修改的是 GGUF 文件的 KV 区，不碰 tensor data，安全可靠。我帮三位用户修过这个问题，修改后生成质量立刻回归正常水平。

5.4 性能瓶颈诊断：perf比top有用一百倍

当./main跑得慢，top只显示 CPU 100%，但你不知道瓶颈在哪。这时要用perf：

# 记录 30 秒性能数据 perf record -g -p $(pgrep -f "main.*qwen2") sleep 30 # 生成火焰图 perf script | ~/FlameGraph/stackcollapse-perf.pl | ~/FlameGraph/flamegraph.pl > perf.svg

典型火焰图会揭示真相：

• 如果 `llama