最近我把同一个本地大模型分别放到了两台笔记本上跑了一遍一台是搭载 RTX 5070 的独显本另一台是只有核显iGPU的轻薄本。跑之前我以为最坏的结果就是核显慢一点跑完才发现这种慢不是“多等几秒”的慢而是会直接改变我是否愿意继续使用这个工具的慢。同一个模型在 RTX 5070 上可以比较自然地对话到了核显机器上变成了一个字一个字往外蹦的“打字机”中间还会出现明显停顿。这个对比真正让我想明白了一件事本地 LLM 的体验上限通常不是显卡有多少算力而是显存容量和内存带宽能不能撑住每一次 token 生成时的权重读取。如果你也在纠结“没有独显能不能跑本地大模型”或者准备买一台带独显的笔记本专门用来跑 LLM这篇内容或许能帮你少走一些弯路。1. 先说结论本地大模型跑得顺不顺卡在显存带宽与显存容量很多硬件评测在聊本地大模型时喜欢把 GPU 算力、核心数、主频放在最前面。但你真正把模型跑起来之后会发现算力只是决定“爬坡能力”决定“最高车速”的往往是内存带宽和显存容量。1.1 为什么单看算力会误导你大模型生成文本的方式是自回归式的它不是一个词一个词把整段话“一次算完”而是每生成一个 token都要把模型里的大多数权重从头到尾读一遍。假设一个 7B 模型用 fp16 保存权重大约 14GB那么每生成一个 token理论上至少要从显存里搬 14GB 数据。如果你的显存带宽是 100GB/s理想情况下每秒最多也只能生成 7 个 token如果带宽是 500GB/s理想上限也就是 35 个 token 左右。当然这只是粗略估算真实的推理还会涉及计算、采样、KV cache 读写速度只会比这个理想值更低。但核心逻辑已经很清楚了在单次对话、batch1 的典型场景里LLM 推理的瓶颈往往不是“算得快不快”而是“能不能在一秒内把权重从头到尾读一遍”。这一点和很多人印象里的“游戏显卡评测”不一样。游戏场景是大量三角形计算、纹理填充GPU 算力起决定性作用LLM 解码则更像流水线搬运水管越粗水流量越大。1.2 核显跑 LLM 的真正上限是共享内存不是 GPU 核心核显没有独立显存它一般采用共享内存架构也就是复用系统内存。表面上系统内存可能很大但内存带宽是有限的而且要和 CPU、核显、其他硬件共享。再加上不少轻薄本为了省电只使用单通道内存会让内存带宽进一步缩水。RTX 5070 这类独显则完全不同。它拥有独立显存显卡访问自己的专用显存时不会和其他组件争抢带宽。这也是为什么在同一台笔记本上独显和核显跑同一个模型体验差距会非常夸张不只是“快一点”和“慢一点”的区别而是“能不能接受长期使用”的区别。所以我在这次对比里最大的认知增量是把“能不能跑起来”和“能不能当日常工具用”分开看。很多核显机器确实能把模型加载起来甚至能正常输出但它的输出节奏、首 token 延迟、长上下文表现可能都达不到你心里的“可用”标准。2. 同模型、两台机器我到底是怎么跑的在开始对比之前我先理了一遍测试流程。因为如果直接把一个 7B 模型塞给核显机器大概率“能加载但体验很差”这个结果本身说明不了太多。更合理的做法是先确认硬件边界再选模型和量化最后用同一个推理引擎跑同一份模型。2.1 模型和量化怎么选先看显存再谈体验选模型的第一步不是看口碑而是看显存或内存能不能装下。我整理了一个简单的步骤如果是独显先打开任务管理器或nvidia-smi看看“专用 GPU 内存”如果是核显看“共享 GPU 内存”和系统总内存。找到模型的 GGUF 文件大小。社区里一般会标注Q4_K_M、Q5_K_M、Q8_0等量化版本。估算模型文件大小 上下文 KV cache 系统开销最好能控制在可用显存/内存的 70% 以内否则运行时会比较紧张。选择模型系列时新手可以优先看社区生态好、文档多的 Qwen、Llama、Phi 系列因为相关教程和踩坑记录都更多。以这次对比为例我在 RTX 5070 笔记本上选择了 7B 模型的 Q4_K_M 量化版因为它在显存占用、效果和速度之间比较平衡在核显笔记本上我也尝试了同样的模型但同时也准备了更小的 1.5B 模型做对照。注意不要一上来就把模型体积拉满先跑通一个小模型确认日志、显存占用和输出都正常再逐步换更大的模型。2.2 推理引擎的差异Ollama、llama.cpp、LM Studio同一个 GGUF 模型在不同推理引擎下的表现可能差异不大但配置方式完全不同。我这次主要用了 Ollama因为它对新手最友好底层又依赖 llama.cpp 生态既能命令行对话也提供了 OpenAI 兼容的 API方便后续接到 LangChain、Spring AI 这类框架里。Ollama适合快速体验和 API 调用。执行ollama run就能跑起来也支持环境变量控制 GPU 层数。LM Studio有图形界面适合不想碰命令行的用户。可以在界面上直接选择模型、拖拽参数。llama.cpp更底层适合想精细控制、调试模型性能的开发者。命令行参数-ngl可以手动指定把多少层放到 GPU。这里有一个容易踩坑的地方引擎默认不一定帮你把 GPU 用满。在独显机器上Ollama 通常会尝试用 GPU但如果驱动、显存或环境变量有问题模型可能会回退到 CPU。在核显机器上问题更复杂因为核显共享内存默认行为未必是“越高越好”。2.3 最小可运行流程如果我推荐一个最简单的启动方式Ollama 可能是当前门槛最低的ollama pull qwen2.5:7b-instruct-q4_K_M ollama run qwen2.5:7b-instruct-q4_K_M跑起来之后可以打开另一个终端用ollama ps查看当前模型是不是真的跑在 GPU 上。如果PROCESSOR列显示GPU说明 GPU offload 生效如果显示CPU或CPU/GPU说明至少有一部分计算没有用到显卡。在核显机器上可能还需要显式设置层数。常见写法大致如下$env:OLLAMA_GPU_LAYERS1 ollama run qwen2.5:1.5b-instruct-q4_K_M如果你用的是 llama.cpp命令类似llama-cli -m qwen2.5-7b-instruct-q4_K_M.gguf -ngl 0-ngl 0表示不把任何层放到 GPU也就是纯 CPU 推理-ngl 99或更大的数值表示尽量把模型全部塞进 GPU。不同版本的命令名和参数细节会有差异落地前需要确认当前引擎版本。3. 对比现场流畅度、速度和决策差异这次对比不是为了跑分而是为了回答一个很实际的问题同样的本地大模型在不同硬件上使用到底差在哪里3.1 独显这边体验接近云端但仍要管好上下文RTX 5070 笔记本跑 7B Q4 模型的体感对我来说已经够用了。它可能没有云端旗舰模型那种“秒回”的感觉但作为离线工具已经足够自然。更关键的是生成过程相对稳定不会出现“中间卡住很久才继续”的情况。但这并不代表可以无脑开长上下文。随着对话轮数变多KV cache 会逐渐占满显存。你会发现同样的模型一开始速度还行聊到后面越来越慢。原因在于长上下文不仅占显存还会让每次生成 token 时额外读取更多 KV cache 数据。所以我在独显上也会主动控制上下文的长度。比如只保留最近几轮对话内容或者定期开启新会话。这不是模型能力不够而是显存和带宽的限制一直都在。3.2 核显这边能输出但“思考时间长”和“打字机感”更明显核显机器也能加载同一个 7B Q4 模型但它给我的体感完全不同。最明显的是首 token 等待时间变长。你发出问题后可能要等好几秒才看到第一个字出现然后输出像打字机一样一个字一个字往外蹦中间偶尔还会停顿。这种体验谈不上“崩溃”但确实很难当成日常对话工具来用。如果你只是想做一次技术验证或者想测试某个 prompt 在本地模型上的行为核显完全可以接受。可一旦你要把它接进 Agent、RAG 或实时聊天场景慢速输出会直接影响工作流体验。一个更隐蔽的问题是核显使用共享内存当模型推理大规模读写内存时整个系统的响应也会受到影响。我在核显机器上跑模型时后台如果还开着大量浏览器标签页明显能感到系统变卡。这种“全家桶式”的资源争抢独显机器几乎不会遇到。4. 为什么核显跑 LLM 更依赖内存带宽而不是 GPU 核心如果你已经理解了“每个 token 都要读一遍模型权重”这个前提那么核显性能差的原因其实就顺理成章了。4.1 LLM 推理是访存密集型任务在大模型自回归解码阶段模型权重被反复读取而每次读取的规模接近整个模型大小。你可以把模型理解成一本很厚的书每生成一个字都要把整本书从头到尾翻一遍。翻书的速度取决于你的“翻页带宽”而不是你的“阅读理解能力”。独显之所以适合跑本地 LLM是因为它配备的高带宽显存正是为了解决这种“大量数据快速读取”的需求。核显没有独立显存只能使用共享内存内存带宽通常只有几十 GB/s 到一百多 GB/s 的水平而且还要和 CPU 争用。于是每生成一个 token都会在“搬模型”这一环节浪费大量时间。当然当 batch size 变大同时处理多个请求时GPU 算力的价值会体现得更明显。但本地对话场景通常是单用户、单请求算力反而不是最突出的瓶颈。4.2 量化精度fp16、bf16、fp32 和 Q4_K_M 的区别很多人刚开始接触本地模型时会纠结该用 fp16 还是 Q4。其实这里的核心问题是模型体积直接决定了每次推理需要搬运的数据量也直接决定了带宽压力和数据精度。精度/量化每参数位数约7B 模型体积约特点fp3232 bit28GB精度高体积最大本地部署压力很大fp1616 bit14GB常见训练/推理精度需要较大显存bf1616 bit14GB指数范围更大精度略低稳定性更好Q8约 8 bit约 7GB量化损失较小体积适中Q4_K_M约 4 bit约 4-5GB体积小本地部署常用速度更有优势从这个表能看出来Q4_K_M 的模型体积大约是 fp16 的三分之一。也就是说在同样带宽下读取权重的消耗也大致下降到三分之一。对内存带宽紧张的核显机器来说这是“还能不能跑”的关键因素。所以不要觉得“精度越高就一定越好”。在显存和带宽受限的机器上模型体积每缩小一点实际生成速度的提升都非常直接。bf16、fp16更多出现在训练或足够大显存的场景里本地部署时Q4_K_M往往是更稳妥的起点。在只有核显的机器上优先看模型体积而不是模型名称里的“大杯”。Q4_K_M 这类 4bit 量化很多时候就是核显机器能否流畅跑起来的胜负手。5. 如果核显机器也想跑本地 LLM建议怎么做测完这几轮之后我的结论并不是“核显买来没用”。只要定位得当核显机器也能成为很好的本地 LLM 学习工具。5.1 适合核显的场景小模型、短文本、离线测试核显机器比较适合下面几类用法学习 LLM 的推理原理、量化差异、API 调用流程。验证 prompt 在某个模型上的效果比如做 prompt 工程实验。做一些轻量级的本地文本处理比如分类、摘要、翻译。在敏感数据不能出本机的场景里跑一个很小的模型做离线初步处理。但以下场景我会比较谨慎实时 Agent 对话、长文档问答、批量推理、高并发服务。这些任务要么要求低延迟要么需要大显存要么需要持续高吞吐核显机器都很难承担。如果硬要用短时间试验可以长期使用体验会非常难受。5.2 调整推理参数上下文长度、GPU 层数、batch 大小如果核显机器是当前唯一能用的设备建议先调这几个参数上下文长度从 4096 降到 2048 甚至 1024。这会明显减少 KV cache 占用的内存也能降低每次推理需要读取的数据量。GPU 层数在核显上不一定要把所有层都丢给 GPU。共享内存环境下CPU 和 GPU 都要读写同一块内存盲目全 offload 可能反而造成额外复制开销。可以试试OLLAMA_GPU_LAYERS1或只放一小部分层观察速度变化。batch size如果引擎支持把 batch size 调小减少单次推理对内存带宽的峰值压力。采样参数temperature、top_p等参数主要影响随机性对速度影响不大但不要为了效果反复生成太多次。另外核显机器跑模型前最好关掉大多数后台应用。浏览器标签页、编译工具、大型 IDE 都在争用内存和带宽轻则让推理变慢重则直接导致内存不足。5.3 一套选型清单先跑通再优化最后工程化我更建议把核显机器的定位看成“实验环境”而不是“生产工具”。在使用上可以按三步走先跑通选一个最小的模型比如 1B 或 1.5B 的 Q4 版本确认引擎能启动、输出正常。再优化在保证能跑通的基础上逐步换更大的模型或更高级的量化记录首 token 延迟、生成速度、显存/内存占用找到适合当前硬件的档位。最后工程化如果以后要接入项目至少需要把模型包装成 API 服务加上日志、异常重试、上下文清理和并发控制。否则一次测试和长期稳定运行是两回事。核显机器更适合做“能不能跑”的验证不适合承担“要稳定、要实时”的在线任务。先跑通再谈优化最后才谈工程化。6. 常见问题排查慢、卡、爆显存、没生效无论你最后选择了独显还是核显运行本地 LLM 时都可能会遇到下面几类问题。这些问题的排查顺序很重要乱换模型、乱调参数往往浪费时间。6.1 如何确认模型真正用上了显卡如果模型实际上跑在 CPU 上GPU 完全没参与速度会慢到让你怀疑人生。确认方式很简单独显运行nvidia-smi看看有没有对应的进程占用了显存。Ollama运行ollama ps看PROCESSOR列。llama.cpp看启动日志里的offloaded 0/28 layers to GPU之类信息。核显打开任务管理器观察 GPU 使用率是否在模型推理时明显升高。如果发现 GPU 完全没生效优先检查驱动是否正确安装、引擎版本是否支持该 GPU、环境变量是否写对。不要一上来就怀疑模型有问题。6.2 推理速度异常慢的排查链路速度问题不能只看“慢”这一个现象。我一般会按下面的顺序排查先看现象是首 token 很慢还是后面每个字都很慢还是时快时慢这决定了排查方向完全不同。再看输入上下文是不是已经很长了之前对话累积的 token 数量是不是过多再看环境内存是否双通道显存是否接近占满后台有没有大型程序在跑再看参数GPU 层数是不是设成了 0上下文长度是不是过高量化是不是太“重”最后看工具边界引擎版本、驱动版本、系统限制甚至模型文件是否损坏都可能影响最终表现。我特别想强调一个容易忽略的坑核显机器如果 GPU offload 生效但系统内存是单通道速度依然会很明显地变慢。单通道内存的带宽只有双通道的一半左右同一个模型跑起来差距可能比预想更大。现象优先检查处理思路启动时报显存不足显存容量、模型体积降低量化、换更小模型、减少上下文输出很慢但 GPU 占用低GPU offload 未生效检查环境变量、驱动、引擎配置前后速度差异明显上下文过长、KV cache 占用过高清空历史、缩短上下文核显机器整个系统卡死系统内存不足换更小模型、关闭后台程序、增加虚拟内存6.3 显存不足和内存不足的表现与处理显存不足在独显上通常表现为加载模型时报错、只加载部分层到 GPU或者运行到一半直接被系统终止。这时候优先换更小、量化更低的模型或者减小上下文长度。内存不足在核显机器上更危险因为共享内存意味着系统内存和显存共用。一旦内存被模型吃满整个系统都可能无响应。16GB 内存跑 7B Q4 模型会比较极限我更建议至少 32GB 内存同时记得开启双通道。如果只是个人学习用途不想为一个实验就买独显机器核显 小模型 短上下文是一个能接受的组合。如果想把本地模型真正变成日常工具独立显存带来的带宽和容量优势确实会直接决定体验上限。这次对比最让我意外的不是 RTX 5070 跑得比核显快而是“能跑”和“能用”之间隔着一条明确的硬件分界线。如果你正在犹豫要不要为本地 LLM 加一块独显我的建议是先想清楚你要跑多大的模型、多长的上下文以及能不能接受慢速输出。如果只是学习推理原理核显足够如果想让本地模型替代日常对话、笔记总结或代码辅助工具独显的独立显存和更高带宽才是真正值得为那部分体验付出的预算。工具选型走到最后永远不是看参数高多少而是看它能否匹配你每天的真实工作流。