2.2 关键技术机制
2.2 关键技术机制
本节摘要：Ollama 之所以能在游戏本、迷你主机甚至树莓派上调动大模型，靠的不是蛮力堆料，而是三项底层设计各司其职：GGUF 容器决定了模型文件如何被硬件"一口吞下"，llama.cpp 推理内核决定了每一层矩阵乘法在什么精度、什么指令集上执行，而后端的分层调度决定了多模型共存时谁上 GPU、谁留在内存、谁被换出。本节把这三层拆开看清楚。
读完这一节，你应该能回答三个问题：为什么同一个 7B 模型会有 Q4、Q5、Q8 等一排版本，选哪个；为什么 num_gpu 参数调大反而可能变慢；为什么 Ollama 默认让模型常驻 5 分钟而不是用完立刻卸载。
从一个下载列表说起：量化是怎么回事
第一次执行 ollama pull llama3 时，终端会滚出一串下载进度，最终落到 ~ollama/models/blobs 下一个约 4.7GB 的文件。如果改拉 llama3:8b-instruct-q8_0，文件会变成 8.5GB 左右。体积差异来自量化位数——原始权重是 16 位浮点，量化就是把它们压缩成 4 位、5 位或 8 位整数存储，推理时再反算回浮点参与运算。
位数越低，体积和内存占用越小，速度越快，但精度损失越大。社区给 Llama 3 8B 准备了从 q2_K 到 q8_0 的完整梯度，命名规则可以拆开读：
# 查看本地已有哪些量化变体 ollama list # 拉取一个特定的量化版本（名字冒号后面就是 tag） ollama pull llama3:8b-instruct-q4_1 ollama pull llama3:8b-instruct-q5_K_M ollama pull llama3:8b-instruct-q8_0
tag 里的后缀对应 llama.cpp 的量化方案：Q4_0 是最朴素的 4 位方案，每 32 个权重共用一组缩放系数；Q4_K_M 中的 K 指 K-quant，改用超级块结构，把缩放误差再压一层，_M 表示混合精度——注意力层这类敏感部位用 Q6K，其余用 Q4K，体积只多 5%，困惑度却明显好转。实际选型有一条经验法则：显存或内存够就上 Q5_K_M 或 Q6_K，紧巴巴就 Q4_K_M，Q8_0 几乎无损但通常只在评测对比时才值得。
权重之外还有一块容易被忽略的内存：KV 缓存。它随上下文长度线性膨胀，一个 8K 上下文的 8B 模型大约要额外吃掉 1GB 出头。所以估算部署容量时，正确的算式是"量化权重 + KV 缓存 + 激活临时区"，而不是只看模型文件多大。
GGUF：一个文件装下整个模型
GGUF 之前，社区先后用过 PyTorch pickle、GGML、GGMF、GGJT 等格式，每次换格式都伴随大量旧模型作废。GGUF 自 2023 年 8 月定名后承诺向后兼容，从此成为本地推理的事实标准。它的文件结构分四段：文件头写明版本与张量数量；元数据键值区存架构名、超参数、词表、聊天模板；张量信息区逐条记录每个张量的名字、类型和字节偏移；最后是连续排列的权重数据。
这种布局带来两个直接好处。第一，自包含——聊天模板、Stop token 这些过去散落在 tokenizer_config.json 里的东西全部进了元数据，ollama run 不需要任何外部配置就能正确对话。第二，可随机访问——张量偏移量在头部就已知，运行时用 mmap 把文件映射进地址空间，按需换页，首次加载大模型时不必把几十 GB 全部读进内存。
想验证元数据里到底存了什么，可以用 Python 直接解析：
# pip install gguf from gguf import GGUFReader reader = GGUFReader("path/to/model.gguf") for key in ["llama.context_length", "llama.embedding_length", "llama.block_count", "tokenizer.ggml.model"]: field = reader.get_field(key) print(key, "=>", field.parts[field.types[0]] if field else "N/A") # 遍历部分张量，看看量化类型分布 for tensor in list(reader.tensors.values())[:10]: print(tensor.name, tensor.tensor_type, tensor.shape)
对 Ollama 用户而言，理解 GGUF 的意义在于打通了"手动获取模型"这条路：任何 Hugging Face 上的 GGUF 仓库，都可以写一个两行的 Modelfile 引入本地文件，绕过官方模型库的限制（第 3.2 节会展开）。
推理内核：从 token 到吐字的完整链路
Ollama 的计算核心是内嵌的 llama.cpp。一次对话请求在内核里经历五个阶段：词元化（tokenizer 把输入切成 token 序列）→ 预填充（prompt 的所有 token 一次性并行算完，填充 KV 缓存）→ 逐 token 解码（每生成一个 token 都要对全序列做注意力）→ 采样（按概率分布挑出下一个 token）→ 反词元化拼成文字返回。预填充是算力密集型，解码是带宽密集型——这个区别解释了本地推理的两种典型手感：首字等待久但后续流畅（预填充慢、解码快），或首字快但每字都卡（显存带宽不足，解码被拖死）。
针对这两段，llama.cpp 各有武器。解码端的核心优化是把注意力计算改写为 Flash Attention 风格的分块算法，避免显式生成完整注意力矩阵，KV 缓存也从每头两个矩阵改为打包布局，配合 KV 量化可再省一半缓存内存。Ollama 0.5.13 起默认尝试启用，老版本可用环境变量打开：
# macOS / Linux OLLAMA_FLASH_ATTENTION=1 ollama serve # Windows PowerShell $env:OLLAMA_FLASH_ATTENTION=1; ollama serve # 同时开启 KV 缓存 8 位量化（需 Flash Attention 先行开启） OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve
CPU 侧，内核按指令集编译了 AVX、AVX2、AVX-512、ARM NEON 等多套算子，启动时自动探测并挑选最快路径；Apple Silicon 上则走 Metal，直接吃统一内存。这也是同一份 GGUF 在不同机器上速度差异巨大的原因之一。
后端调度：模型加载与换入换出
Ollama server 内部维护一个模型加载器，它的行为由两个参数控制：OLLAMA_MAX_LOADED_MODELS（最多同时驻留几个模型，默认 1，Apple Silicon 默认 3）与 OLLAMA_KEEP_ALIVE（模型卸载前的空转保留时长，默认 5m）。默认配置下的体验是：第一次 ollama run qwen2.5:7b 要等十几秒加载，随后 5 分钟内再问就秒回；超过 5 分钟，权重被释放，下次又要付一次加载成本。
多模型场景的换页逻辑值得细看。假设限制为 1，你先加载了 A 模型，接着请求 B：调度器会先把 A 完整卸载，腾出空间再装 B，而不是尝试挤在一起导致两者都 OOM。代价是交替使用两个模型时每次都要重新加载。把上限调到 2（前提是内存装得下两份权重加 KV 缓存），交替就变成即时切换：
# 允许同时驻留 2 个模型，空转保留 30 分钟 OLLAMA_MAX_LOADED_MODELS=2 OLLAMA_KEEP_ALIVE=30m ollama serve # 也可以在 API 请求里按次覆盖 keep_alive curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释熵", "keep_alive": "-1" }'
keep_alive: -1 表示常驻不卸载，适合你独占这台机器跑长期服务；反过来设 0 就是用完即释放，适合内存紧张的共享环境。
层分配是调度器的另一半工作。LLM 的几十个 transformer 层既可以全部放 GPU，也可以留一部分给 CPU。num_gpu（API 里叫 num_gpu，CLI 里对应 ollama run --numgpu）控制送去 GPU 的层数。直觉上"全上 GPU 一定快"并不总成立：当显存装不下全部层和 KV 缓存时，强行全上会导致频繁在显存和内存之间倒腾数据，速度反而不如"GPU 放 N-4 层、其余留 CPU"的稳定切分。Ollama 启动时会自动探测并给一个保守默认值，遇到显存临界的情况可以手动微调：
ollama run llama3.1:8b --numgpu 26
三层机制如何互相成全
量化决定权重多小，KV 缓存策略决定上下文多省，调度决定资源怎么分——三者拼在一起，才凑出"消费级硬件跑大模型"这件事。举个完整的账：16GB 内存的 MacBook 想跑 8B 模型，Q4_K_M 权重约 4.9GB，开 Flash Attention 后 8K 上下文的 KV 缓存约 1.1GB，加上系统与其他进程，还剩充裕余量；若硬上 Q8_0，权重 8.5GB 加缓存，系统一紧张就开始 swap，体感直接崩掉。选对量化档位，常常比换硬件更有效。
下一节转向另一条主线：同一套机制如何分别落在 macOS、Linux、Windows 三种系统上，以及 GPU 探测失败时该按什么顺序排查。