企业官网建设流程全解析

如果你也做过类似的事——在 Hugging Face 榜单上看到一个模型跑分很高，然后兴冲冲地在自己的笔记本上部署，最后看着一卡一卡输出的 token 发呆——那这篇文章可能对你有点用。

我最近正好用自己的笔记本做了一轮本地 LLM 的 benchmark。不是那种几十万条数据的正式评测集，而是更贴近日常使用的那一种：一台普通笔记本，几个不同架构、不同量化等级的模型，记录实际能用的速度和内存。结论先说：本地跑 LLM 的基准测试，真正应该回答的从来不是“哪个模型最强”，而是“在我这台机器上，哪个配置最可用”。跑分只是手段，搞清楚自己的硬件边界才是目的。

这个判断来自一个很现实的观察：很多人在评论区晒出的 token/s 和你的实际体验完全对不上，不是人家撒谎，而是机器不同、量化不同、上下文长度不同、散热状态也不同。与其照搬别人的结果，不如自己跑一套可复现的本地评测流程。

1. 笔记本跑本地 LLM，真正的瓶颈不是模型参数

1.1 显存和内存带宽决定了理论天花板

大多数人第一眼看的是模型参数量。7B、13B、70B，再对比一下自己的显卡和内存，觉得“差不多能装下”。但参数量只决定了模型文件有多大，真正决定生成速度的，是内存带宽。

粗略理解，推理时要生成一个 token，通常需要把模型权重从头到尾读一遍。一个 7B 模型用 4bit 量化，权重大约是 4GB 左右。如果机器的内存带宽只有 40GB/s，那理论上每秒钟最多只能“读完”40GB 数据，配上 4GB 权重，理论生成上限就是 10 token/s 左右。如果你的内存带宽有 400GB/s，同样的权重理论上限就能到 100 token/s。所以笔记本跑本地模型时，经常出现“看起来不算大的模型，却跑不快”的情况，根因往往不是 CPU 不够快，而是内存带宽不够。

这里还要区分两种主流笔记本：

• Windows/Linux 笔记本 + 独立显卡：主要靠显存装模型。显存带宽很高，比如 16GB 显存的显卡通常有几百 GB/s 带宽，跑 7B 模型很快，但显存容量卡住模型大小。一旦模型超过显存容量，要么加载不了，要么走一部分 CPU 内存慢速推理，速度会断崖式下跌。
• Mac 笔记本 + 统一内存：CPU 和 GPU 共享一块内存，好处是内存容量可以很大，能塞下更大的模型，坏处是带宽上限取决于整台机器的设计，通常低于同价位独立显卡的显存带宽。所以 Mac 上跑 7B 模型不一定比 Windows 独显本快，但能跑的模型规模上限往往更大。

理解了这条底层逻辑，你就知道为什么只看“模型能不能跑”不够，还要看“它有多少数据要搬运、搬多快”。

1.2 量化精度不是越低越好：FP16、BF16、INT8、INT4 的取舍

热搜词里出现频率很高的 fp16、fp32、bf16 精度问题，实际是本地 LLM 绕不开的坎。简单列一下：

• FP32：32 位浮点，精度高，占用空间大，本地推理时很少直接用整个模型，因为太占内存。
• FP16：16 位浮点，精度和内存占用相对均衡，很多模型默认发布格式就是 FP16。
• BF16：也是 16 位，但动态范围比 FP16 更大。对深度学习来说，它不容易因为数值溢出变成 NaN，但尾数精度低一些。在很多推理场景下，BF16 比 FP16 更稳定。
• INT8：8 位整数量化，内存占用约为 FP16 的一半，速度通常更快，但权重精度下降。
• INT4：4 位量化，内存占用更小，能塞更大的模型，但质量损失风险最高。

很多人会默认用 INT4，因为加载快、省内存，跑分也漂亮。但量化不是越低越好，尤其是代码生成、多步推理、长文本一致性的任务，INT4 常常会输出一些“看起来通顺但逻辑不对”的内容。我的经验是：如果内存刚好能塞下模型，优先用 BF16 或 INT8；如果内存紧张到必须用 INT4，那就得先用代表性任务验证输出质量可接受，再决定是否长期使用。

