在 RTX 5070 笔记本和只有 iGPU 的核显轻薄本上跑同一个本地 LLM最直观的差别不是能不能启动而是生成速度、能跑多大模型、连续用多久不卡以及你要不要反复调参数。带 iGPU 的轻薄本能跑但体验会明显受限RTX 5070 也不是万能移动端独显的显存和功耗墙同样会卡住大模型。下面按实测路径拆一遍适合准备买笔记本跑本地大模型的人也适合手头只有核显本、想确认还能不能继续用的人。1. 跑本地大模型显卡的核心任务是什么1.1 显存解决的是“装不装得下”本地 LLM 的推理过程可以简单理解成把模型的权重加载到内存或显存里然后根据你的输入逐字计算下一个 token。整个过程最吃资源的其实不是算力而是存储容量和内存带宽。如果一个模型的权重本身是 4GB量化之后是 2GB推理时还要预留 KV cache 和中间状态那么显存低于这个阈值模型就放不进显卡。放不进显卡要么用 CPU 和系统内存硬扛要么直接报错。RTX 5070 笔记本通常有独立显存常见型号给到 8GB 左右iGPU 没有独立显存只能共享系统内存。所以第一道门槛不是“你的显卡有多快”而是“模型和上下文能不能装进某个存储空间”。这也是为什么很多人买笔记本时只盯着“显卡型号”和“AI 算力”但实际跑起来却被显存容量卡住。移动端显卡的显存普遍有限跑不了太大的模型。你看到一个模型介绍里写着 14B 参数先别想着能不能跑先看量化后的文件有多大再对比自己的显存和内存。1.2 算力和内存带宽决定“跑得快不快”模型放得下之后才轮到算力和带宽。大模型推理分两个阶段预填阶段处理你输入的一大段文字解码阶段一个 token 一个 token 地生成。解码阶段对算力要求高但同时也受内存带宽约束因为每次生成都需要把模型权重从显存或内存里读一遍。独立显卡的优势在于GDDR 显存的带宽通常远高于系统内存。RTX 5070 笔记本的显存带宽会比 iGPU 共享系统内存的带宽高很多。这意味着同样跑一个 7B 模型解码速度会差出好几倍尤其当模型层数全部放进显存时差距更明显。不过这里有个容易踩的坑如果模型超过显存容量一部分层只能放在 CPU 内存里那么每层计算都要在 CPU 和 GPU 之间同步实际速度可能比纯 CPU 还难受。所以“跑得动”不等于“跑得快”需要看模型层数、显存占用和内存占用是否匹配。1.3 iGPU 的处境能跑但满负荷时容易挤占系统内存iGPU 本身也有一定的图形算力现代核显也能执行一部分通用计算任务。但它在跑大模型时GPU 使用的显存就是从系统内存里划出来的。如果你的笔记本只有 16GB 内存把模型权重、上下文和操作系统一起挤在里面很容易出现内存吃满、交换到磁盘的情况。实际体验就是模型启动很慢生成到一半变卡甚至整个系统响应迟缓。这不一定是模型选得不对很可能是系统内存不够或者核显驱动把内存分配得不合理。我一般会在测试前先看内存占用变化不要只看任务管理器里 GPU 那一栏。如果一个 8B 模型在 iGPU 笔记本上把可用内存吃到 90% 以上就要考虑换更小的模型或更低的量化格式。2. RTX 5070 笔记本和 iGPU 笔记本差别到底在哪2.1 硬件层面的差异独立显存 vs 共享内存RTX 5070 这类笔记本独显和 iGPU 最本质的区别是显存来源。独立显卡有自己专门的高速显存容量固定带宽高iGPU 没有独立显存必须和 CPU 共享系统内存带宽受内存通道数和频率限制。在跑同一个本地 LLM 时这种差异会直接影响三件事模型能选多大。上下文窗口能开多长。多轮对话时是否越聊越慢。独立显存 8GB 的笔记本通常可以把 7B 到 8B 的量化模型完整放进显存。iGPU 笔记本如果内存够大比如 32GB也可以跑更大的模型但因为带宽受限生成速度会掉得很明显。另外独立显存和系统内存之间还有一次数据拷贝。大多数推理框架会把模型层尽量放到 GPU 上减少 CPU 和 GPU 之间的数据交换。如果你在设置里没有正确开启 GPU offload那即使有 RTX 5070也可能只是在用 CPU 跑速度反而不如核显笔记本的优化配置。2.2 软件生态CUDA 与开源推理框架的配合这一点比很多人想象中更重要。大多数本地 LLM 推理工具比如 llama.cpp、Ollama、LM Studio都优先支持 NVIDIA CUDA。在 RTX 5070 上驱动安装好之后Ollama 默认就能识别 GPUllama.cpp 编译时开 CUDA 也很顺畅。iGPU 则要看具体平台。常见的核显包括 AMD 的 Radeon 系列和 Intel 的 Arc/Iris 系列。llama.cpp 也支持 Vulkan、OpenCL 等方式理论上能把部分层放到核显上跑但实际兼容性取决于驱动和编译选项。遇到“GPU 没被识别”“一开 GPU 就报错”的情况在核显平台上更常见。这也是为什么很多人测完后评价“还是 N 卡省心”。不是因为核显不能跑而是你要多花时间处理驱动、编译和版本匹配。对于新手来说这些时间成本比硬件差价更影响体验。如果你后面还会接触 ComfyUI 这类本地模型工具同样要注意显存和内存占用。不要把 LLM 推理和图像生成同时开否则系统内存会被快速吃空。2.3 功耗、风扇和持续负载下的真实体验跑本地 LLM 不是跑分软件不是点一下测试就结束。一个 7B 模型在独显上生成几千个 token可能持续几分钟在 iGPU 上可能要十几分钟甚至更久。这期间笔记本的散热、风扇噪声、功耗墙都会暴露出来。RTX 5070 笔记本跑高负载推理时风扇噪音会比较明显机身在键盘上方也会发热。它的问题不是性能不够而是功耗和温度墙可能让显卡频率上下波动导致生成速度不稳定。iGPU 笔记本的优势是安静、省电、便携但在持续高负载下共享内存和散热设计同样会限制性能。实测时不要只看刚启动时的速度要把同一段长文本生成完观察后半段有没有明显降速。如果中途降速严重先看是否触发温度墙再看有没有其他进程抢内存。3. 同一模型怎么测才有说服力3.1 统一工具、模型文件和参数跨设备对比最重要的是控制变量。首先要保证是同一个模型文件最好用同一个 GGUF 文件而不是一台机器下载原版 fp16 格式、另一台机器用量化版。推荐的做法是先用 Ollama 或 LM Studio 统一拉取同一个模型标签记录模型名称、量化格式、上下文长度和采样参数。不要一台用默认参数另一台改了温度。否则结果没法比较。其次要保证推理引擎版本一致。Ollama 更新很频繁不同版本的 CPU 线程调度、GPU 层数处理都会有差异。我在做对比时会固定版本并且把 GPU offload 层数写清楚。这样两台机器之间才有可比性。3.2 测试步骤启动、单轮生成、多轮对话、长上下文我会把测试拆成四步启动测试观察加载模型耗时和首次响应时间。单轮生成给同一个 prompt要求输出固定长度比如写一封 300 字的邮件。多轮对话连续问 5 轮观察速度是否衰减、上下文是否重复。长上下文测试粘贴一段几千字的材料让模型做总结观察显存和内存占用。这四步分别对应四个真实场景日常问答、内容生成、聊天机器人、文档总结。如果只在单轮生成上比较很难发现 iGPU 在多轮对话后越跑越慢的问题。3.3 观察哪些指标速度、内存、稳定性、输出质量对比时至少记录四个维度生成速度每秒生成多少个 token也就是 token/s。首 token 延迟输入后等多久才看到第一个字。资源占用显存、内存、CPU 各占多少。输出质量有没有乱码、重复、中断。不要只看峰值速度。有些模型刚启动时很快跑一段后因为内存交换或温度墙而降速。更稳妥的方式是记录“完整生成 1000 token 的实际耗时”而不是靠第一屏的观感。4. 实测中最容易忽视的问题模型大小与量化4.1 为什么 8GB 显存也不能随便上 fp16很多人在本地跑大模型时看到网上说“这个模型支持 fp16、bf16、int8、int4”就觉得选最高精度肯定最好。但在移动端 8GB 显存的环境里一个 7B 模型的 fp16 权重大约 14GB8GB 显存根本放不下。bf16 和 fp16 占用的空间差不多fp32 更大直接跑通常会爆显存。即使你能用 CPU 内存补充GPU 和 CPU 之间频繁交换数据速度也会非常惨。这也是为什么本地推理工具里最常用的不是原版精度而是量化后的 GGUF。所以我的建议是先确认当前显存能装下多大模型再决定精度。模型尺寸、量化格式、上下文长度三者的关系才是实测的起点。4.2 GGUF 量化格式怎么影响能跑性和质量GGUF 是 llama.cpp 生态里最常用的模型存储格式。它支持把原始权重量化成不同位宽比如 Q4_K_M、Q5_K_M、Q8_0。Q4 表示权重平均用 4 bit 存储Q8 用 8 bit。位宽越低文件体积越小内存占用越低但模型质量可能会有轻微损失。对于 7B 模型Q8_0 大概 8GB 左右8GB 显存勉强能塞上下文稍长就会爆。Q5_K_M 大概 5GB 左右比较均衡。Q4_K_M 大概 4GB 左右最实用能留出余量给上下文。这不是说 Q8 一定比 Q4 好。实际操作中Q4_K_M 在很多任务上的质量损失并不明显但速度更稳定能开更长的上下文。如果是为了学习框架、搭 AgentQ4_K_M 是更好的起点。4.3 什么时候该选小模型如果在 iGPU 笔记本上跑一个 14B 模型虽然内存也许够但速度慢到没法用那就是选错了模型。这时候不如降级到 7B甚至 3B、1.5B 的小模型。小模型适合的场景包括文本分类、关键词提取、快速问答、测试提示词、做 API 联调。需要深度推理、长逻辑、复杂代码生成的时候再考虑大模型并且用量化后的体积控制到设备能装下。不要被“能力越强越好”迷惑。实测中能快速稳定返回结果的小模型比经常卡顿的大模型更实用。4.4 不要只对比“谁能跑”要比“能不能连续用”一台设备能启动模型不等于它能连续满足你的实际需求。有时候 iGPU 也能启动 8B 模型但你让它做一轮文档总结内存直接被占满整机开始卡顿。这不是“跑不起来”而是“不能连续用”。所以对比设备时我会把测试场景拉长不只问一个简单问题。模拟真实使用节奏问 5 个问题、粘贴 2000 字、再让它生成一段代码。只有在这种连续负载下才能看出设备的真实边界。5. 只靠 iGPU 跑本地大模型怎么优化到可用5.1 选模型量化模型是入门下限如果你的笔记本只有 iGPU 和 16GB 或 32GB 系统内存我最推荐先试 7B 或 8B 的 GGUF 量化模型Q4_K_M 优先。再小的 3B 模型更容易跑但推理能力弱一些。具体模型可以选社区里活跃的系列比如 Qwen、Llama、Mistral。这里不展开推荐因为生态变化太快。只要认准 GGUF 格式和量化版本即可。5.2 开 GPU offload 还是纯 CPU 推理iGPU 平台不要默认觉得 GPU 一定更快。有些核显驱动和 Vulkan 的兼容性一般强行把全部层放到 GPU会出现报错或速度更慢。更稳妥的顺序是先用纯 CPU 模式跑确认模型能正常输出。再打开 GPU offload先设置一半层数观察速度和稳定性。如果 GPU 层数增加但速度没有提升改回 CPU 模式或降低层数。Ollama 的设置里可以配置 GPU 层数LM Studio 的模型加载设置里也有对应选项。实际经验是核显在短文本生成上有点帮助长文本生成时还是会回到内存带宽瓶颈所以不必强求全部 offload。5.3 控制上下文、KV cache 和批处理iGPU 和系统内存共享上下文越长KV cache 占用越大。一个 7B Q4 模型只占 4GB 内存但 16K 上下文可能再占 1GB 到 2GB。如果还开多路并发内存会很快不足。所以在轻量设备上我建议把上下文长度控制在 4K 到 8K不要盲目拉满。如果只是测试256 或 512 足够。很多工具默认开 8K并不适合所有设备。另外有些推理框架有 batch size 参数。batch size 越大吞吐越高但内存占用也越高。本地个人使用通常不需要调大保持默认即可。5.4 系统和供电设置跑本地大模型时把 Windows 电源模式设置为最佳性能插上电源不要让系统在后台频繁做磁盘索引、系统更新或杀毒扫描。这些都是实测时光听见风扇转、但 token 速度上不去的常见原因。笔记本的显卡驱动也要更新到较新版本。尤其核显驱动对 OpenCL、Vulkan 的支持经常随版本变化。5.5 用 API 方式连接上层应用即使只有 iGPU也可以把本地模型跑成 API 服务。Ollama 启动后默认监听 11434 端口LM Studio 也可以开启本地服务器兼容 OpenAI API 格式。之后就能用 Python或者用各类编排框架去调用。这个做法最大的好处是模型只启动一次反复连接不用每次开启界面点一遍参数。对于 iGPU 设备来说启动模型很耗时做成常驻服务能省很多时间。6. 从单模型到 RAG、Agent 和编排框架6.1 接入 RAG 后显存压力变大很多人跑通本地模型后马上想接 RAG让模型基于自己的文档回答。RAG 的流程是先对文档做向量化检索再把检索到的文本拼到提示词里最后交给 LLM 生成。向量化本身还好但检索回来的文档片段会明显拉长上下文。比如原来问答只用几百 token加入 3 到 5 段资料后可能变成 3000 token 甚至更多。上下文一长KV cache 占用跟着涨在 iGPU 设备上很容易从“能跑”变成“勉强跑”。如果设备性能有限可以从两个方向缓解一是限制检索片段数量二是降低上下文长度。不要一上来就追求把整本手册塞进提示词。6.2 Agent 和工具调用对稳定性的要求Agent 场景下模型需要多轮推理、生成工具调用参数、读取返回值后再继续。这个过程中模型输出格式必须稳定如果生成到一半截断、工具参数格式错误流程就失败。本地小模型在做 Agent 时稳定性比单轮问答差。同样的 7B 量化模型可能写邮件事没问题但让它严格按 JSON 格式返回工具调用时偶尔会多出注释或提前结束。这跟设备是 RTX 5070 还是 iGPU 关系不大更多是模型能力本身的问题。所以做 Agent 和 MCP 这类编排时我建议先选能力更强的模型即使大一点、慢一点。设备算力不够时优先减少工具数量而不是硬扛多个工具调用。6.3 用离线 API 接 Spring AI 这类框架现在不少后端框架都兼容 OpenAI 格式的本地 API。比如 Spring AI、LangChain、Dify都可以配置一个本地模型的 base URL把模型当作一个远程服务来调用。这样做的优势是业务代码不关心模型跑在什么硬件上。你可以在 iGPU 笔记本上开发调试之后把 base URL 切到有 RTX 5070 的机器或换云 API代码基本不用改。不过在本地 API 模式下要关注并发和超时。核显本跑一个模型已经吃紧如果上层应用同时发多个请求非常容易排队超时。开发环境里最好把并发数调低用串行请求验证流程。6.4 买笔记本还是用云 API如果只是偶尔跑一下iGPU 本 小模型完全够用。如果每天要大量生成、做 Agent 编排、跑长文本总结那么 RTX 5070 独显能明显改善体验但本子会更重、更贵、风扇更响。还有一个选择是先不买本用云 API 跑大模型。本地模型的价值在于数据不出机器、离线可用、调模型自由。如果你没有这些需求只是想要稳定输出云 API 的成本和体验可能更好。权衡时看预算和使用频率不用一上来就追求本地跑大模型。7. 本地跑 LLM 时的常见问题和排查顺序7.1 启动慢、生成卡先看资源占用遇到卡顿先开任务管理器或系统监视器看 CPU、内存、GPU 占用和磁盘活动。不要先改模型参数。如果内存占用接近 90%先降模型大小或量化等级。如果 CPU 满载但 GPU 很低很可能是没有开启 GPU offload或模型层没有放进显存。如果磁盘一直读写说明内存不足导致交换这时候无论怎么调参数都不稳定。7.2 输出乱码、回答中断先看采样参数temperature 太高会导致内容混乱设为 0.6 到 0.8 一般比较稳。再看上下文长度如果超过模型最大上下文可能会出现重复和截断。还有一个常见原因是 prompt 格式不匹配。不同模型的模板格式不一样如果直接用错模板输出质量会明显变差。Ollama 和 LM Studio 通常会自动处理但如果你直接调 llama.cpp 底层就要自己检查模板。7.3 显存或内存不够的应对顺序解决顺序是换更小的模型。降低量化等级。缩短上下文。减少并发请求。如果还是不够建议放弃在当前设备上跑不要强行把系统内存塞满。系统内存被占满后操作系统和编辑器也会卡死往往得不偿失。7.4 GPU 识别了但没用上在 RTX 5070 上常见原因是模型没启用 GPU offload或者驱动版本过旧。在 iGPU 上常见原因是 Vulkan、OpenCL 后端没有正确编译或者核显驱动不识别。排查时先看推理工具的日志里面会显示加载了多少层到 GPU以及显存占用情况。如果日志显示“offloaded 0/32 layers”那就是没有真正用上独显或核显。7.5 最后的实际建议如果你现在手头只有 iGPU 笔记本别急着买新机器先用 7B 量化模型把工具链跑通看看自己的使用频率。如果你已经决定要把本地 LLM 当日常工具那 RTX 5070 这类带独立显卡的笔记本能省下很多调参时间但前提是你得接受风扇噪音、电源体积和更贵的价格。真正决定体验的永远是模型选择、量化配置和上下文管理。显卡只是其中一环。