企业官网建设流程全解析

最近我把同一个本地大模型分别放到了两台笔记本上跑了一遍，一台是搭载 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 读写，速度只会比这个理想值更低。但核心逻辑已经很清楚了：在单次对话、batch=1 的典型场景里，LLM 推理的瓶颈往往不是“算得快不快”，而是“能不能在一秒内把权重从头到尾读一遍”。

这一点和很多人印象里的“游戏显卡评测”不一样。游戏场景是大量三角形计算、纹理填充，GPU 算力起决定性作用；LLM 解码则更像流水线搬运，水管越粗，水流量越大。

1.2 核显跑 LLM 的真正上限是共享内存，不是 GPU 核心

核显没有独立显存，它一般采用共享内存架构，也就是复用系统内存。表面上系统内存可能很大，但内存带宽是有限的，而且要和 CPU、核显、其他硬件共享。再加上不少轻薄本为了省电只使用单通道内存，会让内存带宽进一步缩水。

RTX 5070 这类独显则完全不同。它拥有独立显存，显卡访问自己的专用显存时，不会和其他组件争抢带宽。这也是为什么在同一台笔记本上，独显和核显跑同一个模型，体验差距会非常夸张：不只是“快一点”和“慢一点”的区别，而是“能不能接受长期使用”的区别。

所以我在这次对比里最大的认知增量是：把“能不能跑起来”和“能不能当日常工具用”分开看。很多核显机器确实能把模型加载起来，甚至能正常输出，但它的输出节奏、首 token 延迟、长上下文表现，可能都达不到你心里的“可用”标准。

2. 同模型、两台机器，我到底是怎么跑的

在开始对比之前，我先理了一遍测试流程。因为如果直接把一个 7B 模型塞给核显机器，大概率“能加载但体验很差”，这个结果本身说明不了太多。更合理的做法是：先确认硬件边界，再选模型和量化，最后用同一个推理引擎跑同一份模型。

2.1 模型和量化怎么选：先看显存，再谈体验

选模型的第一步不是看口碑，而是看显存或内存能不能装下。我整理了一个简单的步骤：

1. 如果是独显，先打开任务管理器或nvidia-smi看看“专用 GPU 内存”；如果是核显，看“共享 GPU 内存”和系统总内存。
2. 找到模型的 GGUF 文件大小。社区里一般会标注Q4_K_M、Q5_K_M、Q8_0等量化版本。
3. 估算：模型文件大小 + 上下文 KV cache + 系统开销，最好能控制在可用显存/内存的 70% 以内，否则运行时会比较紧张。
4. 选择模型系列时，新手可以优先看社区生态好、文档多的 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_LAYERS="1" 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。其实这里的核心问题是：模型体积直接决定了每次推理需要搬运的数据量，也直接决定了带宽压力和数据精度。

从这个表能看出来，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_LAYERS=1或只放一小部分层，观察速度变化。
• batch size：如果引擎支持，把 batch size 调小，减少单次推理对内存带宽的峰值压力。
• 采样参数：temperature、top_p等参数主要影响随机性，对速度影响不大，但不要为了效果反复生成太多次。

另外，核显机器跑模型前，最好关掉大多数后台应用。浏览器标签页、编译工具、大型 IDE 都在争用内存和带宽，轻则让推理变慢，重则直接导致内存不足。

5.3 一套选型清单：先跑通再优化最后工程化

我更建议把核显机器的定位看成“实验环境”，而不是“生产工具”。在使用上，可以按三步走：

1. 先跑通：选一个最小的模型，比如 1B 或 1.5B 的 Q4 版本，确认引擎能启动、输出正常。
2. 再优化：在保证能跑通的基础上，逐步换更大的模型或更高级的量化，记录首 token 延迟、生成速度、显存/内存占用，找到适合当前硬件的档位。
3. 最后工程化：如果以后要接入项目，至少需要把模型包装成 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 推理速度异常慢的排查链路

速度问题不能只看“慢”这一个现象。我一般会按下面的顺序排查：

1. 先看现象：是首 token 很慢，还是后面每个字都很慢，还是时快时慢？这决定了排查方向完全不同。
2. 再看输入：上下文是不是已经很长了？之前对话累积的 token 数量是不是过多？
3. 再看环境：内存是否双通道？显存是否接近占满？后台有没有大型程序在跑？
4. 再看参数：GPU 层数是不是设成了 0？上下文长度是不是过高？量化是不是太“重”？
5. 最后看工具边界：引擎版本、驱动版本、系统限制，甚至模型文件是否损坏，都可能影响最终表现。

我特别想强调一个容易忽略的坑：核显机器如果 GPU offload 生效，但系统内存是单通道，速度依然会很明显地变慢。单通道内存的带宽只有双通道的一半左右，同一个模型跑起来，差距可能比预想更大。

6.3 显存不足和内存不足的表现与处理

显存不足在独显上通常表现为：加载模型时报错、只加载部分层到 GPU，或者运行到一半直接被系统终止。这时候优先换更小、量化更低的模型，或者减小上下文长度。

内存不足在核显机器上更危险，因为共享内存意味着系统内存和显存共用。一旦内存被模型吃满，整个系统都可能无响应。16GB 内存跑 7B Q4 模型会比较极限，我更建议至少 32GB 内存，同时记得开启双通道。

如果只是个人学习用途，不想为一个实验就买独显机器，核显 + 小模型 + 短上下文是一个能接受的组合。如果想把本地模型真正变成日常工具，独立显存带来的带宽和容量优势，确实会直接决定体验上限。

这次对比最让我意外的，不是 RTX 5070 跑得比核显快，而是“能跑”和“能用”之间隔着一条明确的硬件分界线。如果你正在犹豫要不要为本地 LLM 加一块独显，我的建议是先想清楚你要跑多大的模型、多长的上下文，以及能不能接受慢速输出。如果只是学习推理原理，核显足够；如果想让本地模型替代日常对话、笔记总结或代码辅助工具，独显的独立显存和更高带宽，才是真正值得为那部分体验付出的预算。

工具选型走到最后，永远不是看参数高多少，而是看它能否匹配你每天的真实工作流。