RTX 5070与核显iGPU本地LLM推理性能对比：带宽决定体验

把同一个本地大语言模型LLM分别放到一台搭载 RTX 5070 独显的笔记本和一台只有集成显卡iGPU的轻薄本上运行体验差距到底有多大这个问题我在做设备选型和本地推理方案调研时反复遇到。很多人以为“能跑起来就差不多”实际上从安装配置到生成速度两台设备的差异可以用“代际”来形容。本文会完整记录这次对比的过程包括工具链选择、模型量化、GPU 卸载层数设置、速度估算方法以及核显跑 LLM 时最容易被忽略的瓶颈。如果你正在纠结要不要为本地 AI 推理买独显笔记本或者想在现有核显设备上榨出一点性能这篇文章可以作为一份参考。本文的对比会尽量保证公平同一个 GGUF 模型文件、同一个推理后端、相同的提示词和生成长度只在硬件不同的机器上运行。这样得出的差异才能反映硬件本身的区别而不是模型或参数设置带来的干扰。1. 背景本地 LLM 推理与硬件选型困惑1.1 本地 LLM 推理是什么本地 LLM 推理就是在大模型不联网、不调用云端 API 的前提下把模型文件下载到自己的电脑上通过推理引擎比如 llama.cpp、Ollama、LM Studio直接运行模型实现对话、文本生成、代码补全、摘要提取等能力。这类需求这几年增长很快。原因很直接云端 API 虽然强大但存在数据隐私、按量计费、网络依赖、接口限流等问题。很多开发者在处理内部文档、个人知识库、Agent 工具链时更希望把模型放在本地数据不出机器。这也让“本地部署”成为 LLM 应用开发中绕不开的一环。本地部署的体验关键有两个一是模型能不能完整加载二是生成速度快不快。前者取决于显存或内存容量后者取决于硬件带宽和算力。这两个因素正好是 RTX 5070 独显笔记本与 iGPU 核显笔记本差异最大的地方。1.2 为什么“同一个模型”在不同电脑上差异巨大LLM 推理和传统 CPU 计算任务不太一样。它虽然也需要算力但实际运行时会发现解码过程中真正卡住速度的往往不是 GPU 算得够不够快而是“参数能不能及时搬进 GPU 计算单元”。换句话说大模型推理在解码阶段是一个高度依赖内存带宽的任务。这个特性导致了一个反直觉的现象同样是 7B 参数的模型在 RTX 5070 独立显卡上可以做到几十 tokens/s交互起来几乎感觉不到卡顿但在 iGPU 核显上由于显存和系统内存共用一套 DDR 总线带宽被严重压缩生成速度可能只有个位数到十几 tokens/s每输出一个字都要等很久。很多用户第一次在核显笔记本上跑大模型时会误以为是模型太大或者工具装错了实际上核心原因就是内存带宽差异。理解这一点是读懂后面所有对比数据的前提。1.3 RTX 5070 与 iGPU 的核心差异RTX 5070 是 NVIDIA RTX 50 系列移动端独显采用 Blackwell 架构搭载独立 GDDR 显存。独立显卡的核心优势在于显存带宽远高于系统内存且有独立的显存容量不会挤占系统内存带宽。Blackwell 架构还对低精度推理做了优化后续使用 FP4 这类 4 位精度模型时硬件支持更有优势。iGPU集成显卡则集成在 CPU 内部没有独立显存运行时通过系统内存总线访问数据。它的显存其实是从系统内存中划分出来的一部分“共享显存”。这样一来iGPU 的“显存”容量可以很大取决于系统内存大小但访问速度受到内存总线带宽限制。下面用一张表概括两者的差异对比维度RTX 5070 笔记本独显iGPU 核显显存形态独立 GDDR 显存共享系统内存显存带宽通常达到数百 GB/s 量级受内存总线限制约 60~120 GB/s 量级显存容量通常 8GB 级别部分型号更高取决于系统内存16~64GB 均可算力独立 GPU 核心算力强集成在 CPU 中算力有限功耗更高需要独立散热低功耗适合轻薄本适用场景高吞吐交互式推理、Agent、RAG轻度推理、长文本批量处理、预算有限注意上表中的带宽数字只是便于理解的经验区间不同型号、不同内存配置差异很大。重点是独显的带宽规格明显高于核显借助系统内存所能获得的带宽这决定了 LLM 推理速度的起点。2. 测试环境与工具链准备2.1 测试环境本次对比在两台笔记本上完成分别为硬件 A搭载 RTX 5070 独显的笔记本Windows 11 系统配备 32GB 双通道内存驱动使用 NVIDIA 官方最新 Studio 驱动。硬件 B搭载 Intel/AMD 核显的轻薄本iGPUWindows 11 系统配备 32GB 双通道 DDR5 内存具体处理器型号不影响核心结论。需要说明的是核显性能与系统内存频率关系非常密切。双通道 DDR5-5600 的理论带宽约为 89.6GB/s如果是单通道内存带宽会直接减半LLM 推理速度还会进一步下降。所以如果你打算用核显跑本地模型双通道内存是底线。2.2 推理部署工具选择目前本地 LLM 推理工具主要有三套Ollama、llama.cpp 和 LM Studio。它们底层核心其实都源自或移植了 llama.cpp 的推理逻辑只是封装程度不同。Ollama安装简单命令式操作自带模型仓库适合快速上手和日常使用也是本文主要使用的工具。llama.cpp经典开源推理引擎提供 llama-bench 等基准工具适合做细粒度性能测试和参数控制。LM Studio图形化界面支持手动拖动 GPU offload 层数对不熟悉命令行的用户更友好。三套工具各有优势本文对比时以 Ollama 作为统一入口基准测试使用 llama.cpp 自带的 llama-bench这样既能验证日常使用体验又能得到可量化的性能指标。2.3 模型选择为什么用 7B 级别模型测试模型选择的是 Qwen2.5 7B Instruct 的 GGUF 量化版本。选 7B 级别的原因很简单这是核显也能勉强带动、独显可以轻松流畅运行的中间尺寸。如果选 1B 或 3B 小模型独显的优势体现不明显如果选 14B 甚至 70B 模型核显根本加载不动对比就没有意义。同一个模型在本文中会下载两种量化版本Q4_K_M体积约 4~5GB质量损失可控适合核显和 8GB 显存独显。Q8_0体积约 7~8GB精度更接近 FP16适合显存相对宽裕的独显。需要再次强调对比时两台机器必须加载完全相同的标签和量化版本不能一台用 Q4、另一台用 FP16否则速度差异会混入模型体积因素。2.4 测试方法与观测指标为了让结果有可比性测试遵循以下规则使用相同的模型文件相同标签、相同量化格式。使用相同的提示词设置固定的温度参数和最大生成长度。每个配置至少测试 3 次取中间值避免偶然波动。记录三个指标加载耗时、首 Token 延迟、生成速度tokens/s。首 Token 延迟表示从发起请求到模型开始输出第一个字的时间生成速度表示后续每秒钟能生成多少个 Token。这两个指标一个影响“你感觉等多久才开始回答”一个影响“回答过程中会不会卡顿”缺一不可。3. 决定 LLM 推理速度的关键原理3.1 解码过程是内存带宽瓶颈大模型的推理过程可以分成两个阶段预填充Prefill和解码Decode。预填充阶段会把整段输入提示词一次性交给模型处理此时计算量较大GPU 的算力利用率比较高。解码阶段则是逐 Token 生成输出每个 Token 的生成都要依赖已经出现的所有 Token这个过程无法并行必须一步一步来。关键点在于解码阶段模型每生成一个 Token都需要把网络的每一层权重从显存中读取一遍参与矩阵乘法。这意味着生成速度的上限直接取决于“单位时间内能从显存读出多少模型权重”。如果显存带宽不够哪怕计算单元再快也只能等待数据搬运。这也解释了为什么提升显存带宽比单纯提升算力对推理更有效。很多老牌显卡虽然跑游戏性能可以但如果显存带宽偏低跑大模型的体验反而不如新款中端卡。RTX 5070 的独立 GDDR7 显存带宽远高于系统内存带宽因此解码速度会比 iGPU 高出一个数量级。3.2 估算公式你的电脑能跑多快在实际项目中可以用一个非常粗略但好用的公式估算生成速度上限生成速度tokens/s ≈ 可用内存/显存带宽GB/s / 模型量化后体积GB举个例子一台核显轻薄本使用双通道 DDR5-5600 内存理论带宽约 89.6GB/s实际能被 iGPU 利用的带宽要打个折扣。假设有效带宽按 70% 估算约 62GB/s加载一个 4.4GB 的 7B Q4_K_M 模型理论上限大约是62 / 4.4 ≈ 14 tokens/s这正好符合很多核显笔记本跑 7B 量化模型的体验能对话但明显感觉每个字都是“蹦”出来的。再看独显场景。RTX 50 系列移动端显存带宽通常达到数百 GB/s 量级假设一块显卡有效带宽在 300GB/s 以上同样加载 4.4GB 的模型理论上限大约是300 / 4.4 ≈ 68 tokens/s实际解码还会受到计算效率、KV Cache、内存分配等影响结果会略低于理论值但整体量级远高于核显。这个公式的价值在于它可以帮你判断一台机器适合跑多大的模型。预算有限时先用这个公式估算能避免“买回来发现跑不动”的尴尬。3.3 精度与量化FP16/BF16/INT8/INT4 怎么选本地 LLM 部署绕不开精度话题。模型权重最常见的原始存储格式是 FP1616 位浮点或 BF16BFloat16两者都占 2 字节。FP16 精度和范围较均衡BF16 指数范围比 FP16 更大更适合训练场景在推理时两者体积和速度差异不大。FP32 是 32 位浮点占 4 字节体积大、速度慢实际本地推理很少直接使用。更常见的做法是使用量化格式把权重从 16 位压缩到 8 位或 4 位精度格式单参数体积7B 模型估算体积特点FP324 字节约 28GB精度最高体积巨大推理不实用FP16/BF162 字节约 14GB精度高体积仍偏大INT8/Q8_01 字节约 7~8GB精度损失小速度适中INT4/Q4_K_M0.5 字节约 4~5GB体积小、速度快质量损失可接受对普通用户来说Q4_K_M 是性价比最高的选择体积小、加载快生成质量在对话场景下感知不明显。如果显存足够可以尝试 Q8_0 获得更接近原始模型的精度。至于 FP4这是 RTX 50 系列 Blackwell 架构重点支持的方向在新版推理框架中逐步铺开但不同工具的成熟度差异较大使用时需要确认后端支持情况。4. 在 RTX 5070 笔记本上运行完整流程4.1 安装 Ollama 并拉取模型Windows 下安装 Ollama 最简单的方式是直接到官网下载安装包也可以使用 wingetwinget install Ollama.Ollama安装完成后打开新的终端确认版本ollama --version然后拉取模型。注意指定量化标签确保两台机器加载的是同一个文件ollama pull qwen2.5:7b-instruct-q4_K_M ollama pull qwen2.5:7b-instruct-q8_0下载完成后可以用ollama list查看本地已有模型列表。4.2 运行对话测试直接执行ollama run qwen2.5:7b-instruct-q4_K_M进入交互模式后输入相同的提示词例如请用不超过 100 字介绍大模型推理中的内存带宽瓶颈并给出两条优化建议。Ollama 会实时流式输出结果并在结束后显示本次生成的 Token 总量和平均速度。RTX 5070 上的典型表现是生成过程基本无感知等待输出流畅速度能稳定在几十 tokens/s 的水平。如果模型本身不大首 Token 延迟通常在几百毫秒到 1 秒左右。4.3 使用 llama-bench 做基准测试为了得到更稳定的量化数据可以下载 llama.cpp 的官方预编译包使用 llama-bench 工具。注意把模型文件放到本地目录并调整路径llama-bench.exe -m D:\models\qwen2.5-7b-instruct-q4_K_M.gguf -n 256 -p 128 -ngl 999参数说明-m指定 GGUF 模型路径。-n生成 Token 数量。-p输入提示词的 Token 长度。-ngl 999表示把尽可能多的层卸载到 GPU。如果显存不足可以减小该值。在 RTX 5070 笔记本上运行后llama-bench 会输出多个阶段的耗时和速度重点关注解码速度。经验上7B Q4_K_M 模型的解码速度会明显高于核显交互式使用完全没问题。4.4 观测显存、功耗与速度测试过程中可以打开任务管理器切换到“性能”标签观察 GPU 的专用 GPU 内存占用情况。RTX 5070 跑 7B Q4_K_M 时显存占用通常在 5GB 左右运行过程中如果上下文拉长KV Cache 会持续占用额外显存所以不建议把上下文长度设置得过大。同时注意笔记本一定要插电运行并开启高性能电源模式。独显在跑 LLM 时功耗不低如果拔掉电源Windows 会默认限制独显性能速度可能掉 30% 甚至更多。5. 在 iGPU 核显笔记本上运行完整流程5.1 iGPU 跑 LLM 是怎么工作的iGPU 没有独立显存所有数据都存放在系统内存中。运行 LLM 时模型权重、中间激活、KV Cache 全部占用系统内存。当体系架构调用核显计算时数据从系统内存搬运到核显计算单元算完后结果再写回系统内存。这样一来整个推理流程的带宽上限就是系统内存带宽。双通道 DDR5-5600 的理论带宽约 89.6GB/s看似不低但相比独立显卡的显存带宽还是差了很多。而且核显还要和 CPU、操作系统、后台程序共享这套内存总线实际可获得的有效带宽会更低。5.2 核显环境下的工具选择Ollama 在部分核显平台上的支持不稳定如果检测不到独立 NVIDIA/AMD 显卡驱动可能会直接回退到 CPU 推理此时核显完全没有参与计算速度自然难看。这种情况下更推荐使用支持 Vulkan 后端的 llama.cpp 或 LM Studio。llama.cpp 的预编译包中带 Vulkan 的版本可以直接在核显上运行。使用方式类似只是需要把模型层数加载到 GPUllama-bench.exe -m D:\models\qwen2.5-7b-instruct-q4_K_M.gguf -n 256 -p 128 -ngl 999 -mg 1-mg 1用于指定核显设备序号如果你的核显在设备列表中不是 1可能需要调整。运行前最好在任务管理器中确认核显占用率是否上升防止模型实际跑在 CPU 上。5.3 iGPU 的实际表现在核显笔记本上运行同一个 7B Q4_K_M 模型典型体验是模型加载需要几秒到十几秒首批 Token 延迟明显较高生成速度通常在 5~15 tokens/s 区间。具体数值取决于内存频率、是否双通道、核显型号和主板设计。这个速度在纯文本对话场景下勉强可用但如果你需要模型生成大段代码或长文等待时间会被拉长到难以接受的程度。不过有一个优点由于模型权重全部放在系统内存中只要内存够大核显笔记本可以跑比独显更吃容量的模型。比如某些 14B 或 32B 模型的低量化版本在独显显存不足时会报错但在内存 32GB 的核显笔记本上反而可以慢慢跑。6. 对比结果与瓶颈分析6.1 同一模型的对比表使用相同模型、相同提示词、相同生成长度时两台机器的对比结果大致如下指标RTX 5070 独显笔记本iGPU 核显笔记本模型加载耗时快基本秒级慢需要等待数秒到十几秒首 Token 延迟低通常 1 秒内较高明显感觉等待生成速度数十 tokens/s 量级个位数到十几 tokens/s 量级显卡占用独显利用率高显存占用明显核显占用率波动大部分场景回退 CPU长文本生成体验流畅几乎无感知等待逐字输出交互体验较差这里的数字是量级概念不是精确跑分。不同笔记本的电源策略、内存配置、驱动版本都会影响最终数值建议用第 3 节的公式在自己的机器上做一个估算再结合实测验证。6.2 为什么 iGPU 会慢这么多核心原因就是内存带宽。LLM 解码阶段是带宽敏感任务独显的独立显存带宽通常是核显借用系统内存带宽的数倍到近十倍这就决定了二者在解码速度上存在天然代差。另一个因素是算力定位。RTX 5070 在硬件层面为并行计算做了大量优化Tensor Core 在低精度矩阵运算上效率很高而核显定位是满足日常图形输出、视频解码等轻负载并没有为大模型推理这种高吞吐访存任务做特殊优化。此外Ollama 和 llama.cpp 在 NVIDIA 平台上走的是 CUDA 加速路径代码优化成熟度更高而在核显平台上往往依赖 Vulkan 或 CPU 路径甚至可能因为驱动识别问题回退到纯 CPU进一步放慢速度。6.3 iGPU 的真正优势容量大看到这里你可能会觉得 iGPU 一无是处。其实不然。iGPU 最大的优势是“显存”容量大。独立显卡的显存容量固定比如 RTX 5070 笔记本通常是 8GB 级别。当你需要跑 14B 甚至 32B 参数的量化模型时8GB 显存可能不够放模型更别说还要留空间给 KV Cache。此时解决办法是牺牲速度让部分层跑 CPU、部分层跑 GPU但体验依然受限。而核显笔记本的系统内存通常有 16GB、32GB 甚至 64GB模型可以完整放进内存里虽然慢但至少“能跑”。对于不追求实时性、只需离线批量处理文档的场景核显笔记本是一种低成本方案。比如晚上挂机跑一批文本摘要、知识库批量向量化慢一点也可以接受。7. 常见问题与排查思路问题现象常见原因解决思路模型加载到一半提示内存不足量化体积超过可用内存/显存换更小量化版本或关闭后台大内存程序核显机器生成速度只有 1~3 tokens/s模型实际跑在 CPU 上GPU 未参与查看任务管理器 GPU 占用改用支持 Vulkan 的 llama.cpp命令执行后一直卡在加载阶段模型文件损坏或磁盘 IO 慢重新ollama pull确认磁盘剩余空间独显跑模型但显存占用不高层数卸载到 GPU 太少部分层留在 CPU增大-ngl数值或用OLLAMA_GPU_LAYERS设置生成到长上下文后速度骤降KV Cache 占据大量显存/内存缩小上下文长度或切换更高内存容量机器接入 RAG 时报文本向量 API 未配置未拉取 embedding 模型在 Ollama 中拉取并指定 embedding 模型再配置向量化接口遇到性能问题时优先确认三件事模型是否真的加载到了目标设备、内存/显存是否充足、电源模式是否开启高性能。大多数“慢到不可用”的问题都出在这三个环节。8. 最佳实践与工程建议8.1 根据硬件选择模型规模与量化格式选模型之前先算一笔账。用系统内存或显存的可用空间减去 KV Cache 预留空间再除以模型参数量的单参数体积就可以大致估算出能跑多少参数的模型。例如 8GB 显存跑 7B Q4_K_M约 4.4GB没问题但如果你想跑 14B Q4_K_M约 8~9GB就必须把大量层放在 CPU 上速度会明显下降。这种情况下要么换小模型要么接受“能加载但慢”的现实。8.2 推理参数调优本地推理时不要把上下文长度拉满。很多框架默认 4K 上下文已经够日常对话使用盲目调到 32K 会显著增加 KV Cache 显存占用甚至在长对话中触发内存溢出。按需设置上下文长度是提升稳定性的关键。另外不要把 temperature 调得过高或过低。本地模型在低 temperature 下更稳定但过于保守会让回答显得刻板建议在 0.6~0.8 区间调整找到适合自己场景的平衡点。8.3 服务化与上层应用接入Ollama 启动后默认监听11434端口并提供 OpenAI 兼容的/v1/chat/completions接口。这意味着本地推理服务可以直接接入各类 LLM 应用框架比如 RAG 知识库、Agent 工具链甚至 Spring AI 等后端框架。接入时注意两点一是 embedding 模型也要本地部署否则文本向量化会报“API 未配置”之类的错误二是要评估并发量本地推理的并发能力受硬件限制不要按云端 API 的标准去压测。8.4 笔记本功耗与散热在笔记本上跑 LLM插电和拔电是两个体验。拔电后系统会限制 CPU/GPU 功耗推理速度可能下降明显。如果长期用本地推理建议开启高性能模式并把笔记本放在散热良好的位置。独显满载时风噪和发热会明显上升这是正常现象不必过度担心。9. 总结与下一步行动这次对比的核心结论很简单RTX 5070 和 iGPU 都能运行本地 LLM但解码速度的差异主要来自显存/内存带宽而不是单纯“显卡强不强”。RTX 5070 适合高频交互、Agent 编排、RAG 检索生成等对实时性要求高的场景iGPU 笔记本更适合预算有限、模型容量优先、愿意牺牲速度换容量的轻量场景。如果你准备动手实践建议按下面顺序走一遍用内存带宽公式估算自己设备的理论速度上限。下载 Ollama 或 llama.cpp拉取一个 7B Q4_K_M 模型。用任务管理器确认模型运行在 GPU 还是 CPU。跑一次固定提示词的基准测试记录 tokens/s。再尝试 Q8_0 或更大模型对比质量与速度。下一步可以继续学习 GGUF 量化原理、llama.cpp 的 Vulkan 编译、KV Cache 优化以及把本地 LLM 接入 RAG 或 Agent 框架。本地推理是一条值得深入的路关键是先搞清楚自己的硬件边界再选择合理的模型和参数。