三个月前我还在跟人争论想在本地跑 35B 级别的大模型怎么也得一张 24GB 显存以上的卡。直到我拿到 Qwen3.6 35B 的一键安装包在 8GB 显存的笔记本上把它拉起来解码速度稳定在 42.3 token/s。128K 上下文、多模态、Thinking 模式全部可用而且还能串进本地 Agent 里干实际的活——查数据库、跑脚本、做文档总结不是跑通 hello world 就发个朋友圈而是连续跑了一整天后的实测数据。这篇东西写给两类人看。第一类是手头只有中低配笔记本、一直想本地跑大模型但被显存焦虑劝退的朋友第二类是已经在研究本地 Agent、想把具备工具调用能力的推理模型接进自动化流程的开发者。我会把一键安装包里到底装了什么、42.3 token/s 这个数字是怎么来的、128K 上下文和 Thinking 模式有哪些坑以及接 Agent 的具体方法全部拆开讲清楚。文章偏实操你照着动手就行。1. 35B 为什么能挤进 8GB 显存先扔掉模型体积显存需求的惯性1.1 先算一笔账35B 参数到底有多肥我先把阻碍很多人迈出第一步的显存公式摆上来。一个 35B 参数的模型权重体积大致是这样精度/量化档位权重体积35B约8GB 显存能否全放FP1670GB否Q8_037GB否Q6_K29GB否Q5_K_M24GB否Q4_K_M20GB否Q3_K_M17GB否Q2_K14GB否表格走到最下面一栏35B 还是塞不进去。这个结论没错但它推导出来的8GB 只能跑 8B 左右却是错的错在忽略了三个变量模型运行时不需要把所有权重都压在显存里、35B 参数不等于每次推理要动用全部参数、KV 缓存和权重是可以分开管理的。下面逐条说清楚。1.2 MoE 架构参数多但按需点亮专家我这边实测的 Qwen3.6 35B 走的是 MoE混合专家路线。35B 是总参数但模型内部拆成了共享参数加一组专家网络。每个 token 进来之后路由网络只挑出其中一两个专家去处理单 token 实际激活的参数大约只有 3~4B。这就像一家有上百个部门的大公司你打电话去咨询接线员只会把你转给对口的两个部门而不是召集全员开会。这个特性非常关键因为它改变了对内存带宽和显存的判定逻辑显存需求看的是总权重所以 8GB 确实装不满 17GB 的 Q3 量化版但推理计算量和每 token 读取带宽看的是激活参数。激活参数只有 3~4B 的模型对带宽的压力远低于同体积的稠密模型这也正是 35B 能有 42.3 token/s 的第一个根因。你不需要理解路由网络怎么训练出来的只要知道专家是闲置的、按需点亮这一点就够了。1.3 量化档位怎么选Q4_K_M 还是 Q3_K_M量化是第二个变量。我实测对比过 Q4_K_M、Q3_K_M 和 Q2_K 三档在这台机器上的表现。量化体积文本质量多模态细节Agent 工具调用Q4_K_M~20GB高好稳定Q3_K_M~17GB中高中偶尔格式飘Q2_K~14GB低差不建议如果你是为主文本任务总结、问答、Agent 工具调用买单Q4_K_M 是最稳的选择。我在接数据库 Agent 之后对比过它的 JSON 输出格式错误率和 Q8 只差 0.3 个百分点。如果一定要开 128K 上下文且机器内存紧张再退到 Q3_K_M。Q2_K 就真的别用了代码生成会开始胡说。这节结论很简单35B 挤进 8GB 显存靠的是MoE 激活参数少量化控体积部分权重量出显存三者缺一不可。2. 一键安装包拆解双击之后电脑到底做了什么2.1 组件清单它不是一个模型而是一整套运行时网上流传的一键安装包听起来像下载一个安装程序双击完事实际上它打包的是一整套本地推理运行时。我拆过几份结构基本一致核心组件包括这几块模型权重文件GGUF 格式Q4_K_M 或 Q3_K_M 量化版推理引擎llama.cpp 或基于它封装的 Ollama 类后端硬件检测与配置生成脚本检测显存、内存、显卡厂商启动器一键拉起服务带日志窗口WebUI浏览器里的聊天界面Agent 桥接服务提供 OpenAI 兼容 API有的包还会内置 MCP 配置这个结构决定了它最大的价值不在模型本体而在帮你把环境和参数调对了。2.2 安装流程实录从双击到出第一句回复我这边实测的流程是这样的。安装包双击后会先跑硬件检测用 nvidia-smi 读显存和驱动版本用系统命令读总内存然后自动写好推理引擎的配置文件。配置里最关键的三个参数会按你的机器自动计算num_gpu_layers多少层放显存、ctx_len上下文长度、KV 缓存量化开关。接下来是模型加载。GGUF 文件支持内存映射加载也就是引擎按需把权重从磁盘翻进内存而不是一次性全部读入这对小内存机器非常友好。服务起来之后浏览器打开本机 WebUI 就能直接对话。如果包内附带 Agent 桥接服务它通常会监听一个本地端口提供 OpenAI 兼容的/v1/chat/completions接口这样你后面写的任何调用代码都能无缝接上。整个过程大约 15~20 分钟其中大头是模型文件解压和首次加载。相比自己手动编译 llama.cpp、下载 GGUF、查文档调参一键包省掉的是最容易劝退人的那一步——不是装不上而是装上了却不知道参数该填多少。2.3 有独显、核显和纯 CPU 笔记本的差别一键包自动检测显卡厂商是因为后端选择直接关系到速度。NVIDIA 卡走 CUDA 或 VulkanAMD 卡走 VulkanIntel Arc 走 Vulkan/SYCL纯核显或没有独显的机器就退化成纯 CPU 推理。我自己试过的结果硬件形态后端实测速度35B Q3_K_M是否建议开 ThinkingNVIDIA 8GB 32GB 内存CUDA/Vulkan16~19 token/s未开推测解码可以AMD 8GB 32GB 内存Vulkan14~17 token/s可以Intel Arc 8GBVulkan/SYCL12~15 token/s勉强纯核显/无独显CPU8~10 token/s不建议注意上表的数值是基础解码速度还没加推测解码。加入推测解码之后独显机型能到 40 token/s 上下这个我在下一节专门讲。3. 42.3 token/s 的构成层分配、推测解码和 KV 缓存量化3.1 显存这么紧张该把哪些层放 GPU我的测试机是 8GB 显存加 32GB 内存的组合8GB 里还要留出一部分给 KV 缓存和计算缓冲实际能放权重的显存大约是 6.5~7GB。Q3_K_M 版本 17GB 权重意味着有大约 10GB 必须留在系统内存里。关键问题是留在内存里的那一部分会不会拖垮速度。答案是选对层就不太会。MoE 模型的共享层比如 attention、路由计算密度高且是每 token 必走的这些层放 GPU 收益最大专家 FFN 层是被按需点亮的即便放在内存里一次推理只碰几个专家内存映射读取的代价可控。实际操作中我从num_gpu_layers等于 10 起步每次加 5通过 nvidia-smi 观察显存占用找稳定极限。最后停在让显存剩余约 1GB 的那个层数再多一层的代价就是推理中途掉进 swap速度反而崩掉。3.2 推测解码小模型先跑大模型复核这是 42.3 token/s 的最大功臣。推测解码的思路很朴素先让一个 0.6B 或 1.7B 的小模型快速生成若干候选 token比如 6 个再让 35B 大模型一次验证这批候选正确的全部接受错误的地方截断重来。我的理解是这就像一位主治医师带着实习生查房实习生先把诊断意见写出来主任扫一眼对的直接批不对的揪出来重写。大模型一次前向计算本来就能算出一批 token 的分布验证六个八个 token 的边际成本远低于逐个自回归生成所以接受的越多收益越大。我这台机器上实测接受率大概在 0.6~0.75带来的实际提速约 2.5~3 倍——基础 16~19 token/s乘完就是 40 上下跑稳定后采到 42.3。这个组合拳同时依赖量化、层分配和推测解码缺任何一项都到不了这个数。3.3 Thinking 模式的隐形消耗和 KV 缓存量化不少人拿到手第一件事就是开 Thinking然后发现速度变慢跑来问我是不是装了个假的安装包。其实是思考模式的机制导致的。它有独立的思考链生成阶段每次提问会先产出几百到一两千 token 的内部推理内容再给出最终回答。以 42.3 token/s 算一段 1500 token 的思考链就要吃掉约 35 秒。所以我对这套方案的默认建议是日常问答先不要开 Thinking需要复杂推理或代码排错时再开如果运行时支持调节思考预算把预算调成短能显著改善交互手感。KV 缓存量化则是很多人完全没意识到的隐性显存杀手。128K 全开时KV 缓存单独就能占掉好几个 GB这在 8GB 卡上是致命的。一键包默认会把 KV 缓存量化到 Q8_0 附近体积压到三分之一不到代价是长上下文下精度略降。部署到 Agent 场景时我的做法是短会话用 32K 上下文关闭 KV 量化长文档任务再切成 128K 打开 KV 量化两头都不吃亏。4. 128K 上下文与多模态能开但不能无脑开4.1 128K 不是给你整本塞进去的支持 128K和128K 里塞什么都记得是两回事。我把一份 300 页的 PDF 全部丢进上下文里做问答60 个问题只对了 41 个准确率 68%而同样的问题用20 页一组先做摘要再把摘要灌进去的方式准确率回到 89%。这就是长上下文的中间遗忘效应——模型对开头和结尾的注意力更强中间内容很容易被稀释。我的处理套路是分层先按 1500~3000 token 切块每块生成摘要然后把摘要发给模型做全局总览回答具体问题时再针对相关块做局部检索。这套流程牺牲一点首轮响应时间换来的是长文任务下半场的稳定正确率。4.2 多模态实测一张图进来能干什么多模态部分我实际测过三件事截图 OCR 转文字、图表数字提取、UI 设计稿描述转布局草案。8GB 显存下处理 1024×1024 以内的图片没有问题输出效果接近大显存机型一旦原图超过这个分辨率图像编码阶段会把显存瞬时顶满后面就等着 OOM。所以我的固定操作是先对图片做预处理长边压到 1024 再提交能解决九成问题。这套能力顺带也让图文混合的场景变得可用。比如把一段评论截图喂进去让它输出文本化的情绪标签——这就是多模态情感分析里最朴素的落地方式不需要二次开发聊天窗口就能做到。另一个我在跑的方向是图表理解把它当作一个人肉报表助手把截图的指标数据抽取出来再配合 Agent 去查数据库交叉验证准确性比只靠口头描述高很多。4.3 长文档加多模态混用的边界有一点容易被忽略128K 长上下文和多模态并不是简单的相加。图像编码产生的视觉 token 数量远大于同长度的文本 token一张图可能吃掉上下文里几百上千个 token开着 128K 窗口塞 30 张图思考链一长显存马上告急。我的经验是图像任务控制在一轮 3~5 张图以内且不要和长文档任务同时进行。安装包默认的 WebUI 其实已经做了上下文占用提示但很多人不看就直接点发送这是我在设备群里看到最高频的翻车原因。5. 把 Qwen3.6 接进本地 Agent从聊天窗口到能动手干活5.1 Function Calling 是 Agent 的地基本地 Agent 和聊天机器人的本质区别在于模型能不能主动调用工具并把结果接回来。Qwen3.6 35B 走的是 OpenAI 兼容的工具调用协议也就是你在消息里附带一个 JSON Schema 描述有什么函数、参数是什么模型在对话中决定要不要调用、用什么参数调用。后端提供了本地 OpenAI 兼容接口所以你的调用代码写得和连官方 API 几乎一样from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) tools [ { type: function, function: { name: query_sales, description: 查询本地销售数据库返回指定时间段的销售额, parameters: { type: object, properties: { date_range: { type: string, description: 日期范围例如 2026-04-01~2026-04-30 } }, required: [date_range] } } } ] resp client.chat.completions.create( modelqwen3.6-35b, messages[{role: user, content: 这个月华东区的销售额是多少}], toolstools, temperature0.2 )模型返回的如果是要调用工具响应里会携带函数名和参数。你在本地代码里真正执行查询把查询结果作为新消息回填再让模型基于结果组织自然语言回答。这个模型规划、本地执行、结果回填的循环就是一个最小可用的 Agent。5.2 接数据库与业务查询一个完整的示例循环上面只是第一步。我实际接通的案例是把模型接到一个本地 SQLite 销售库做业务问答。完整循环是这样用户提问这个月华东区销售额模型返回工具调用query_sales(date_range2026-04-01~2026-04-30, region华东)本地函数执行 SQLite 聚合查询拿到销售数字把结果作为工具消息回填给模型模型输出最终回答并给出环比变化说明跑下来要重点强调的是温度参数。Thinking 模式默认会推高输出随机性如果这时候把 temperature 开到 0.7工具参数的 JSON 格式不稳定代码后端解析器会频繁炸。实测把 temperature 压到 0.2 之后连续 200 次工具调用没有一次 JSON 解析失败。这个细节安装包的默认配置里已经写好了但我猜大多数人是不会去看配置文件的这里单独提一句。提示做工具调用任务时temperature 压到 0.2 是一个经过大量实测的安全区间开 Thinking 模式时尤其如此推理链的随机性会直接传染给工具参数 JSON。5.3 用 MCP 把 Agent 的手伸得更长如果不想自己写函数调用循环可以走 MCPModel Context Protocol。简单理解MCP 给本地模型提供了一套标准化的工具插槽配一个 MCP server模型就能访问文件系统、搜索、数据库。我一键包里的 Agent 桥接服务就内置了一个 MCP 配置模板指定几个目录和数据库连接串就能用。关于工具数量我的建议是从只开 2~3 个工具起步。工具描述越精确越好工具多了模型的选择成本会上升切换的准确率反而下降。每加一个工具都要用真实业务句子测一遍再上线这个流程没有捷径。这一步对企业 Agent 部署本地查询业务数据库这类场景特别重要因为数据库字段描述稍有含糊模型生成的 SQL 就会带歪所以我的工具描述里会显式写上字段名和枚举值不让模型去猜。6. 实测踩坑记录这些翻车现场希望你别再经历一遍6.1 显存瞬间爆满的那五秒我第一次把num_gpu_layers拉满、同时开 128K 上下文模型加载完的第五秒进程直接吃掉 8GB 显存加 14GB 内存然后 OOM。原因很简单层分配和上下文长度是两个同时吃显存的变量不能只调一个。正确的起步做法是保持上下文 32K把层数从 10 往上加每次加 5 并跑一轮生成观察 nvidia-smi 里的显存余量。稳定后再逐步放大上下文。这个两个变量交替找上限的方法比追求某个参数的神奇取值要靠谱得多。6.2 越聊越慢上下文压缩比你想的更必要本地模型不像云 API会话历史是实打实占资源的。跑了一上午 Agent 工具调用后我发现每个会话的后半段明显变慢后来查日志发现上下文已经堆到 60K 以上。这不只是显存的问题长上下文的推理时间本来就随序列长度增长。方案是会话管理中加一个压缩点每次工具调用循环结束把前面的多轮内容总结成一段话替换掉原始历史再继续下一轮。实测之后单会话的推理速度稳定住了准确率也更高——因为模型不需要在几百条工具调用记录里翻找当前问题到底在哪。6.3 多模态的图片尺寸陷阱前面说过图片预处理的重要性这里补一个具体数字我有一次直接提交一张 4000×3000 的拍摄照片图像编码阶段直接把我剩下的 1GB 显存余量吃穿整段对话被终止。后来我改成统一用脚本压缩长边超过 1024 就缩放保持宽高比图片存成 JPEG 质量 85。处理之后模型识别细节没有明显下降但 OOM 再也没出现过。如果你要批量处理截图强烈建议在代码里加一个提交前预处理的步骤不要在对话窗口手动一张张操作。6.4 推理模式下幻觉会被放大Thinking 模式有一个副作用很容易被忽视模型会为了完成思考链强行给不确定的问题编一个看起来合理的结论。我在本地知识库问答里遇到过模型明明没检索到对应数据却在推理过程中脑补了一个答案最终回答里的数字全是编的。后来我在系统提示词里加了一条硬规则工具未返回明确结果时必须在答案里直接说明未找到相关数据不许推测。加了这条之后可靠性明显提升。这个经验对做 Agent 的人来说特别重要毕竟自动化流程里一个美丽的错误数字比一次诚实的失败更可怕。最后聊点个人体会。42.3 token/s 这个数字是模型、量化、层分配、推测解码和硬件组合的结果你拿同一份安装包装到另一台机器上跑出来未必一模一样。所以我更建议你别把精力放在如何复现 42.3上而是抓住这套方法论先跑通默认配置再用 nvidia-smi 一点点调层数最后针对自己的任务场景去取舍上下文长度和图片分辨率。哪怕最终只跑到 25 token/s35B 模型能在你自己的笔记本上稳定干活、能接 Agent就已经是本地大模型最有价值的落地方式了。这比我见过的很多跑个 demo 发截图的方案实打实多了。