企业官网建设流程全解析

之前有朋友问我：本地跑大模型，究竟是“有独显就行”还是“随便一台轻薄本也能凑合”？这个问题看起来简单，但背后的差距远不止“快一点”和“慢一点”这么简单。它涉及显存容量、显存带宽、量化策略、推理框架调度等多个环节。这篇文章就用一个真实对比场景展开：同一套开源 LLM，分别跑在配备 RTX 5070 Laptop 独显的笔记本和只有 iGPU 核显的笔记本上，完整记录测试思路、关键命令、数据解读和调优方法。无论你手头是高端独显本，还是只有核显的轻薄本，都可以按这套流程自己测一遍，找到最适合本机的本地 LLM 方案。

1. 独显本和核显本跑本地 LLM，差距到底在哪

1.1 本地 LLM 是什么

本地 LLM 指的是把开源大语言模型（如 Qwen2.5、Llama 3、DeepSeek 等）下载到自己的电脑上，通过推理框架加载模型权重，在本地完成对话、代码生成、摘要等任务。它和云端 API 的主要区别是：数据不出本机、无按 token 计费、可离线使用，同时需要自己准备算力和存储资源。

过去几年，开源模型的体积和门槛一直在下降。一个 7B（70 亿参数）模型经过 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 系统内存的传输速度。

从这张表能看出，独显和核显的差距并不只是“性能高低”，而是“能不能装下”“装下后跑多快”两个层面的问题。

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.cpp

Ollama 的安装最简单，直接去官网下载对应 Windows 安装包，装完在终端输入ollama serve启动服务。

ollama serve

LM Studio 同样下载安装包即可，安装后不需要额外配置环境变量，图形界面里可以选择模型并查看运行状态。

llama.cpp 主要用于跑基准测试。你可以下载官方发布的预编译版本，也可以自己用 CMake 构建，核显用户建议开启 Vulkan 后端：

cmake -B build -DGGML_VULKAN=ON 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，可以先设置调试日志，再启动 Ollama：

setx 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 都要读一遍权重，那权重体积越小，速度就越快，对显存容量的要求也越低。这就是量化存在的意义。

对台式机和高端显卡来说，FP16 也许可行；但在笔记本 8GB 显存的环境下，7B 模型必须量化才能装下。这也是为什么本地部署 LLM 时，第一件事就是确认模型的量化格式。

3.3 用显存带宽估算理论 token/s

Decode 阶段的理论速度可以粗略估算：

理论最大 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：把模型尽可能多的层加载到 GPU，99 表示全部交给 GPU。
• -p 512：prompt 长度为 512 个 token。
• -n 128：生成 128 个 token，用于测 Decode 速度。

输出会包含两项关键数据：

• pp：Prefill 阶段速度，单位 token/s。
• tg：Text 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 需要重点看的指标

对话体验的直观感受是：Generation 速度在 20 token/s 以上时，文字输出基本连贯；10 token/s 以下时，会有明显的“一个字一个字往外蹦”的卡顿感。

4.5 实测解读

在本次环境中，独显笔记本跑 Qwen2.5 7B Q4_K_M 的生成速度明显高于核显笔记本，大致能实现“顺畅聊天”的体验；核显笔记本虽然也能加载同一个模型，但输出速度明显偏慢，属于“能用但不够丝滑”的水平。

如果切换到 1.5B 或 3B 小模型，核显的体验会好很多，因为模型体积变小，内存带宽压力随之下降。这也印证了一个结论：独显的价值不仅在于“性能强”，更在于它能在保证速度的前提下运行更大的模型。

5. 常见问题与排查

5.1 问题速查表

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. 最佳实践：不同硬件下如何用好本地 LLM

6.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 把自己的本地模型包装成可多人使用的服务。硬件只是起点，真正决定体验的，是对推理链路每个环节的理解。