Ollama 底层的 llama.cpp 和 GGUF

GGUF = 大模型权重的「通用压缩格式」(类似视频的 MP4,适配所有播放器)
llama.cpp = 跑 GGUF 格式模型的「轻量级推理引擎」(类似视频播放器,能在低配电脑上流畅播 MP4)
两者配合:GGUF 让模型体积变小、适配性强,llama.cpp 让模型能在 CPU / 低配 GPU 上快速跑
这也是 Ollama 能做到 “一键本地运行” 的底层原因

GGUF 详解:大模型的 “通用压缩包”

核心定义

GGUF(Generic GGML Format)是 GGML 格式的升级版,是专门为大模型权重设计的二进制存储格式
核心目标是「通用、高效、压缩」

GGML 是什么?
GGML 最初是 Georgi Gerganov 为 llama.cpp 开发的轻量级机器学习张量库(核心是为 CPU 优化),早期大模型量化权重格式直接叫「GGML 格式」,但这个格式只适配 llama.cpp,通用性差

GGUF 为什么是 “升级版”?
随着 llama.cpp 支持的模型越来越多(Llama、Qwen、Phi 等),原 GGML 格式的局限性暴露(比如不支持多模态、跨框架适配差)
因此在 2023 年底推出 GGUF,把 “专属格式” 升级为 “通用格式”,全称里加「Generic」就是为了突出 “通用” 这个核心升级点

