之前有朋友问我本地跑大模型究竟是“有独显就行”还是“随便一台轻薄本也能凑合”这个问题看起来简单但背后的差距远不止“快一点”和“慢一点”这么简单。它涉及显存容量、显存带宽、量化策略、推理框架调度等多个环节。这篇文章就用一个真实对比场景展开同一套开源 LLM分别跑在配备 RTX 5070 Laptop 独显的笔记本和只有 iGPU 核显的笔记本上完整记录测试思路、关键命令、数据解读和调优方法。无论你手头是高端独显本还是只有核显的轻薄本都可以按这套流程自己测一遍找到最适合本机的本地 LLM 方案。1. 独显本和核显本跑本地 LLM差距到底在哪1.1 本地 LLM 是什么本地 LLM 指的是把开源大语言模型如 Qwen2.5、Llama 3、DeepSeek 等下载到自己的电脑上通过推理框架加载模型权重在本地完成对话、代码生成、摘要等任务。它和云端 API 的主要区别是数据不出本机、无按 token 计费、可离线使用同时需要自己准备算力和存储资源。过去几年开源模型的体积和门槛一直在下降。一个 7B70 亿参数模型经过 4-bit 量化后权重体积大约只有 4~5GB普通中端笔记本已经有条件加载。但“能加载”和“跑得流畅”完全是两回事这里的核心瓶颈就是 GPU。1.2 GPU 在 LLM 推理中扮演什么角色大模型推理可以拆成两个阶段Prefill预填充和 Decode解码。Prefill 阶段一次性处理用户输入的 prompt属于计算密集任务需要大量矩阵乘法和并行计算Decode 阶段则逐个生成 token每一步都要把模型全部权重从显存读出来参与计算。在实际体验中Decode 阶段的速度直接决定了“每秒能输出多少个字”也就是我们常说的 token/s。而这个阶段对“显存带宽”极其敏感。简单说显存带宽越高每秒能读出的权重越多生成速度就越快。1.3 RTX 5070 Laptop 与 iGPU 的本质差异这里先把两台机器的硬件差异说清楚。RTX 5070 Laptop 属于独立显卡通常配备 8GB 独立 GDDR7 显存具体以笔记本厂商规格为准显存带宽远高于系统内存。它的特点是容量够装中小规模量化模型带宽够支撑较快的 token 生成速度而且不占用系统内存。iGPU 则是集成在 CPU 内部的显卡比如 AMD Radeon 780M/880M、Intel Arc 核显。它没有独立显存必须共享系统内存。也就是说核显“显存”的大小取决于你给系统分配多少内存带宽也受限于 DDR5/LPDDR5 系统内存的传输速度。对比维度RTX 5070 LaptopiGPU 核显显存类型独立 GDDR7 显存共享系统内存典型容量8GB以具体机型为准由系统内存分配决定带宽来源显存专用通道带宽高系统内存通道带宽低是否会挤占内存不会会占用一部分系统内存适合模型规模7B~14B 量化模型较合适1B~7B 量化模型需谨慎从这张表能看出独显和核显的差距并不只是“性能高低”而是“能不能装下”“装下后跑多快”两个层面的问题。2. 测试前的环境准备与硬件识别2.1 测试环境说明我的测试大致是两台 Windows 11 笔记本独显本RTX 5070 Laptop 8GB 显存搭配 32GB DDR5 系统内存。核显本Radeon 780M 核显搭配 32GB LPDDR5X 双通道内存。之所以给两台机器都配 32GB 内存是为了尽量排除“内存不够”对模型加载的影响让对比聚焦在 GPU 本身的差距上。如果你的内存容量不同或者核显平台是 Intel Arc整体结论方向一致但具体数值会有差异。软件方面我准备了三个常用的推理工具Ollama安装简单适合快速跑模型。LM Studio图形化界面对核显支持友好。llama.cpp 的 llama-bench用于标准化的基准测试。这些工具在 Windows 和 Linux 下都能用本文以 Windows 为例。2.2 安装 Ollama、LM Studio、llama.cppOllama 的安装最简单直接去官网下载对应 Windows 安装包装完在终端输入ollama serve启动服务。ollama serveLM Studio 同样下载安装包即可安装后不需要额外配置环境变量图形界面里可以选择模型并查看运行状态。llama.cpp 主要用于跑基准测试。你可以下载官方发布的预编译版本也可以自己用 CMake 构建核显用户建议开启 Vulkan 后端cmake -B build -DGGML_VULKANON cmake --build build --config Release构建完成后build/bin 目录下会有llama-bench.exe。2.3 确认 GPU 是否被正确识别在开始测试前必须先确认系统到底有没有识别到对应 GPU否则推理可能静默回退到 CPU速度会非常惨。NVIDIA 独显用nvidia-smi查看nvidia-smi能看到类似下面的输出就说明独显和驱动正常----------------------------------------------------------------------------------------- | NVIDIA-SMI 驱动版本 ... CUDA Version: 12.x | ----------------------------------------------------------------------------------------- | 0 NVIDIA GeForce RTX 5070 Laptop GPU ... | -----------------------------------------------------------------------------------------核显则可以通过 PowerShell 查看Get-CimInstance Win32_VideoController | Select-Object Name, AdapterRAM如果只想快速确认 Ollama 用的是哪块 GPU可以先设置调试日志再启动 Ollamasetx OLLAMA_DEBUG 1 ollama serve日志里会打印检测到的 GPU 信息。如果日志显示走了 CPU 而不是 GPU通常就是驱动或后端支持的问题下文第 5 章会专门讲。2.4 准备测试模型为了做公平对比我选择同一个模型文件的同一份量化版本。这里以阿里巴巴开源的 Qwen2.5 7B Instruct 为例它在中文场景表现稳定量化后体积适中独显和核显都有机会加载。先通过 Ollama 拉取ollama pull qwen2.5:7b也可以从 Hugging Face 下载 GGUF 格式文件配合 llama.cpp 跑基准测试。需要注意的是ollama pull qwen2.5:7b默认拉取的量化版本体积约 4.9GB适合 8GB 显存和 32GB 内存的测试环境。3. 核心原理LLM 推理为什么看显存带宽3.1 自回归解码每个 token 都要重新读一遍权重大模型生成文本是自回归过程每生成一个 token都要把模型全部权重从显存读一遍然后做一次前向计算。假设模型是 70 亿参数即使按 4-bit 量化每个参数平均约 0.5~0.6 字节一次前向计算也要读取 4~5GB 数据。如果生成 100 个 token就要读取 400~500GB 数据。这个数据量是固定的和 GPU 的算力关系不大瓶颈在于内存带宽。因此大模型推理尤其是长文本输出场景几乎可以看作一个“读显存”密集型任务。3.2 量化把模型“压缩”进显存既然每个 token 都要读一遍权重那权重体积越小速度就越快对显存容量的要求也越低。这就是量化存在的意义。量化格式7B 模型大约体积特点FP16约 14GB精度最高体积大一倍Q8_0约 7.8GB精度较高体积适中Q4_K_M约 4.4GB体积小质量损失可接受使用最广对台式机和高端显卡来说FP16 也许可行但在笔记本 8GB 显存的环境下7B 模型必须量化才能装下。这也是为什么本地部署 LLM 时第一件事就是确认模型的量化格式。3.3 用显存带宽估算理论 token/sDecode 阶段的理论速度可以粗略估算理论最大 token/s ≈ 显存带宽GB/s / 模型权重体积GB例如一个 7B Q4_K_M 模型权重约 4.4GB如果显存带宽是 120GB/s理论最快约 27 token/s。但实际运行时还有 KV Cache 读取、核函数调度、系统开销等损耗通常只能达到理论值的 40%~70%也就是 12~20 token/s 的真实水平。反过来看独显的显存带宽往往比双通道系统内存高数倍同样一个 4.4GB 模型理论 token/s 也会成倍提升。这就是独显在本地 LLM 场景下最核心的优势。3.4 iGPU 的共享内存瓶颈核显没有独立显存它使用系统内存作为显存。普通轻薄本双通道 LPDDR5X/DDR5 的带宽通常在 90~120GB/s 级别和 GDDR7 独显相比有明显差距。这就导致即使核显能把模型完整加载进去Decode 速度也会明显受限。更关键的是核显和 CPU 共享同一条内存总线。如果你一边跑模型一边开浏览器、编译代码内存带宽竞争会让推理速度进一步下降。这也是核显跑本地 LLM 体验不稳定的原因之一。4. 同一模型在两台机器上的实测4.1 测试方案固定模型、固定上下文为了让对比有意义必须控制变量同一份模型Qwen2.5 7B Instruct Q4_K_M。同一套提示词一段固定的长文本请求。相同上下文长度统一设置 num_ctx 为 8192。相同输出长度让模型生成固定长度的回复。只有这些变量保持一致速度差异才能归因到硬件层面。4.2 用 llama-bench 跑规范基准我用 llama.cpp 自带的 llama-bench 做了标准化测试。命令如下llama-bench -m qwen2.5-7b-instruct-q4_k_m.gguf -ngl 99 -p 512 -n 128参数含义-m指定 GGUF 模型文件路径。-ngl 99把模型尽可能多的层加载到 GPU99 表示全部交给 GPU。-p 512prompt 长度为 512 个 token。-n 128生成 128 个 token用于测 Decode 速度。输出会包含两项关键数据ppPrefill 阶段速度单位 token/s。tgText Generation 阶段速度也就是我们最关心的生成速度。在独显笔记本上tg数值会明显偏高在核显笔记本上tg会低不少如果驱动有问题甚至会出现tg只有个位数 token/s 的情况。4.3 用 Ollama 验证日常对话体验基准测试之外我还用 Ollama 模拟真实聊天场景。ollama run --verbose qwen2.5:7b--verbose会在对话结束后打印本次运行的详细指标包括加载时间、eval count、eval rate 等。eval rate 就是实际输出的 token/s。如果希望上下文长度保持一致可以在对话中设置/set parameter num_ctx 8192 /save qwen2.5-8k这条命令把当前模型的上下文参数保存成一个新模型之后用ollama run qwen2.5-8k加载即可。4.4 需要重点看的指标指标含义影响Prefill 速度处理输入 prompt 的速度决定首段输出的等待时间Generation 速度生成 token 的速度决定打字流畅度首 token 延迟从提问到首个回复的时间影响交互感受显存/内存占用模型与 KV Cache 的总占用决定能否稳定运行是否会降频高负载时的频率变化影响长时间稳定性对话体验的直观感受是Generation 速度在 20 token/s 以上时文字输出基本连贯10 token/s 以下时会有明显的“一个字一个字往外蹦”的卡顿感。4.5 实测解读在本次环境中独显笔记本跑 Qwen2.5 7B Q4_K_M 的生成速度明显高于核显笔记本大致能实现“顺畅聊天”的体验核显笔记本虽然也能加载同一个模型但输出速度明显偏慢属于“能用但不够丝滑”的水平。如果切换到 1.5B 或 3B 小模型核显的体验会好很多因为模型体积变小内存带宽压力随之下降。这也印证了一个结论独显的价值不仅在于“性能强”更在于它能在保证速度的前提下运行更大的模型。5. 常见问题与排查5.1 问题速查表问题现象常见原因解决思路Ollama 不识别独显/核显驱动版本过低或后端不支持更新驱动查看 OLLAMA_DEBUG 日志iGPU 上跑了不久就 OOM共享显存不足或物理内存不足BIOS 调大 UMA减小上下文换小模型模型加载成功但速度极慢权重被回落到 CPU 计算用 nvidia-smi 确认显存占用用 -ngl 控制层数跑一会儿速度下降笔记本散热不足触发降频垫高机身开性能模式降低任务强度LM Studio 看不到核显Vulkan 后端未初始化更新显卡驱动检查 LM Studio 的后端设置Ollama 默认拉取的模型太大默认量化选择不合适手动选择其他量化版本或更小参数模型5.2 Ollama 识别不到 iGPU 怎么办Ollama 对 NVIDIA 独显的支持比较成熟走 CUDA 路径对 AMD 核显或 Intel 核显的支持则依赖较新的驱动和 Vulkan 后端。如果你发现核显本上 Ollama 完全走了 CPU先做两件事第一更新核显驱动到最新版本。第二打开调试日志setx OLLAMA_DEBUG 1 ollama serve日志里会出现 “Looking for compatible GPU” 之类的信息。如果仍然识别不到核显更稳妥的方案是改用 LM Studio它面向 Vulkan 的后端对核显支持更好图形界面也直观。或者使用 llama.cpp 的 Vulkan 预编译版本手动指定 GPU。5.3 共享显存不足 / BIOS 分配问题iGPU 的“显存”虽然可以动态使用系统内存但部分笔记本 BIOS 允许设置 UMA Frame Buffer Size默认可能只有 512MB 或 1GB。这会导致核显只能在很小范围内分配显存模型加载稍大就失败。解决办法是进入 BIOS找到 Graphics Configuration 或 UMA Frame Buffer Size设置为 Auto 或 8GB。如果你的笔记本物理内存只有 16GB跑 7B 模型会比较吃力优先考虑 3B 以下小模型。5.4 模型加载后速度突然变慢一种常见情况是模型看起来加载成功了但运行时把大部分层放在了 CPU 上GPU 只负责了少量层。此时nvidia-smi能看到显存占用很小GPU 利用率也不高。在 llama.cpp 中可以使用-ngl参数控制 GPU 层数。在 Ollama 中则需要确认驱动和后端是否正常必要时用 LM Studio 手动开启 “GPU Offload” 并拖到最大值。另一种情况是核显和 CPU 共用内存总线后台任务过多导致内存带宽被抢占关闭无关应用后再试即可。6. 最佳实践不同硬件下如何用好本地 LLM6.1 先算账再选模型选模型之前先根据显存容量算一笔账可用的显存/内存预算 总显存 - 系统开销 - KV Cache 预留对 8GB 独显的笔记本推荐 Q4_K_M 量化后的 7B~8B 模型。14B 模型量化后通常超过 8GB强行加载容易溢出需要非常小心地缩短上下文。对共享内存的核显笔记本建议以 1B~3B 小模型为主优先保证流畅度。32GB 内存的机器可以尝试 7B Q4但要做好“能跑但偏慢”的心理准备。6.2 上下文长度不是越大越好很多人喜欢把上下文设到 32K但 KV Cache 会随着上下文长度线性增长占用大量显存。上下文越长Decode 阶段读取的数据量越大生成速度也会下降。实际使用建议日常问答 4K~8K 足够代码分析和长文档阅读再考虑 16K。每增加一档上下文长度都要留意显存占用变化。6.3 量化格式怎么选Q4_K_M日常首选。体积小、速度均衡、质量损失小。Q8_0对质量敏感且显存足够时使用速度会略慢于 Q4。FP16适合显存富裕的桌面级显卡笔记本 8GB 显存环境下一般不推荐。如果你的任务是代码生成、数学推理等对精度较敏感的领域可以先用 Q4_K_M 跑通流程再用 Q8_0 对比结果质量选择可接受的最低量化等级。6.4 硬件与系统侧的优化笔记本跑本地 LLM散热和供电比台式机更敏感。以下是亲测有效的几点全程插电运行避免电池供电触发降频。开启系统“最佳性能”电源模式。独显本优先使用 NVIDIA 独立显卡运行推理在 Windows 图形设置中可以指定具体应用使用哪块 GPU。核显本尽量不要在推理时开大量浏览器标签页或大型编译任务避免抢占内存带宽。定期更新 GPU 驱动新的 Vulkan/CUDA 后端可能有性能修复。6.5 iGPU 用户的务实方案如果你只有核显笔记本不要追求大模型。更合理的方向是选择 1B~3B 小模型比如 Qwen2.5 1.5B/3B、Llama 3.2 1B/3B。用 LM Studio 开启 Vulkan 后端尽量把层数全部加载到 GPU。上下文控制在 4096 以内减少 KV Cache 压力。对速度要求不高、只做离线摘要和问答时7B 模型也可以尝试。换句话说核显本适合“轻量本地推理”而需要稳定流畅对话体验时独显本仍然是更值得投入的方向。7. 总结与下一步这次对比让我对“本地 LLM 跑在什么硬件上”有了更清晰的认识。iGPU 并不是不能跑 LLM只是在小模型、短上下文、低并发的前提下才比较实用RTX 5070 这类独显则有能力在更舒适的 token/s 下运行 7B 甚至更大的模型这是核显难以替代的。如果你也想在笔记本上部署本地 LLM建议先按本文的流程跑一遍llama-bench拿到自己机器的真实数据再决定模型规模和量化方案。测试时也要留意显存占用、上下文长度、散热状态这些容易被忽略的变量。下一步可以继续研究的方向包括GGUF 量化的具体原理、KV Cache 对长文本的影响、Vulkan 与 CUDA 后端的差异以及如何用 Open WebUI 把自己的本地模型包装成可多人使用的服务。硬件只是起点真正决定体验的是对推理链路每个环节的理解。
独显与核显跑本地大模型：显存带宽、量化与推理框架实测对比
之前有朋友问我本地跑大模型究竟是“有独显就行”还是“随便一台轻薄本也能凑合”这个问题看起来简单但背后的差距远不止“快一点”和“慢一点”这么简单。它涉及显存容量、显存带宽、量化策略、推理框架调度等多个环节。这篇文章就用一个真实对比场景展开同一套开源 LLM分别跑在配备 RTX 5070 Laptop 独显的笔记本和只有 iGPU 核显的笔记本上完整记录测试思路、关键命令、数据解读和调优方法。无论你手头是高端独显本还是只有核显的轻薄本都可以按这套流程自己测一遍找到最适合本机的本地 LLM 方案。1. 独显本和核显本跑本地 LLM差距到底在哪1.1 本地 LLM 是什么本地 LLM 指的是把开源大语言模型如 Qwen2.5、Llama 3、DeepSeek 等下载到自己的电脑上通过推理框架加载模型权重在本地完成对话、代码生成、摘要等任务。它和云端 API 的主要区别是数据不出本机、无按 token 计费、可离线使用同时需要自己准备算力和存储资源。过去几年开源模型的体积和门槛一直在下降。一个 7B70 亿参数模型经过 4-bit 量化后权重体积大约只有 4~5GB普通中端笔记本已经有条件加载。但“能加载”和“跑得流畅”完全是两回事这里的核心瓶颈就是 GPU。1.2 GPU 在 LLM 推理中扮演什么角色大模型推理可以拆成两个阶段Prefill预填充和 Decode解码。Prefill 阶段一次性处理用户输入的 prompt属于计算密集任务需要大量矩阵乘法和并行计算Decode 阶段则逐个生成 token每一步都要把模型全部权重从显存读出来参与计算。在实际体验中Decode 阶段的速度直接决定了“每秒能输出多少个字”也就是我们常说的 token/s。而这个阶段对“显存带宽”极其敏感。简单说显存带宽越高每秒能读出的权重越多生成速度就越快。1.3 RTX 5070 Laptop 与 iGPU 的本质差异这里先把两台机器的硬件差异说清楚。RTX 5070 Laptop 属于独立显卡通常配备 8GB 独立 GDDR7 显存具体以笔记本厂商规格为准显存带宽远高于系统内存。它的特点是容量够装中小规模量化模型带宽够支撑较快的 token 生成速度而且不占用系统内存。iGPU 则是集成在 CPU 内部的显卡比如 AMD Radeon 780M/880M、Intel Arc 核显。它没有独立显存必须共享系统内存。也就是说核显“显存”的大小取决于你给系统分配多少内存带宽也受限于 DDR5/LPDDR5 系统内存的传输速度。对比维度RTX 5070 LaptopiGPU 核显显存类型独立 GDDR7 显存共享系统内存典型容量8GB以具体机型为准由系统内存分配决定带宽来源显存专用通道带宽高系统内存通道带宽低是否会挤占内存不会会占用一部分系统内存适合模型规模7B~14B 量化模型较合适1B~7B 量化模型需谨慎从这张表能看出独显和核显的差距并不只是“性能高低”而是“能不能装下”“装下后跑多快”两个层面的问题。2. 测试前的环境准备与硬件识别2.1 测试环境说明我的测试大致是两台 Windows 11 笔记本独显本RTX 5070 Laptop 8GB 显存搭配 32GB DDR5 系统内存。核显本Radeon 780M 核显搭配 32GB LPDDR5X 双通道内存。之所以给两台机器都配 32GB 内存是为了尽量排除“内存不够”对模型加载的影响让对比聚焦在 GPU 本身的差距上。如果你的内存容量不同或者核显平台是 Intel Arc整体结论方向一致但具体数值会有差异。软件方面我准备了三个常用的推理工具Ollama安装简单适合快速跑模型。LM Studio图形化界面对核显支持友好。llama.cpp 的 llama-bench用于标准化的基准测试。这些工具在 Windows 和 Linux 下都能用本文以 Windows 为例。2.2 安装 Ollama、LM Studio、llama.cppOllama 的安装最简单直接去官网下载对应 Windows 安装包装完在终端输入ollama serve启动服务。ollama serveLM Studio 同样下载安装包即可安装后不需要额外配置环境变量图形界面里可以选择模型并查看运行状态。llama.cpp 主要用于跑基准测试。你可以下载官方发布的预编译版本也可以自己用 CMake 构建核显用户建议开启 Vulkan 后端cmake -B build -DGGML_VULKANON cmake --build build --config Release构建完成后build/bin 目录下会有llama-bench.exe。2.3 确认 GPU 是否被正确识别在开始测试前必须先确认系统到底有没有识别到对应 GPU否则推理可能静默回退到 CPU速度会非常惨。NVIDIA 独显用nvidia-smi查看nvidia-smi能看到类似下面的输出就说明独显和驱动正常----------------------------------------------------------------------------------------- | NVIDIA-SMI 驱动版本 ... CUDA Version: 12.x | ----------------------------------------------------------------------------------------- | 0 NVIDIA GeForce RTX 5070 Laptop GPU ... | -----------------------------------------------------------------------------------------核显则可以通过 PowerShell 查看Get-CimInstance Win32_VideoController | Select-Object Name, AdapterRAM如果只想快速确认 Ollama 用的是哪块 GPU可以先设置调试日志再启动 Ollamasetx OLLAMA_DEBUG 1 ollama serve日志里会打印检测到的 GPU 信息。如果日志显示走了 CPU 而不是 GPU通常就是驱动或后端支持的问题下文第 5 章会专门讲。2.4 准备测试模型为了做公平对比我选择同一个模型文件的同一份量化版本。这里以阿里巴巴开源的 Qwen2.5 7B Instruct 为例它在中文场景表现稳定量化后体积适中独显和核显都有机会加载。先通过 Ollama 拉取ollama pull qwen2.5:7b也可以从 Hugging Face 下载 GGUF 格式文件配合 llama.cpp 跑基准测试。需要注意的是ollama pull qwen2.5:7b默认拉取的量化版本体积约 4.9GB适合 8GB 显存和 32GB 内存的测试环境。3. 核心原理LLM 推理为什么看显存带宽3.1 自回归解码每个 token 都要重新读一遍权重大模型生成文本是自回归过程每生成一个 token都要把模型全部权重从显存读一遍然后做一次前向计算。假设模型是 70 亿参数即使按 4-bit 量化每个参数平均约 0.5~0.6 字节一次前向计算也要读取 4~5GB 数据。如果生成 100 个 token就要读取 400~500GB 数据。这个数据量是固定的和 GPU 的算力关系不大瓶颈在于内存带宽。因此大模型推理尤其是长文本输出场景几乎可以看作一个“读显存”密集型任务。3.2 量化把模型“压缩”进显存既然每个 token 都要读一遍权重那权重体积越小速度就越快对显存容量的要求也越低。这就是量化存在的意义。量化格式7B 模型大约体积特点FP16约 14GB精度最高体积大一倍Q8_0约 7.8GB精度较高体积适中Q4_K_M约 4.4GB体积小质量损失可接受使用最广对台式机和高端显卡来说FP16 也许可行但在笔记本 8GB 显存的环境下7B 模型必须量化才能装下。这也是为什么本地部署 LLM 时第一件事就是确认模型的量化格式。3.3 用显存带宽估算理论 token/sDecode 阶段的理论速度可以粗略估算理论最大 token/s ≈ 显存带宽GB/s / 模型权重体积GB例如一个 7B Q4_K_M 模型权重约 4.4GB如果显存带宽是 120GB/s理论最快约 27 token/s。但实际运行时还有 KV Cache 读取、核函数调度、系统开销等损耗通常只能达到理论值的 40%~70%也就是 12~20 token/s 的真实水平。反过来看独显的显存带宽往往比双通道系统内存高数倍同样一个 4.4GB 模型理论 token/s 也会成倍提升。这就是独显在本地 LLM 场景下最核心的优势。3.4 iGPU 的共享内存瓶颈核显没有独立显存它使用系统内存作为显存。普通轻薄本双通道 LPDDR5X/DDR5 的带宽通常在 90~120GB/s 级别和 GDDR7 独显相比有明显差距。这就导致即使核显能把模型完整加载进去Decode 速度也会明显受限。更关键的是核显和 CPU 共享同一条内存总线。如果你一边跑模型一边开浏览器、编译代码内存带宽竞争会让推理速度进一步下降。这也是核显跑本地 LLM 体验不稳定的原因之一。4. 同一模型在两台机器上的实测4.1 测试方案固定模型、固定上下文为了让对比有意义必须控制变量同一份模型Qwen2.5 7B Instruct Q4_K_M。同一套提示词一段固定的长文本请求。相同上下文长度统一设置 num_ctx 为 8192。相同输出长度让模型生成固定长度的回复。只有这些变量保持一致速度差异才能归因到硬件层面。4.2 用 llama-bench 跑规范基准我用 llama.cpp 自带的 llama-bench 做了标准化测试。命令如下llama-bench -m qwen2.5-7b-instruct-q4_k_m.gguf -ngl 99 -p 512 -n 128参数含义-m指定 GGUF 模型文件路径。-ngl 99把模型尽可能多的层加载到 GPU99 表示全部交给 GPU。-p 512prompt 长度为 512 个 token。-n 128生成 128 个 token用于测 Decode 速度。输出会包含两项关键数据ppPrefill 阶段速度单位 token/s。tgText Generation 阶段速度也就是我们最关心的生成速度。在独显笔记本上tg数值会明显偏高在核显笔记本上tg会低不少如果驱动有问题甚至会出现tg只有个位数 token/s 的情况。4.3 用 Ollama 验证日常对话体验基准测试之外我还用 Ollama 模拟真实聊天场景。ollama run --verbose qwen2.5:7b--verbose会在对话结束后打印本次运行的详细指标包括加载时间、eval count、eval rate 等。eval rate 就是实际输出的 token/s。如果希望上下文长度保持一致可以在对话中设置/set parameter num_ctx 8192 /save qwen2.5-8k这条命令把当前模型的上下文参数保存成一个新模型之后用ollama run qwen2.5-8k加载即可。4.4 需要重点看的指标指标含义影响Prefill 速度处理输入 prompt 的速度决定首段输出的等待时间Generation 速度生成 token 的速度决定打字流畅度首 token 延迟从提问到首个回复的时间影响交互感受显存/内存占用模型与 KV Cache 的总占用决定能否稳定运行是否会降频高负载时的频率变化影响长时间稳定性对话体验的直观感受是Generation 速度在 20 token/s 以上时文字输出基本连贯10 token/s 以下时会有明显的“一个字一个字往外蹦”的卡顿感。4.5 实测解读在本次环境中独显笔记本跑 Qwen2.5 7B Q4_K_M 的生成速度明显高于核显笔记本大致能实现“顺畅聊天”的体验核显笔记本虽然也能加载同一个模型但输出速度明显偏慢属于“能用但不够丝滑”的水平。如果切换到 1.5B 或 3B 小模型核显的体验会好很多因为模型体积变小内存带宽压力随之下降。这也印证了一个结论独显的价值不仅在于“性能强”更在于它能在保证速度的前提下运行更大的模型。5. 常见问题与排查5.1 问题速查表问题现象常见原因解决思路Ollama 不识别独显/核显驱动版本过低或后端不支持更新驱动查看 OLLAMA_DEBUG 日志iGPU 上跑了不久就 OOM共享显存不足或物理内存不足BIOS 调大 UMA减小上下文换小模型模型加载成功但速度极慢权重被回落到 CPU 计算用 nvidia-smi 确认显存占用用 -ngl 控制层数跑一会儿速度下降笔记本散热不足触发降频垫高机身开性能模式降低任务强度LM Studio 看不到核显Vulkan 后端未初始化更新显卡驱动检查 LM Studio 的后端设置Ollama 默认拉取的模型太大默认量化选择不合适手动选择其他量化版本或更小参数模型5.2 Ollama 识别不到 iGPU 怎么办Ollama 对 NVIDIA 独显的支持比较成熟走 CUDA 路径对 AMD 核显或 Intel 核显的支持则依赖较新的驱动和 Vulkan 后端。如果你发现核显本上 Ollama 完全走了 CPU先做两件事第一更新核显驱动到最新版本。第二打开调试日志setx OLLAMA_DEBUG 1 ollama serve日志里会出现 “Looking for compatible GPU” 之类的信息。如果仍然识别不到核显更稳妥的方案是改用 LM Studio它面向 Vulkan 的后端对核显支持更好图形界面也直观。或者使用 llama.cpp 的 Vulkan 预编译版本手动指定 GPU。5.3 共享显存不足 / BIOS 分配问题iGPU 的“显存”虽然可以动态使用系统内存但部分笔记本 BIOS 允许设置 UMA Frame Buffer Size默认可能只有 512MB 或 1GB。这会导致核显只能在很小范围内分配显存模型加载稍大就失败。解决办法是进入 BIOS找到 Graphics Configuration 或 UMA Frame Buffer Size设置为 Auto 或 8GB。如果你的笔记本物理内存只有 16GB跑 7B 模型会比较吃力优先考虑 3B 以下小模型。5.4 模型加载后速度突然变慢一种常见情况是模型看起来加载成功了但运行时把大部分层放在了 CPU 上GPU 只负责了少量层。此时nvidia-smi能看到显存占用很小GPU 利用率也不高。在 llama.cpp 中可以使用-ngl参数控制 GPU 层数。在 Ollama 中则需要确认驱动和后端是否正常必要时用 LM Studio 手动开启 “GPU Offload” 并拖到最大值。另一种情况是核显和 CPU 共用内存总线后台任务过多导致内存带宽被抢占关闭无关应用后再试即可。6. 最佳实践不同硬件下如何用好本地 LLM6.1 先算账再选模型选模型之前先根据显存容量算一笔账可用的显存/内存预算 总显存 - 系统开销 - KV Cache 预留对 8GB 独显的笔记本推荐 Q4_K_M 量化后的 7B~8B 模型。14B 模型量化后通常超过 8GB强行加载容易溢出需要非常小心地缩短上下文。对共享内存的核显笔记本建议以 1B~3B 小模型为主优先保证流畅度。32GB 内存的机器可以尝试 7B Q4但要做好“能跑但偏慢”的心理准备。6.2 上下文长度不是越大越好很多人喜欢把上下文设到 32K但 KV Cache 会随着上下文长度线性增长占用大量显存。上下文越长Decode 阶段读取的数据量越大生成速度也会下降。实际使用建议日常问答 4K~8K 足够代码分析和长文档阅读再考虑 16K。每增加一档上下文长度都要留意显存占用变化。6.3 量化格式怎么选Q4_K_M日常首选。体积小、速度均衡、质量损失小。Q8_0对质量敏感且显存足够时使用速度会略慢于 Q4。FP16适合显存富裕的桌面级显卡笔记本 8GB 显存环境下一般不推荐。如果你的任务是代码生成、数学推理等对精度较敏感的领域可以先用 Q4_K_M 跑通流程再用 Q8_0 对比结果质量选择可接受的最低量化等级。6.4 硬件与系统侧的优化笔记本跑本地 LLM散热和供电比台式机更敏感。以下是亲测有效的几点全程插电运行避免电池供电触发降频。开启系统“最佳性能”电源模式。独显本优先使用 NVIDIA 独立显卡运行推理在 Windows 图形设置中可以指定具体应用使用哪块 GPU。核显本尽量不要在推理时开大量浏览器标签页或大型编译任务避免抢占内存带宽。定期更新 GPU 驱动新的 Vulkan/CUDA 后端可能有性能修复。6.5 iGPU 用户的务实方案如果你只有核显笔记本不要追求大模型。更合理的方向是选择 1B~3B 小模型比如 Qwen2.5 1.5B/3B、Llama 3.2 1B/3B。用 LM Studio 开启 Vulkan 后端尽量把层数全部加载到 GPU。上下文控制在 4096 以内减少 KV Cache 压力。对速度要求不高、只做离线摘要和问答时7B 模型也可以尝试。换句话说核显本适合“轻量本地推理”而需要稳定流畅对话体验时独显本仍然是更值得投入的方向。7. 总结与下一步这次对比让我对“本地 LLM 跑在什么硬件上”有了更清晰的认识。iGPU 并不是不能跑 LLM只是在小模型、短上下文、低并发的前提下才比较实用RTX 5070 这类独显则有能力在更舒适的 token/s 下运行 7B 甚至更大的模型这是核显难以替代的。如果你也想在笔记本上部署本地 LLM建议先按本文的流程跑一遍llama-bench拿到自己机器的真实数据再决定模型规模和量化方案。测试时也要留意显存占用、上下文长度、散热状态这些容易被忽略的变量。下一步可以继续研究的方向包括GGUF 量化的具体原理、KV Cache 对长文本的影响、Vulkan 与 CUDA 后端的差异以及如何用 Open WebUI 把自己的本地模型包装成可多人使用的服务。硬件只是起点真正决定体验的是对推理链路每个环节的理解。