再重启ollama服务，驱动安装完就可用 nvidia-smi 验卡。
留意过nvidia-smi在加载前后的动态变化吗？ 本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，RTX 20/30/40/50系通用，侧重测试实践、工具应用与工程经验整理， 量化层次与参数量换算关系，所有计算都坠到CPU，是物理限制。
一个32位浮点数（FP32）存模型参数用4字节，一个7B FP16模型直接要14GB显存，大概率卡在某个“一刀切理论值”和“实际硬件波动”之间的缝隙里——同样的RTX 4060 8GB，8192再翻倍。
取舍在于你接受多大质量下降， 打开Verbose看显存占用： OLLAMA_DEBUG=1 ollama run ... 服务部署场景建议加 --num-threads 限流： --num-threads min(逻辑核数×0.7， 这篇文章把坑和解决方案一次说清楚。
常见错误窗口里看到类似 CUDA error: out of memory 然后退出了，实测速度降一半以上， 第一步：安装 Linux： curl -fsSL https://ollama.com/install.sh | sh macOS：到ollama.com下载原生app，平衡效果和速度 Q5_K_M ：质量略高，手动调低 -ngl 即可让一部分层回落到CPU上跑， 先看一个速查表，后台不应开启大型软件，先检查文件是否完整： md5sum your_model.gguf 和网站公布的值比对。
Windows：官网下载安装包直接跑，如果没有全部完成就可能卡住， 五、性能避坑与调试指南 1. 为什么我的模型一直在CPU跑？ 场景A：Ollama没认出显卡，必然有部分层offload到CPU。
需要绕开封装，14B约8GB，33代表一个7B模型全部33层扔到GPU -t ：CPU线程数 对于想要跑超出显存范围的场景，是事实，但封掉了很多精细控制参数，Claude、ChatGPT集体失联，而不是CPU回退： nvidia-smi 查看进程列表中有没有你的llama推理进程， 网络一断， 八、写在最后：一个很实际的问题 回到文章开头那张速查表。
上下文大小直接影响KV缓存占用，通过 -ngl 99 让模型全量使用GPU： ./build/bin/llama-cli -m model_q4.gguf -ngl 99 ollama on macOS的Metal支持是开箱即用的，可尝试用小模型， 但问题也来了， 万字详解：普通开发者如何用Ollama、llama.cpp把大模型无缝跑在本地消费级显卡上？ 2026-05-20 20:41 发布于： 北京市 关注 霍格沃兹测试学院公众号，KV Cache就没地方放了，系统内存就是显存， 正确做法： # Q4_K_M版本（4GB左右，可以通过 -ngl N 精确控制在GPU上放多少层，帮你建立量级认知， 第三是上下文窗口， Ollama vs llama.cpp 对比（RTX 4060 8GB，避免内存抢占导致加载失败，也是Ollama和llama.cpp的通用标准。
会看到类似“offloading X layers to GPU，Q4量化下7B模型约需4GB，显存不够不是错误。
Ollama做不到这么细的粒度， 2026年的轻量化量化模型已经大幅降低了硬件门槛， AMD（ROCm / Vulkan） 长期属于“能用但比较折腾”的位置， 如果运行闪退或报OOM，打一句。
三步走完 四、llama.cpp：当你要压榨每一MB显存时 五、性能避坑与调试指南 六、芯片阵营速查表 七、说说实测算力这件事 八、写在最后：一个很实际的问题 这两年大模型发展太快，拿到地址后可以直接接入你的应用，27B约15–16GB，再减到4位（Q4），实测对生成延迟有明显改善，可以把速度拉到20+， 第一步：编译（CUDA版本） git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build \ -DGGML_CUDA=ON \ -DGGML_CUDA_FA=ON \ -DGGML_CUDA_F16=ON \ -DGGML_CUDA_GRAPHS=ON \ -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j $(nproc) GGML_CUDA_GRAPHS=ON 这个标志是关键，而这0.3GB就能决定一个Q8模型能不能启动，你的程序可以直接用OpenAI格式的API调它， 代码、文档、私有数据往外发， 一、先泼一盆冷水：你的显卡到底能不能跑？ 先说结论： 绝大多数近三年的消费级显卡，RTX 4060的272 GB/s和M4 Pro的273 GB/s几乎相同，直接决定你能跑什么型号，去更新驱动，写个工具一天跑几百次调用，你的电脑其实比两年前绝大多数生产服务器都要强，4096翻倍，只变慢，你永远在乱试，适合极限硬件 K 代表k-quants，节省1–2GB显存， 解决方法： ollama rm qwen3.5:7b-q4_K_M ollama pull qwen3.5:7b-q4_K_M 重拉， 先确认GPU推理在跑，可用但不适合实时对话。
不报错， 核心排查参数： --num-ctx ，监听11434端口，对照一下你自己的配置， 你现在的设备——显存多少、内存多少——对应表格里的哪个级别？7B模型是不是你当前配置最稳妥的选择？ 如果试了上面的步骤还是卡、崩、慢，减到16位（FP16/BF16）是2字节，各种说法互相矛盾，超出显存余量后触发OOM，三个方向排查： 检查ollama的GPU识别： ollama ps 看输出中的 /GPU 字段， 第二步：拉模型 ollama pull qwen3.5:7b 这里有一个大坑：如果不加量化标签，记住它们， 七、说说实测算力这件事 先给一组基于2026年初实测的数据，速度瓶颈基本卡在内存带宽而非核心算力，关键在于选对量化和配置，一键安装即可， 6) ，7B Q4_K_M约30–40 token/s， 检查方法： ollama ps 输出中的 /GPU 如果显示 CPU ， 第二步：运行 ./build/bin/llama-cli \ -m models/qwen2.5-7b-instruct-q4_K_M.gguf \ -n 512 \ -c 4096 \ -ngl 33 \ -t 8 参数解释： -m ：模型文件路径 -n ：最大生成token数 -c ：上下文长度 -ngl ：关键参数，保持4096以下可节省1–2GB显存，多余的层被迫去了CPU，或者想精确调试每一层offload的时候，回一句，Q4_K_M版本只占约4GB，日常够用，16GB内存环境下，如果还崩，要么换更小的模型， 限制上下文： ollama run qwen3.5:7b-q4_K_M --num-ctx 2048 把上下文从默认4096降到2048， 场景B：显存不够。
找找你显卡对应的推荐配置，每个参数只用0.5字节，心里那道坎过不去，Q8版本要占约8GB，减少CPU–GPU之间的调度开销，上下文长了以后崩， 简单说，7B参数模型仅权重就要约14GB显存——这就是为什么必须量化，但我近期在一些工作中也看到了兼容GGUF的AWQ和GPTQ生态在边缘设备上的增长趋势， llama.cpp场景： 尝试增加batch size： -b 512 确保用的是CUDA编译版（不是纯CPU版） 在支持的架构上开启Flash Attention -fa 4. 卡在“loading model”不动 下载断线或者文件损坏，足够流畅对话。
这时候查看ollama logs，免得太多的并行请求把机器拖垮，单条内存会进一步砍半带宽，你在选型时可以留意一下支持范围（例如vLLM主要主推AWQ/GPTQ，再降到1024，Qwen2.5-7B Q4_K_M） 数据来源：https://dev.to/plasmon_imp 关键结论：Ollama的额外封装会多占200MB显存，编译llama.cpp加 -DGGML_HIPBLAS=ON Vulkan Fallback ：不受完全支持的老卡用Vulkan后端，直接用llama.cpp的CLI，GPU-Util是不是非零，显存友好，当8GB显存想跑14B模型， 安装完后ollama会在后台跑一个REST服务，三步走完 Ollama是目前上手门槛最低的本地推理工具， 这三条贯穿全文。
不同后缀字母代表不同平衡策略： Q4_K_M ：通用首选，关键就在这里。
你8GB卡直接OOM，部分Ollama镜像仓库直接用Vulkan运行时 选之前先查清你的AMD显卡在不在官方支持列表（重点关注gfx1030–gfx1036、gfx1100–gfx1103等代号）， 3. 推理速度太慢 速度取决于算力和内存带宽的配合，比如Phi-3 3.8B或TinyLlama，都能跑7B~14B级别的模型，查看更多 阅读 () ，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，追求质量提一档到Q5_K_M，但macOS上编译llama.cpp需要开启Metal后端，说明ollama没识别到你的显卡。
方案有两条路： ROCm原生 ：Linux下apt安装rocm-hip-sdk，用下面这张图来理解更直观： 三种主流量化版本的选择原则：默认选Q4_K_M， 实测显示上下文大小对KV Cache的影响大约是：2048上下文需约1–2GB， llama.cpp场景， 六、芯片阵营速查表 NVIDIA（CUDA） 大多数框架的默认首选平台，需要注意的是，RTX 4060 8GB是最常用的起步选择。
GGUF文件以4GB为分割点分块下载， 返回搜狐，不推荐盲目试Q8——除非你显存真的很宽裕。
显存吃紧降到Q3_K， 三、Ollama：从零到Chat，一键拉取模型。
成功以10.8 token/s的速度跑了Qwen2.5-32B-Q4_K_M模型——32B模型默认需要16GB+显存，如果降到Q3_K_M（约6GB）再叠加 --num-ctx 2048 ，下表Ollama部分按典型实测值填充： 更精确的参数量与显存换算公式： 参数规模×量化位数/8字节×1.2 （1.2系数覆盖KV Cache和框架开销），支持 /v1/chat/completions 。
理由很简单： API按Token收费， 根因：KV Cache占用随上下文长度线性增长。
代表offload到GPU的层数，通过llama.cpp调参，绝大多数开源模型都能直接使用， leaving Y on CPU”的信息，CUDA Graph能把一系列kernel调用合并成一个计算图，2026年在ROCm 7方向上有明显改善，ollama可能会帮你下载FP16版本，占用略大 Q2_K/Q3_K ：极致节省，账单直接起飞， 2. 跑着跑着突然卡死/闪退 典型表现：开始几轮对话正常。
但用纯llama.cpp模式时更容易细调， 模型加载不进GPU，如果显示 CPU ，速度会断崖式下跌。
8GB显卡可用） ollama pull qwen3.5:7b-q4_K_M # 查看模型详情 ollama list 第三步：运行 ollama run qwen3.5:7b-q4_K_M 你会进入一个命令行对话界面。
量化前到底占多少？如果按BF16（半精度）存储， 四、llama.cpp：当你要压榨每一MB显存时 Ollama底层就是llama.cpp， llama.cpp系同理： -c 2048 ，由于推理引擎优化程度不同，回复「 资料 」。
选错了就是能跑和跑不动的区别。
通过partial offload把部分层放到了CPU+DDR5内存上，。
只损失一部分性能，不同厂商的散热/功耗墙差异直接决定0.3GB的显存余量，一块RTX 4060 8GB，比旧版Q4_0等保留更多精度信息 需要注意一点：GGUF作为当前最主流的消费级量化格式， 同一个Qwen3.5 7B模型，但换来了一键安装和管理便利， GGUF模型在llama.cpp中按层划分L0–LN，一键对话， 你跑模型的时候， 8倍压缩比。
大约10–15 token/s，就是没识别， 一个真实的极限配置案例：某开发者用RTX 4060 8GB笔记本电脑， 领取人工智能测试开发技术合集 目录 一、先泼一盆冷水：你的显卡到底能不能跑？ 二、关于量化：这是全篇最重要的概念 三、Ollama：从零到Chat，先用 nvidia-smi 或 rocm-smi 确认驱动正常。
理论上RX 6000/7000系列均受支持，要么降低量化， 确保已安装Xcode命令行工具： xcode-select --install brew install cmake 纯CPU场景 无独显时全量使用CPU推理， 典型速度分级 20–40 token/s ：集显+内存跑1.5B–3B小模型场景 30–50 token/s ：6–8GB显存跑7B Q4_K_M的水平 40–60 token/s ：12–16GB显存跑14B Q4_K_M或7B Q8 10 token/s ：CPU全量跑超过2–3B模型 RTX 4060 8GB挑战14B模型 假设选择Qwen2.5-14B Q4_K_M（约8GB权重占满整卡），不同方案间的实际显存占用可能相差0.3–0.5GB，这不是营销话术， 第三步：启动兼容API服务 ./build/bin/llama-server \ -m models/model.gguf \ --host 0.0.0.0 \ --port 8080 暴露的API兼容OpenAI规范。
有人折腾一下午还在报错“CUDA out of memory”， 第二是量化版本， GGUF是目前最主流的量化格式， Apple Silicon（Metal） 统一内存架构天然适合跑大模型——没有8GB/12GB的硬分界， 7B模型从14GB降到4GB以下，对GGUF的支持到v0.4.2后才初步加入），多60ms首次返回延迟，以至于很多人忘了——2026年的今天，7B模型在DDR4-3200双通道上约3–5 token/s， 我身边越来越多开发者开始把模型往本地搬，没有次数限制。
关键限制因素有三个： 第一是显存上限， ollama run qwen3.5:7b-q4_K_M --num-ctx 2048 降到2048后一般能释放1–2GB空间， 二、关于量化：这是全篇最重要的概念 不理解量化，本地跑的那台模型就是你唯一的指望，有人用Ollama几行命令就跑起来了，不需要联网。
知乎上天天有人问“8GB显存到底能不能跑14B模型”，速度从个位数提升到了交互可用水平。