还有一个容易误判的点：同一个量化标签，不同工具、不同实现跑出来的效果也不一样。比如q4_K_M是 llama.cpp 系列里的一个常用量化档位，它在多数模型上表现不错，但并不是所有模型都一样。真正靠谱的做法，是在同一台机器上切换精度，用同样的提示词跑一遍，对比输出、速度和内存。

1.3 散热和功耗决定了实际持续性能

笔记本和台式机最大的区别，是散热和功耗限制。一个模型刚加载时，可能跑得飞快；连续跑十分钟后，温度升高，功耗墙触发，频率一降，速度就慢下来了。很多人在笔记本上碰到“刚开始好好的，过一会儿就变慢”的情况，第一反应是模型有问题，其实往往是热降频。

所以做本地 LLM 评测时，不能只跑一次。至少要连续跑多轮，记录一段时间内的平均速度。如果你发现同一个配置第一轮和第十轮速度差距很大，那说明这台笔记本在持续负载下性能释放不稳定。

这也解释了为什么别人的跑分数据对你没有太大参考价值。台式机供电充足、散热更好，显卡还能跑更高的功耗档位；笔记本要考虑电池、充电器功率、模具散热和风扇策略。我一般会固定电源模式为“最佳性能”再开始评测，否则两轮测试可能跑在不同的性能策略下，结果根本不可比。

2. 我在笔记本上跑 LLM benchmark 的完整流程

2.1 先确定要回答的实际问题

直接打开一个模型就开始跑分，很容易陷入“参数调来调去但不知道在验证什么”的困境。我会先问自己三个问题：

• 这台电脑最高能跑多大的模型？
• 在可接受速度和内存占用下，用什么量化档位质量最好？
• 日常聊天、文档总结、简单代码生成，我该选哪个模型和配置？

这三个问题决定了评测的测试集和记录指标，而不是反过来先跑分再解释。

在测评之前，还有一个关键准备：确认可用内存或显存。比如一台 16GB 内存的 Mac，系统本身要占用 2-3GB，实际留给模型的大概 13GB 左右。如果模型文件是 15GB，加载后就会进入交换空间，速度会变得不可用。Windows 笔记本也一样，16GB 内存想要同时跑系统和 14GB 模型，大概率会撑爆物理内存。所以选模型时，先看模型文件大小，再对比可用内存，留出至少 20%-30% 余量。

2.2 准备统一的测试集和固定的上下文长度

为了让不同模型之间有可比性，输入条件必须一致。我一般会准备 5 到 10 条提示词，覆盖不同难度：

• 一句话问答，用来测首 token 延迟；
• 一段 300 字左右的中文材料总结，用来测中短上下文下的稳定性；
• 一段有 bug 的简单代码，让模型找问题，用来测代码能力；
• 一个需要多步推理的问题，用来测逻辑一致性；
• 一个需要从长文本中提取具体信息的任务，用来测长上下文能力。

每条提示词固定最大生成长度，比如 512 或 1000 token。上下文长度也固定，比如 4096 或 8192。上下文长度是非常容易被忽视的变量。同样一个模型，上下文长度从 2048 改成 8192，内存占用和推理耗时都会明显增加，如果你不固定这个参数，不同次测试就不可能比较。

2.3 用本地方案快速跑单条推理，记录三个关键指标

我通常用 Ollama 或 LM Studio 这类工具做第一轮验证。它们已经封装好了推理引擎，不需要自己写模型加载代码。如果你想更底层一些，也可以直接使用 llama.cpp 的绑定，但第一轮没必要，先把流程跑通更重要。

对着每条测试提示词跑一次，至少记录三个指标：

• 首 token 延迟（TTFT）：从输入到第一个输出 token 的时间。这个指标决定了用户点下发送按钮后，要等多久才能看到内容开始出现。对于一个聊天式应用，首 token 延迟很影响体感。
• 平均生成速度（token/s）：每秒生成多少个 token。长文输出时，这个速度决定用户会不会等得抓狂。
• 峰值内存/显存占用：模型加载后，实际吃掉了多少内存或显存。这个数字直接决定模型能不能在当前机器上运行。

单条跑通只说明流程没断，不代表稳定。接下来要做批量测试。

2.4 批量测试：连续跑多轮，观察内存、温度和速度