GGUF 的命名在 llama.cpp 官方仓库(https://github.com/ggerganov/llama.cpp)的 GGUF 规范文档中明确标注为「Generic GGML Format」

为什么需要 GGUF

早期大模型权重格式(如 PyTorch 的 .pth、Hugging Face 的 .bin)有如下问题:

  • 体积大:7B 模型原生权重约 13GB,普通电脑装不下
  • 适配差:不同推理框架(llama.cpp/transformers)需要转格式,门槛高
  • 速度慢:原生权重不做优化,CPU 推理卡成幻灯片

GGUF 针对性解决

量化压缩 支持 4bit/8bit/16bit 量化,7B 模型从 13GB → 4GB(4bit) 低配电脑(8G 内存)也能装下
通用适配 所有主流大模型(Llama 3/Qwen/Phi 3)都能转 GGUF,所有推理框架(llama.cpp/Ollama)都能读,不用为不同模型/框架反复转格式
加载加速 预编译权重结构,模型启动时间从分钟级 → 秒级,本地调用模型响应更快
跨平台 兼容 Windows/Mac/Linux/ 树莓派,甚至手机,任何设备都能跑

  1. 实战关联:Ollama 里的 GGUF
    Ollama 下载的所有模型(如 llama3:7b),底层都是 GGUF 量化格式(默认 4bit/8bit),这也是它能在 Mac M1 / 老旧电脑上运行的关键

llama.cpp 详解:跑 GGUF 模型的 “轻量级引擎”

核心定义

llama.cpp 是由开发者 Georgi Gerganov 开源的 C/C++ 编写的大模型推理框架
最初只为跑 Llama 模型设计,现在支持所有 GGUF 格式的模型(Llama 3、Qwen、Gemini 等)

核心优势(为什么 Ollama 选它做底层)

优势 具体效果 对应 Ollama 的表现
纯 CPU 友好 极致优化 CPU 推理(用 SIMD / 多线程),不用高端 GPU 也能跑 Ollama 不用装 CUDA,普通电脑直接运行
极简轻量化 无依赖(不用装 Python/PyTorch/TensorFlow),编译后就一个可执行文件 Ollama 一键安装,不用配复杂环境
支持 GGUF 原生支持 GGUF 量化格式,推理速度比原生权重快 2-5 倍 Ollama 模型启动快、响应快
跨平台 支持 x86/ARM 架构(Mac M 系列、树莓派、手机) Ollama 能跨 Windows/Mac/Linux 运行
低内存占用 4bit 量化的 7B 模型,仅需 4-6GB 内存就能跑 老旧笔记本也能跑大模型

极简使用示例

不用 Ollama,直接用 llama.cpp 跑 GGUF 模型的核心步骤:

# 1. 下载 llama.cppgit clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp &&make# 编译(仅需 C 编译器,无其他依赖)# 2. 下载 GGUF 格式的模型(比如 Llama 3 7B 4bit)wget https://xxx.com/llama-3-7b-instruct-q4_0.gguf # 3. 运行模型(纯 CPU,无需 GPU) ./main -m llama-3-7b-instruct-q4_0.gguf -p "解释一下 Agent 集群"

执行后就能在终端看到模型的推理结果,这就是 Ollama 底层的核心操作(Ollama 只是把这些步骤封装成了 ollama run 命令)

llama.cpp + GGUF 与 Ollama 的关系

用户 → Ollama(一键命令/API)→ llama.cpp(推理引擎)→ GGUF 模型(量化压缩的权重)→ 本地硬件(CPU/GPU)

Ollama 是「用户友好的封装层」:把复杂的 llama.cpp 命令、GGUF 模型下载 / 管理封装成简单指令
llama.cpp 是「推理执行层」:负责实际的模型计算、token 生成
GGUF 是「模型存储层」:让模型体积小、加载快、适配性强

和其他推理框架的对比

框架 / 格式 核心特点
GGUF + llama.cpp 轻量、纯 CPU、低内存、跨平台
Hugging Face Transformers 功能全、支持所有模型、GPU 优化好
vLLM 高吞吐、动态批处理、GPU 专用

框架 / 格式 适用场景 缺点
GGUF + llama.cpp 本地低配设备、离线运行、快速原型 推理速度比 GPU 框架慢(适合轻量场景)
Hugging Face Transformers 云端 / 高端 GPU 部署、复杂微调 依赖多、低配设备跑不动、体积大
vLLM 高并发 API 服务、云端部署 仅支持 GPU、低配设备用不了

总结
GGUF 是大模型权重的通用量化格式,核心价值是「压缩体积、通用适配、加载加速」,让低配设备装得下模型
llama.cpp 是轻量级推理引擎,核心价值是「纯 CPU 优化、极简无依赖、跨平台」,让低配设备跑得动模型
两者是 Ollama 实现 “本地一键运行大模型” 的底层核心,也是目前本地 AI 部署的主流技术组合

Read more

前端虚拟列表实现:别再渲染10000个DOM节点了

前端虚拟列表实现:别再渲染10000个DOM节点了

前端虚拟列表实现:别再渲染10000个DOM节点了 毒舌时刻 这代码写得跟网红滤镜似的——仅供参考。 各位前端同行,咱们今天聊聊前端虚拟列表。别告诉我你还在一次性渲染10000个列表项,那感觉就像把10000本书全部摆在桌面上——既占地方又难找。 为什么你需要虚拟列表 最近看到一个项目,一个下拉列表有5000个选项,全部渲染导致页面卡死,我差点当场去世。我就想问:你是在做列表还是在做性能杀手? 反面教材 // 反面教材:一次性渲染所有数据 function BigList({ items }) { return ( <ul style={{ height: '400px', overflow: 'auto' }}> {items.map(item => ( <li key={item.id} style={{ height: '50px'

前端 + agent 开发学习路线

背景:团队启动Agent项目,从零开始学习工程化AI开发 感谢ai老师写的学习指南。存档! 引言:从困惑到清晰 最近团队要启动Agent项目,我第一次接触这个概念时,只停留在“接入大模型API+优化Prompt”的浅层理解。经过大量学习和实践探索,我才发现工程化Agent开发是系统化的架构设计,而不仅仅是API调用。 这篇文章记录我从前端视角出发,探索Agent工程化开发的学习路径和实践经验。如果你也是前端/全栈开发者,想要在AI时代找到自己的定位,这篇指南应该能帮到你。 一、认知重塑:什么是工程化Agent? 1.1 我的错误认知 vs 现实 我原来的理解: Agent = 大模型API + Prompt优化 实际上的工程化Agent: Agent = 系统架构 + 可控执行 + 安全审查 + 领域适配 + 可观测性 1.2 Agent的分层架构(医疗场景示例) 你的主战场 任务分解器 工具路由器 记忆管理器 状态监控器

一文了解Blob文件格式,前端必备技能之一

一文了解Blob文件格式,前端必备技能之一

文章目录 * 前言 * 一、什么是Blob? * 二、Blob的基本特性 * 三、Blob的构造函数 * 四、常见使用场景 * 1. 文件下载 * 2. 图片预览 * 3. 大文件分片上传 * 四、Blob与其他API的关系 * 1. File API * 2. FileReader * 3. URL.createObjectURL() * 4. Response * 五、性能与内存管理 * 六、实际案例:导出Word文档 * 七、浏览器兼容性 * 八、总结 前言 最近在项目中需要导出文档时,我首次接触到了 Blob 文件格式。作为一个前端开发者,虽然经常听到 "Blob" 这个术语,但对其具体原理和应用场景并不十分了解。经过一番研究和实践,

Spring Boot携手Leaflet,点亮省级旅游口号WebGIS可视化之路

Spring Boot携手Leaflet,点亮省级旅游口号WebGIS可视化之路

目录 前言 一、旅游口号信息管理 1、写在前面的 2、空间属性关联 二、SpringBoot后台实现 1、系统调用时序图 2、Mapper数据查询实现 3、控制层接口实现 三、Leaflet集成实现WebGIS 1、省级数据展示及可视化 2、东北三省旅游口号 3、长三角城市群口号 4、珠三角旅游口号 5、西北地区旅游口号 四、总结 前言         在当今数字化浪潮汹涌澎湃的时代,地理信息系统(GIS)技术正以前所未有的速度改变着我们对世界的认知与探索方式。它不仅为科学研究提供了强大的工具,更在旅游、城市规划、环境保护等诸多领域展现出巨大的应用潜力。而当我们将目光聚焦于旅游行业,一个充满活力与创新的领域,GIS技术的应用更是如鱼得水,为旅游体验的提升和旅        游管理的优化带来了全新的机遇。         省级旅游口号作为各地旅游宣传的重要名片,承载着地域文化的精髓与旅游资源的亮点,是吸引游客、塑造旅游品牌形象的关键要素。然而,传统的旅游口号宣传方式往往局限于文字、