如果你也做过类似的事——在 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 绕不开的坎。简单列一下FP3232 位浮点精度高占用空间大本地推理时很少直接用整个模型因为太占内存。FP1616 位浮点精度和内存占用相对均衡很多模型默认发布格式就是 FP16。BF16也是 16 位但动态范围比 FP16 更大。对深度学习来说它不容易因为数值溢出变成 NaN但尾数精度低一些。在很多推理场景下BF16 比 FP16 更稳定。INT88 位整数量化内存占用约为 FP16 的一半速度通常更快但权重精度下降。INT44 位量化内存占用更小能塞更大的模型但质量损失风险最高。很多人会默认用 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 秒才看到第一个字后面再快也有一种卡顿感。反过来如果你要做长文档总结最终输出几百 token15 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但这只是表面。下面是一个通用参考表不是具体模型数据而是相对规律量化方式内存占用生成速度输出质量风险FP16高受带宽限制较低BF16高受带宽限制较低数值范围更稳INT8中中等偏快中低某些任务有明显损失INT4低快高尤其代码、逻辑、长文本任务很多人只看 INT4 的速度快、内存省就默认它最好。但如果你把模型用在代码生成或多步推理里INT4 的错误率可能比 INT8 高出一截。我的建议是先用高精度跑通业务验证再尝试降级量化对比输出质量和速度。别让跑分骗了你真正有价值的是“在你的实际任务里这个量化版本能不能稳定输出”。4. 把一次评测沉淀成可复用的本地 LLM 评测框架4.1 一个简单的五步评测法一次成功的评测不应该只是临时跑几个模型而是沉淀成可复用的框架。我总结成五步定场景明确你要用模型干什么比如聊天、代码、总结、Agent 工具调用。定输入集固定 5-10 条有代表性的提示词覆盖不同难度和上下文长度。定配置记录模型量化、上下文长度、生成长度、采样参数、GPU offload 等。跑基线先从最小配置低量化、短上下文跑通再逐步放大。出报告把每个配置的速度、内存、首 token 延迟、输出质量、失败情况整理成一张表。这套流程的核心价值不是跑分而是让所有对比都建立在同一组条件下。下次换模型、换量化、换机器只需要替换对应配置字段。4.2 评测报告里至少要有哪些指标我建议至少记录这些维度模型名称 量化标签模型文件大小加载后峰值内存/显存上下文长度设置首 token 延迟秒平均生成速度token/s连续跑 1 次和连续跑 10 次后的速度差每条测试集上是否出现明显错误、重复、截断是否出现内存溢出或进程被杀死。有了这些维度你才能回答“这个模型到底适不适合这台机器”。只记一个 token/s 是没有意义的。4.3 边界测试如果换一批模型框架怎么复用这个评测框架适用于大多数本地模型。换模型时保持输入集和参数不变修改模型名称和量化标签就行。但有一点要注意不同模型的 tokenizer 不同同样 3000 字提示词在不同模型下对应的 token 数可能不一样。所以更严谨的做法是在日志里记录本次输入实际消耗的 token 数否则两个模型看起来上下文长度一致实际输入长度差别很大。还有一类场景需要额外处理如果你打算把本地 LLM 接入 Agent 或工具调用链路评测不能只看生成速度。你还需要检查模型是否正确地输出了工具调用格式返回的 JSON 是否合法多轮对话中是否保留了关键上下文连续调用工具后模型是否会出现混乱。这些用普通问答提示词测不出来。如果你准备做 AI 应用开发建议在评测集中加入工具调用样例比如“根据查询结果给出建议”这类任务。很多笔记本本地模型在单纯问答时看起来不错一旦接入 Agent 编排框架就漏洞百出这正是因为评测维度没有覆盖工具调用。4.4 一个判断矩阵什么场景选什么量化结合常见使用场景可以形成一套粗略判断使用场景优先选择可以尝试不建议日常问答、闲聊INT8INT4无明显上限文档总结、信息提取INT8 / BF16INT4上下文很长时慎用 INT4代码生成、代码补全BF16 / INT8INT8建议先测一轮 INT4 错误率多步推理、数据分析BF16 / FP16INT8INT4 风险较高Agent 工具调用BF16 / FP16INT8必须测试工具调用格式核心原则是在可用内存边界内尽量选择更高精度的量化。如果高精度加载不了再降一级并用代表性任务验证输出是否还能接受。不要一开始就为了省内存选择最低量化。5. 踩坑、排查和长期使用建议5.1 从“单次跑通”到“批量稳定”之间的问题很多人在第一次跑通本地 LLM 后会觉得很顺利然后直接把它放到服务里长期运行结果遇到各种问题。我见过最多的是这四类内存持续上涨跑一段时间后进程被系统杀掉生成速度越来越慢因为上下文被越补越长输出开始出现乱码、重复、格式丢失后端服务一次请求后模型没有完整释放资源。这些问题通常不是单一参数能解决的。我的经验是按“输入、环境、参数、工具边界”的顺序排查而不是一上来就改模型。5.2 一套排查链路慢、崩溃、乱输出、爆内存如果本地模型跑得慢依次检查看是否发生了热降频。在系统监控工具里看 CPU/GPU 频率是否比开始下降。如果下降先让机器休息一下再测试。看内存/显存使用率。如果接近满说明模型或上下文已经超出容量操作系统正在频繁使用交换空间速度自然会掉下来。看上下文长度设置。如果设置过大即使当前输入很短也可能分配了大量缓存空间。看 GPU offload 层数。如果只 offload 了一小部分层大多数层在 CPU 上跑速度瓶颈会非常明显。看是否使用了合适的量化。如果模型文件接近内存上限就必须调整量化等级或换更小模型。如果模型输出乱码或重复先检查输入编码尤其是中文内容确保文件是 UTF-8。再看采样参数temperature 是否设置过高一般 0.2-0.8 之间更稳定。再看上下文是否被截断导致模型失去重要信息。再尝试换一种量化比如从 INT4 换到 INT8看是否改善。如果换了量化还是乱输出很可能是模型本身不适合该任务应该换模型而不是继续调参数。如果进程崩溃或被系统杀掉先看内存峰值是否超过物理内存。再看是否有多个模型同时加载或者之前的进程没有释放资源。再检查日志中是否有 GPU、Vulkan、Metal 相关错误。最后确认推理工具版本和模型格式是否兼容。这个排查链路不保证每一步都命中但在大多数情况下先怀疑资源再怀疑参数最后才怀疑模型是效率比较高的方向。5.3 笔记本长期跑本地 LLM 的实际建议如果你打算长期在笔记本上跑本地模型有几个建议值得认真考虑不要永远满载跑。笔记本不是服务器长时间重负载会加速硬件老化也容易触发热降频。日常使用中尽量分批处理任务给机器留出冷却时间。给任务排队不要同时开两个模型。一个模型服务已经占用大量内存和计算资源多开只会互相拖累。使用支持异步任务或断点续跑的工具。这样即使遇到热降频也不会因为一次失败损失所有工作。注意存储空间。一个 7B 模型的不同量化版本可能加起来超过 20GB评测时不必一次保留所有版本测完一个删一个避免硬盘被塞满。另外把电源模式固定下来。笔记本的“最佳性能”“平衡”“节能”模式会直接影响评测结果。如果不固定同一天里两次测试可能跑出完全不同速度。5.4 这个方案的适用边界适合谁、不适合谁最后把适用边界说清楚。这套本地 LLM 评测框架适合有具体业务场景想评估本地模型能不能满足需求的人只有笔记本不想升级硬件想找到现有机器可用配置的人做 AI 应用开发需要给本地推理建立性能基线和质量基线的人对模型量化、上下文长度、内存占用有疑惑需要一套实测方法的人。这套框架不适合想严格复现论文 benchmark 的研究者。那需要统一硬件、统一评测集、更严谨的统计口径。需要极高推理吞吐量的线上服务场景。那需要 GPU 服务器而不是笔记本。追求绝对输出质量的场景。本地模型在很多任务上仍然不如云上大模型评测只能帮你在“本地可用”和“输出质量”之间找平衡而不可能凭空拉高质量上限。回到最开始的判断在笔记本上跑本地 LLM 的 benchmark最大的价值不是得到一张漂亮的分数表而是搞清楚你自己的机器在什么配置下能稳定输出可用结果。我从这次评测里得到的不是“哪个模型最强”而是一套可以复用的流程先定场景再定输入统一配置跑最小样本最后看速度和质量的平衡。下一次拿到一台新笔记本或者看到一个新模型我只需要把模型名和量化标签换进去很快就能判断“这个方案能不能在我的机器上用”。这种可复用的判断能力比单次跑分结果重要得多。