批量测试的目的是发现三类问题：热降频、内存持续增长、上下文累积异常。

把准备好的 5-10 条提示词循环跑 3 轮，每轮完成后记录总耗时和内存占用。如果速度逐轮下降，就要考虑是不是散热问题；如果内存只升不降，就要怀疑推理工具或框架是否存在资源不释放的问题；如果同样一条提示词在不同轮次里输出结果波动很大，就要检查上下文是否被截断，或者采样参数是否设置得太高。

有条件的话，把系统监控工具打开，看看 CPU/GPU 频率曲线。没有监控工具，就靠“机器是否变烫、风扇是否咆哮、速度是否下降”来做粗略判断。这其实已经能发现大部分问题。

注意：不要一上来就把批量数和并发数拉满。先用一条样例确认输入、输出和日志都正常，再慢慢加轮次。

2.5 把量化、上下文、并发都记下来，避免“测评结果不可复现”

一个很容易踩的坑是：跑完一轮，没有记录环境，过两天想复现时完全不知道当时用的是哪个配置。为了避免这种情况，我建议至少记录这些字段：

• 推理工具及版本（Ollama、LM Studio、llama.cpp 版本等）
• 模型原始名称和量化标签（比如q4_K_M、q8_0）
• 上下文长度设置
• 最大生成长度
• 采样参数：temperature、top_p 等
• 是否开启了 GPU offload，如果开了，offload 到哪一层
• 系统内存总量、可用内存、GPU 型号或芯片型号

如果不记录这些，你很可能测完就忘。更麻烦的是，不同推理框架的默认设置差异很大，同一个模型在 Ollama 和 LM Studio 下的速度可能差很多。刚开始你可能会以为是模型问题，最后发现是上下文长度或 GPU offload 配置不同。所以先建立一张环境记录表，再开始批量测试。

3. 跑分最容易被骗的三个地方

3.1 首 token 延迟和生成速度要分开看

很多观点只给一个 token/s，但这其实会掩盖真实体验。

举一个简单的例子：模型 A 首 token 延迟 4 秒，生成速度 30 token/s；模型 B 首 token 延迟 0.5 秒，生成速度 15 token/s。如果你要做一个聊天机器人，用户通常会感觉到模型 B 反应更快，因为问题一输入，内容马上开始蹦出来；模型 A 则要等 4 秒才看到第一个字，后面再快也有一种卡顿感。反过来，如果你要做长文档总结，最终输出几百 token，15 token/s 和 30 token/s 的差距就变得很重要。

所以评测时，TTFT 和 token/s 要分开记录。你的应用更看重哪个，就给它更高权重。

3.2 上下文长度会极大地影响内存和速度

同一个模型，在上下文长度 2048 下跑得很流畅，拉到 8192 后可能明显变慢。原因有两层：一是更长的 key-value cache 会占用更多内存；二是注意力计算复杂度会随序列变长快速增长。

更隐蔽的是，一些模型在短上下文下表现正常，一旦输入超过某个长度，就会丢失开头信息，或者出现重复输出。这个问题在量化模型里更明显。如果你只是用短促的问答测模型，测不出来长上下文稳定性；必须用一条足够长的真实资料去测。

我的做法是：挑一段 2000 字左右的文档，让模型在回答里提取开头、中间、结尾的三个具体细节。如果某个细节丢掉了，就说明当前模型和量化在这个上下文长度下不够可靠。不要只看“模型支持 128K 上下文”的说明，那个支持通常只代表能处理，不代表处理得好。

3.3 并发和流式输出会改变体感速度

如果你准备把本地模型接到一个小服务或前端应用里，就不能只看单请求跑分。

不同推理框架的并发策略差异很大。有的框架一次只能处理一个请求，后面的请求排队，用户等待时间会越来越长；有的框架支持多个请求并发，显存/内存占用会大幅上升。笔记本本身的资源有限，通常能稳定处理 1-2 个并发请求已经不错。评测时不用追求最大并发，而是问自己：在可容忍延迟下，能支持几个用户？

另外，流式输出会改变体感速度。同样的总生成时间，如果采用流式输出，用户会感觉内容在持续出现，等待焦虑会降低。但流式输出也会增加请求数据量，如果框架处理不好，反而可能拖慢整体响应。所以接入应用前，一定要用真实前端场景测一次，而不是只看纯推理数据。

3.4 量化等级会带来“分数幻觉”

量化等级和分数之间的关系很微妙。用 INT4 加载模型，内存占用低，同一台机器上可能跑出比 FP16 更快的 token/s，但这只是表面。

下面是一个通用参考表，不是具体模型数据，而是相对规律：

很多人只看 INT4 的速度快、内存省，就默认它最好。但如果你把模型用在代码生成或多步推理里，INT4 的错误率可能比 INT8 高出一截。我的建议是：先用高精度跑通业务验证，再尝试降级量化，对比输出质量和速度。别让跑分骗了你，真正有价值的是“在你的实际任务里，这个量化版本能不能稳定输出”。

4. 把一次评测沉淀成可复用的本地 LLM 评测框架

4.1 一个简单的五步评测法

一次成功的评测，不应该只是临时跑几个模型，而是沉淀成可复用的框架。我总结成五步：

1. 定场景：明确你要用模型干什么，比如聊天、代码、总结、Agent 工具调用。
2. 定输入集：固定 5-10 条有代表性的提示词，覆盖不同难度和上下文长度。
3. 定配置：记录模型量化、上下文长度、生成长度、采样参数、GPU offload 等。
4. 跑基线：先从最小配置（低量化、短上下文）跑通，再逐步放大。
5. 出报告：把每个配置的速度、内存、首 token 延迟、输出质量、失败情况整理成一张表。

这套流程的核心价值不是跑分，而是让所有对比都建立在同一组条件下。下次换模型、换量化、换机器，只需要替换对应配置字段。

4.2 评测报告里至少要有哪些指标

我建议至少记录这些维度：

• 模型名称 + 量化标签；
• 模型文件大小；
• 加载后峰值内存/显存；
• 上下文长度设置；
• 首 token 延迟（秒）；
• 平均生成速度（token/s）；
• 连续跑 1 次和连续跑 10 次后的速度差；
• 每条测试集上是否出现明显错误、重复、截断；
• 是否出现内存溢出或进程被杀死。

有了这些维度，你才能回答“这个模型到底适不适合这台机器”。只记一个 token/s 是没有意义的。

4.3 边界测试：如果换一批模型，框架怎么复用

这个评测框架适用于大多数本地模型。换模型时，保持输入集和参数不变，修改模型名称和量化标签就行。但有一点要注意：不同模型的 tokenizer 不同，同样 3000 字提示词，在不同模型下对应的 token 数可能不一样。所以更严谨的做法是在日志里记录本次输入实际消耗的 token 数，否则两个模型看起来上下文长度一致，实际输入长度差别很大。

还有一类场景需要额外处理：如果你打算把本地 LLM 接入 Agent 或工具调用链路，评测不能只看生成速度。你还需要检查：

• 模型是否正确地输出了工具调用格式；
• 返回的 JSON 是否合法；
• 多轮对话中是否保留了关键上下文；
• 连续调用工具后，模型是否会出现混乱。

这些用普通问答提示词测不出来。如果你准备做 AI 应用开发，建议在评测集中加入工具调用样例，比如“根据查询结果给出建议”这类任务。很多笔记本本地模型在单纯问答时看起来不错，一旦接入 Agent 编排框架就漏洞百出，这正是因为评测维度没有覆盖工具调用。

4.4 一个判断矩阵：什么场景选什么量化

结合常见使用场景，可以形成一套粗略判断：

核心原则是：在可用内存边界内，尽量选择更高精度的量化。如果高精度加载不了，再降一级，并用代表性任务验证输出是否还能接受。不要一开始就为了省内存选择最低量化。

5. 踩坑、排查和长期使用建议

5.1 从“单次跑通”到“批量稳定”之间的问题

很多人在第一次跑通本地 LLM 后会觉得很顺利，然后直接把它放到服务里长期运行，结果遇到各种问题。我见过最多的是这四类：

• 内存持续上涨，跑一段时间后进程被系统杀掉；
• 生成速度越来越慢，因为上下文被越补越长；
• 输出开始出现乱码、重复、格式丢失；
• 后端服务一次请求后，模型没有完整释放资源。

这些问题通常不是单一参数能解决的。我的经验是按“输入、环境、参数、工具边界”的顺序排查，而不是一上来就改模型。

5.2 一套排查链路：慢、崩溃、乱输出、爆内存

如果本地模型跑得慢，依次检查：

1. 看是否发生了热降频。在系统监控工具里看 CPU/GPU 频率是否比开始下降。如果下降，先让机器休息一下再测试。
2. 看内存/显存使用率。如果接近满，说明模型或上下文已经超出容量，操作系统正在频繁使用交换空间，速度自然会掉下来。
3. 看上下文长度设置。如果设置过大，即使当前输入很短，也可能分配了大量缓存空间。
4. 看 GPU offload 层数。如果只 offload 了一小部分层，大多数层在 CPU 上跑，速度瓶颈会非常明显。
5. 看是否使用了合适的量化。如果模型文件接近内存上限，就必须调整量化等级或换更小模型。

如果模型输出乱码或重复：

1. 先检查输入编码，尤其是中文内容，确保文件是 UTF-8。
2. 再看采样参数，temperature 是否设置过高，一般 0.2-0.8 之间更稳定。
3. 再看上下文是否被截断，导致模型失去重要信息。
4. 再尝试换一种量化，比如从 INT4 换到 INT8，看是否改善。
5. 如果换了量化还是乱输出，很可能是模型本身不适合该任务，应该换模型，而不是继续调参数。

如果进程崩溃或被系统杀掉：

1. 先看内存峰值是否超过物理内存。
2. 再看是否有多个模型同时加载，或者之前的进程没有释放资源。
3. 再检查日志中是否有 GPU、Vulkan、Metal 相关错误。
4. 最后确认推理工具版本和模型格式是否兼容。

这个排查链路不保证每一步都命中，但在大多数情况下，先怀疑资源，再怀疑参数，最后才怀疑模型，是效率比较高的方向。

5.3 笔记本长期跑本地 LLM 的实际建议

如果你打算长期在笔记本上跑本地模型，有几个建议值得认真考虑：

• 不要永远满载跑。笔记本不是服务器，长时间重负载会加速硬件老化，也容易触发热降频。日常使用中尽量分批处理任务，给机器留出冷却时间。
• 给任务排队，不要同时开两个模型。一个模型服务已经占用大量内存和计算资源，多开只会互相拖累。
• 使用支持异步任务或断点续跑的工具。这样即使遇到热降频，也不会因为一次失败损失所有工作。
• 注意存储空间。一个 7B 模型的不同量化版本可能加起来超过 20GB，评测时不必一次保留所有版本，测完一个删一个，避免硬盘被塞满。

另外，把电源模式固定下来。笔记本的“最佳性能”“平衡”“节能”模式会直接影响评测结果。如果不固定，同一天里两次测试可能跑出完全不同速度。

5.4 这个方案的适用边界：适合谁、不适合谁

最后把适用边界说清楚。

这套本地 LLM 评测框架适合：

• 有具体业务场景，想评估本地模型能不能满足需求的人；
• 只有笔记本，不想升级硬件，想找到现有机器可用配置的人；
• 做 AI 应用开发，需要给本地推理建立性能基线和质量基线的人；
• 对模型量化、上下文长度、内存占用有疑惑，需要一套实测方法的人。

这套框架不适合：

• 想严格复现论文 benchmark 的研究者。那需要统一硬件、统一评测集、更严谨的统计口径。
• 需要极高推理吞吐量的线上服务场景。那需要 GPU 服务器，而不是笔记本。
• 追求绝对输出质量的场景。本地模型在很多任务上仍然不如云上大模型，评测只能帮你在“本地可用”和“输出质量”之间找平衡，而不可能凭空拉高质量上限。

回到最开始的判断：在笔记本上跑本地 LLM 的 benchmark，最大的价值不是得到一张漂亮的分数表，而是搞清楚你自己的机器在什么配置下能稳定输出可用结果。我从这次评测里得到的不是“哪个模型最强”，而是一套可以复用的流程：先定场景，再定输入，统一配置，跑最小样本，最后看速度和质量的平衡。下一次拿到一台新笔记本，或者看到一个新模型，我只需要把模型名和量化标签换进去，很快就能判断“这个方案能不能在我的机器上用”。这种可复用的判断能力，比单次跑分结果重要得多。