1. 为什么要在本地跑35B大模型，而不是直接调云端API

很多人第一次听到“本地部署35B大模型”的反应是：现在云端API又便宜又快，为什么还要折腾自己的机器？这个问题我在过去一年里被问过不下几十次，每次我都用同一个场景回答——当你手头有一批涉及内部业务逻辑的文档需要做批量摘要、分类、抽取结构化信息时，把这些原文一段段往云端接口里送，心里那道坎是过不去的。不是技术问题，是数据边界问题。

本地部署的核心价值从来不是“省钱”或者“跑分好看”，而是数据不出本机和推理过程完全可控这两件事。35B这个参数量级恰好卡在一个很微妙的位置：它比7B、8B的小模型明显更“聪明”，在中文理解、长文摘要、代码补全这些任务上能给出可用的结果；同时又不像70B、405B那样对显存和内存提出离谱要求，一台配置合理的工作站或者高性能笔记本就能扛住。换句话说，35B是“个人能负担得起的智能上限”附近的一个甜点。

那WorkBuddy在这里扮演什么角色？简单说，它是一个把“模型下载、量化、推理引擎、对话界面、工具调用”这一整套链路打包好的本地工作台。你可以把它理解成一个专门为本地大模型服务的控制面板——模型文件放在哪、用哪个推理后端、上下文窗口开多大、要不要挂知识库、要不要开放工具调用权限，这些原本需要写配置文件、敲命令行才能搞定的事情，在WorkBuddy里变成了可视化操作。对于不想把时间花在环境折腾上、只想尽快用起来的人来说，这个价值是实打实的。

至于Intel算力引擎的加持，这一点值得单独说。很多人对Intel平台的印象还停留在“核显只能亮机”，但实际上近几代Intel处理器在AI推理加速上做了不少工作，尤其是配合OpenVINO这类推理运行时，CPU和集成显卡可以协同分担矩阵运算负载。在35B模型这种内存带宽敏感、计算密度中等的场景下，Intel平台的表现比很多人预期的要好。后面我会专门用一章拆解这里面的原理和实测数据。

这篇文章适合三类人看：一是手里有一台还算过得去的电脑、想试试本地大模型但被各种教程劝退的人；二是已经在用云端API、但开始在意数据边界和调用成本的人；三是想搞清楚“端云混合”到底怎么落地、什么任务放本地什么任务放云端的人。我会从硬件判断、部署实操、性能调优、场景分工四个层面把这件事讲透，中间穿插我自己踩过的坑和验证过的参数。

2. 先搞清楚你的机器能不能跑：35B模型的真实资源账

2.1 显存、内存、量化精度三者的换算关系

在动手之前，必须先算清楚一笔账：35B参数的模型，到底需要多少内存或显存才能跑起来。这个账不算清楚，后面下载了几十GB的模型文件发现加载失败，时间就白费了。

核心公式其实不复杂：模型加载所需空间 ≈ 参数量 × 每参数字节数 + 运行时开销。这里的“每参数字节数”取决于量化精度。常见的量化格式和对应关系如下：

这张表是理论值，实际占用会略高一些，因为还有KV Cache、中间激活值、推理框架自身的开销。以Q4_K_M为例，35B模型权重约20GB，加上8K上下文的KV Cache（大约2-4GB，取决于模型结构和批大小），再加上推理引擎本身的内存占用，实际需要准备24-28GB的可用内存或显存。

这就引出一个关键判断：如果你的机器只有16GB内存、没有独立显卡，那35B模型基本跑不动，强行加载会频繁触发磁盘交换，速度慢到无法使用。如果你的机器有32GB内存，可以跑Q4量化版本，但上下文不能开太大。如果有64GB内存或者一张16GB以上显存的显卡，那就可以比较从容地跑Q4甚至Q5量化版本。

2.2 Intel平台的内存带宽为什么是关键瓶颈

大模型推理有一个反直觉的特点：它往往不是算力瓶颈，而是内存带宽瓶颈。每生成一个token，模型都需要把全部权重从内存里读一遍（或者至少读大部分）。35B模型在Q4量化下约20GB权重，如果内存带宽是50GB/s，那理论上每秒最多读2.5遍权重，对应大约2.5个token/s的生成速度上限。实际因为计算调度、缓存命中率等因素，还会更低。

这就是为什么Intel平台在本地推理上有其独特价值。近几代Intel处理器支持双通道DDR5内存，带宽可以到80-90GB/s；如果是工作站平台配合四通道甚至八通道内存，带宽能上到150GB/s以上。这个带宽水平虽然比不上高端独立显卡的显存带宽，但对于35B Q4模型来说，已经能跑到每秒5-8个token的可用水准。

另外，Intel的集成显卡（特别是Arc核显或者较新的UHD Graphics）可以通过OpenVINO与CPU协同工作。具体做法是把一部分计算密集的层分配给iGPU，把内存密集的层留给CPU，两者并行。这个协同策略在WorkBuddy里是可以配置的，后面实操章节会讲怎么调。

2.3 一张表判断你的设备属于哪一档

我把常见设备配置和对应的35B模型运行体验整理成下面这张表，你可以直接对号入座：

这张表里的“token/s”是生成速度，不是处理速度。处理速度（prompt processing）通常快得多，因为可以并行计算。实际体验中，生成速度低于3 token/s就会明显感觉卡顿，5 token/s以上就比较顺畅了。

注意：如果你用的是笔记本，还要考虑散热和功耗墙。长时间推理会让CPU和GPU持续高负载，散热不好的机器会降频，实际速度可能比台式机低30%-50%。

3. WorkBuddy本地部署35B模型的完整实操链路

3.1 安装WorkBuddy与推理后端的选择逻辑

WorkBuddy本身是一个工作台界面，它需要搭配一个推理后端才能真正跑模型。目前主流的本地推理后端有几种，各自适合不同场景：

• llama.cpp / GGUF路线：最通用，CPU推理效率高，支持各种量化格式，对Intel平台友好。缺点是GPU加速需要额外编译配置。
• OpenVINO路线：Intel官方推理运行时，对Intel CPU和集成显卡优化最好，支持模型转换和量化。缺点是模型格式需要转换，生态相对封闭。
• Ollama路线：封装程度最高，一条命令拉模型跑起来，但可调参数少，适合快速验证。
• vLLM路线：GPU推理性能最强，但主要面向NVIDIA显卡，对Intel平台支持有限。

在WorkBuddy里，我建议优先选llama.cpp后端配合GGUF量化模型，原因是：第一，GGUF格式的35B模型资源最多，下载方便；第二，llama.cpp对CPU推理的优化非常成熟，Intel平台能吃到AVX-512指令集的红利；第三，WorkBuddy对llama.cpp的集成最完善，参数暴露得最全。

安装流程大致是这样：先从WorkBuddy官网下载对应系统的安装包（Windows、Linux、macOS都有），安装完成后首次启动会引导你配置推理后端。如果你机器上已经装了Ollama，WorkBuddy可以自动检测并接入；如果没有，它会提示你下载llama.cpp的预编译版本。整个过程不需要你手动编译，这对不熟悉C++工具链的人来说省了很多事。

提示：WorkBuddy的系统缓存目录默认在C盘用户目录下，模型文件动辄几十GB，建议在设置里把缓存目录改到空间充足的盘符。这个选项在“设置-存储-模型缓存路径”里，改完之后重启生效。

3.2 模型文件的获取、校验与放置

35B模型的GGUF文件在各大模型社区都能找到，下载时注意几个关键点：

第一，认准量化版本。文件名里通常带Q4_K_M、Q5_K_M这样的标记。Q4_K_M是质量和体积平衡最好的选择，Q5_K_M质量略好但体积大20%左右，Q3_K_M体积小但质量下降明显。我的建议是：内存够就上Q5_K_M，内存紧张就Q4_K_M，尽量不要低于Q4。

第二，校验文件完整性。大文件下载过程中断导致文件损坏是常见问题。下载完成后用SHA256校验和比对一下，或者至少在WorkBuddy里加载一次看是否报错。我遇到过好几次下载了99%就断掉的情况，文件大小看起来对，但加载时报“invalid magic number”，重新下载才解决。

第三，放置路径。WorkBuddy默认会扫描几个固定目录，你也可以手动指定模型文件夹。建议把模型放在SSD上，不要放机械硬盘——加载速度差好几倍，而且推理时如果触发内存交换，机械硬盘会让速度直接崩掉。

模型加载进WorkBuddy的流程是：打开“模型管理”面板，点击“添加本地模型”，选择GGUF文件，WorkBuddy会自动读取模型的元信息（参数量、量化类型、上下文长度），然后你给它起个名字、设置默认参数，就可以在对话界面里选择了。

3.3 关键推理参数的设置与背后原理

模型加载起来只是第一步，参数设置才是决定体验好坏的关键。WorkBuddy暴露了十几个推理参数，我挑最重要的几个讲清楚它们的作用和推荐值：

上下文长度（n_ctx）：这个参数决定模型能“记住”多少内容。35B模型通常支持32K甚至更长的上下文，但开得越大，KV Cache占用越多，内存压力越大。在32GB内存的机器上，我建议开到8192；64GB内存可以开到16384。超过这个值，内存交换会让速度断崖式下跌。

批处理大小（n_batch）：处理prompt时一次并行计算的token数。这个值越大，prompt处理越快，但内存占用也越高。默认512通常够用，如果内存充裕可以调到1024或2048。注意这个参数不影响生成速度，只影响处理速度。

GPU层卸载数（n_gpu_layers）：如果你有独立显卡，这个参数决定把多少层模型放到GPU上跑。设为0就是纯CPU推理，设为-1就是全部放GPU（显存不够会报错）。对于35B Q4模型，12GB显存大约能放下20-25层，剩下的留给CPU。WorkBuddy里可以实时调整这个值并观察速度变化，找到最佳平衡点。

线程数（n_threads）：CPU推理时使用的线程数。一般设为物理核心数，不要设成超线程数，因为超线程对矩阵运算帮助有限，反而可能增加调度开销。比如8核16线程的CPU，设8就行。

温度（temperature）：控制输出随机性。做事实性问答和代码生成时设0.1-0.3，做创意写作时设0.7-0.9。这个参数在WorkBuddy的对话界面就能调，不用改配置文件。

下面是一组我在Intel平台上实测下来比较稳的参数组合，供参考：

{ "n_ctx": 8192, "n_batch": 1024, "n_gpu_layers": 20, "n_threads": 8, "temperature": 0.3, "top_p": 0.9, "repeat_penalty": 1.1 }

这套参数在32GB内存 + 12GB显存的机器上，35B Q4_K_M模型能跑到18-22 token/s的生成速度，prompt处理速度在200 token/s左右，日常使用完全够用。

3.4 首次加载失败的常见原因排查

第一次加载35B模型失败的概率不低，我把遇到过的情况和排查思路列出来：

症状一：加载到一半卡住不动。大概率是内存不足，系统在疯狂做磁盘交换。打开任务管理器看内存占用，如果接近100%且磁盘活动率很高，就是这个问题。解决办法是换更小的量化版本，或者关掉其他占内存的程序。

症状二：报“invalid model file”。文件损坏或者下载不完整。重新下载并校验哈希值。

症状三：加载成功但生成速度极慢（低于1 token/s）。检查n_threads是否设成了超线程数，检查是否误开了GPU卸载但显存不足导致频繁回退，检查电源模式是否设成了“节能”。

症状四：生成内容乱码或重复。量化版本质量太差（比如Q2、Q3），或者repeat_penalty设得太低。换Q4以上版本，把repeat_penalty调到1.1-1.2。

症状五：WorkBuddy界面卡死但后台还在跑。这是界面渲染和推理线程抢资源，把WorkBuddy的界面刷新率调低，或者在设置里开启“推理时最小化界面”。

4. Intel算力引擎在35B推理中的实际表现与调优

4.1 OpenVINO如何让CPU和集成显卡协同工作

Intel的OpenVINO推理运行时有一个很实用的特性：它可以把一个模型的计算图拆分成多个子图，分别调度到CPU、集成显卡、独立显卡上执行。对于35B这种大模型，典型的拆分策略是：把注意力机制中的矩阵乘法放到集成显卡上（计算密度高），把前馈网络中的大矩阵乘法留给CPU（内存带宽需求高），两者通过共享内存交换中间结果。

这个协同策略的效果取决于模型结构和硬件配置。在纯CPU模式下，35B Q4模型在8核Intel处理器上大约能跑4-6 token/s；开启集成显卡协同后，能提升到6-9 token/s，提升幅度在50%左右。这个提升不算惊天动地，但确实能感受到差别。

要在WorkBuddy里启用这个协同，需要在推理后端设置里选择“OpenVINO”而不是“llama.cpp”，然后模型需要转换成OpenVINO的IR格式。WorkBuddy内置了转换工具，在模型管理里选“转换为OpenVINO格式”就行，转换过程大约需要10-20分钟，取决于模型大小和CPU性能。

注意：OpenVINO路线对模型格式有要求，不是所有GGUF模型都能直接转换。建议先用llama.cpp路线跑通，确认模型没问题之后，再尝试转OpenVINO做性能优化。

4.2 实测数据：不同配置下的token生成速度对比

我在几台不同配置的机器上跑了同一组测试，用的是35B Q4_K_M模型，prompt长度512，生成长度256，取三次平均。结果如下：

从这组数据能看出几个规律：第一，内存从DDR4升级到DDR5带来的提升很明显，因为带宽上去了；第二，集成显卡协同能带来50%左右的提升，但前提是内存带宽不能太拉胯；第三，独立显卡的加入是质变，即使只卸载一部分层，速度也能翻倍以上；第四，OpenVINO在全加速模式下比llama.cpp略快，但差距没有想象中那么大。

4.3 散热与功耗墙对持续推理的影响

这一点在笔记本上特别明显。我拿一台轻薄本做测试，连续推理10分钟后，CPU温度从65度升到95度，频率从4.2GHz降到2.8GHz，生成速度从6 token/s掉到3.5 token/s。这就是功耗墙和温度墙在起作用。

缓解办法有几个：一是把电源模式设为“最佳性能”，让风扇策略更激进；二是用散热底座或者外接散热器；三是在WorkBuddy里限制推理线程数，比如8核只开6个线程，降低发热；四是把长任务拆成短任务，中间留冷却时间。

台式机在这方面优势明显，散热空间大，可以上更好的风冷或水冷，持续推理速度基本不会掉。如果你打算把本地大模型当作日常工具用，台式机或者工作站是更靠谱的选择。

5. 端云混合的任务分工：什么放本地，什么放云端

5.1 按数据敏感度划分任务边界

端云混合的核心逻辑不是“本地跑不动就上云”，而是按数据敏感度和任务性质来分工。我自己的分工原则是这样的：

必须本地处理的任务：涉及内部文档、客户信息、未公开代码、个人隐私数据的摘要、分类、抽取、改写。这些数据一旦上传到云端，就脱离了你的控制范围，哪怕服务商承诺不留存，风险依然存在。

可以上云的任务：公开信息的查询、通用知识的问答、不涉及敏感数据的代码生成、创意写作的头脑风暴。这些任务用云端大模型（比如更大参数量的模型）效果更好，速度也更快。

混合处理的任务：长文档分析。做法是先在本地用35B模型做初步筛选和摘要，把敏感信息脱敏后，再把摘要送到云端做深度分析。这样既保护了原始数据，又利用了云端更强的推理能力。

WorkBuddy支持配置多个模型端点，你可以在设置里同时接入本地模型和云端API，然后在对话时选择用哪个。更高级的用法是配置“路由规则”：根据关键词或文件类型自动决定走本地还是云端。这个功能在WorkBuddy的“模型路由”面板里配置，支持正则匹配和文件扩展名匹配。

5.2 用WorkBuddy的工作流串联本地与云端

WorkBuddy有一个很实用的功能叫“工作流”，可以把多个步骤串起来自动执行。我举一个实际例子：批量处理合同文档。

第一步，本地35B模型读取合同PDF，抽取关键字段（甲方、乙方、金额、期限、违约责任），输出结构化JSON。这一步在本地做，因为合同内容敏感。

第二步，WorkBuddy自动把JSON里的敏感字段（公司名、金额）替换成占位符，生成脱敏版本。

第三步，脱敏版本送到云端大模型，做条款风险分析和异常检测。

第四步，云端返回的分析结果和本地抽取的原始字段合并，生成最终报告。

整个流程在WorkBuddy里配置一次，之后每次处理新合同只需要把文件拖进工作流就行。这个用法把本地模型的数据安全优势和云端模型的推理能力结合起来了，是我目前最常用的端云混合模式。

5.3 成本与延迟的权衡：什么时候值得等本地模型

本地模型的一个明显劣势是速度慢。同样一个任务，云端API可能3秒返回，本地35B模型要30秒。那什么时候值得等？

我的判断标准是：如果这个任务的数据敏感度高于时间敏感度，就等本地。比如处理一批内部会议记录，晚上跑一晚上，第二天看结果，完全没问题。但如果是要实时响应的对话场景，本地模型的速度确实会影响体验。

另一个考量是成本。云端API按token计费，大量调用时成本不低。本地模型一次部署之后，边际成本几乎为零。如果你每天要处理几十万字的内容，本地模型的成本优势会非常明显。

WorkBuddy在这方面提供了一个折中方案：异步任务队列。你可以把批量任务丢进队列，让本地模型慢慢跑，同时继续用云端API处理实时对话。队列跑完后会通知你查看结果。这个功能在“任务管理”面板里，支持优先级设置和失败重试。

6. 把35B模型用出生产力的几个实战场景

6.1 本地知识库问答的搭建要点

WorkBuddy内置了知识库功能，可以把本地文档（PDF、Word、Markdown、TXT）索引成向量库，然后让模型基于这些文档回答问题。35B模型在这个场景下的表现比小模型好很多，因为它能更好地理解长文档的上下文和隐含逻辑。

搭建知识库有几个关键点：第一，文档切分粒度要合适，一般按段落切，每段500-1000字，太短会丢失上下文，太长会稀释相关性；第二，嵌入模型建议用专门的中文嵌入模型，不要用生成模型兼任，效果差很多；第三，检索时返回的文档块数量（top_k）设3-5比较合适，太多会超出上下文窗口，太少可能漏掉关键信息。

我实测下来，35B模型配合知识库做内部文档问答，准确率比7B模型高出一大截，尤其是在需要跨文档推理的问题上。比如“根据这三份合同，哪一份的付款周期最长”，小模型经常搞混，35B模型基本能答对。

6.2 代码补全与审查的本地化方案

对于涉及未公开代码库的场景，本地模型是唯一选择。35B模型在代码补全上的表现可圈可点，尤其是Python、JavaScript、Go这些主流语言。在WorkBuddy里可以配置代码专用的系统提示词，让模型输出更符合工程规范。

代码审查是我用得最多的功能。把一段代码贴进去，让模型找潜在bug、性能问题、安全隐患。35B模型能发现大部分常见问题，比如空指针、资源泄漏、SQL注入风险。当然它也会误报，需要人工复核，但作为第一道筛子能省不少时间。

提示：代码审查时把temperature设到0.1，让输出更确定。另外可以在系统提示词里加上你团队的编码规范，模型会按规范来检查。

6.3 长文档摘要与结构化抽取的提示词设计

35B模型处理长文档的能力比小模型强很多，但提示词设计依然关键。我的经验是：不要让它一次性做太多事。比如“总结这份文档并抽取所有日期和金额”这种复合指令，模型容易顾此失彼。更好的做法是分两步：先做摘要，再做抽取，每步给明确的输出格式要求。

结构化抽取时，用JSON Schema约束输出格式效果最好。在WorkBuddy里可以在系统提示词里写清楚字段名、类型、是否必填，模型会按格式输出。如果某个字段抽不到，让它填null而不是瞎编。

对于超长文档（超过上下文窗口），WorkBuddy支持分块处理再合并。做法是把文档切成多个块，每块单独摘要，然后把所有摘要合并再做一次总结。这个流程可以在工作流里自动化。

7. 我踩过的坑和最后分享的几个技巧

第一个坑是模型文件放机械硬盘。我一开始把35B模型放在一块4TB的机械硬盘上，加载花了将近10分钟，推理时偶尔触发内存交换，速度直接掉到1 token/s以下。后来换到NVMe SSD，加载时间降到1分钟以内，推理也稳定了。这个教训很直接：大模型对存储I/O的要求比想象中高。

第二个坑是上下文开太大导致OOM。有一次我把n_ctx设到32768，想着反正内存有64GB，结果加载到一半就崩了。后来算了一下，32K上下文的KV Cache在35B模型上要占8GB以上，加上权重和其他开销，64GB内存确实不够。现在我都控制在8K-16K，够用且稳定。

第三个坑是忽略电源模式。笔记本默认的“平衡”模式会限制CPU持续性能，推理速度比“最佳性能”模式低30%左右。这个设置藏在系统电源选项里，很容易忽略。

最后分享几个提升体验的小技巧：在WorkBuddy里给常用任务设置快捷键，减少重复操作；把系统提示词模板保存成预设，一键切换；定期清理模型缓存目录里的临时文件，避免磁盘占满；如果主要用中文，选中文能力强的模型版本，英文模型的中文表现会打折扣。

端云混合这件事，说到底是在数据安全、响应速度、使用成本三者之间找平衡。没有一刀切的最优解，只有适合你当前场景的合理分工。我的做法是先把本地35B模型跑通，把它当成一个可靠的“内部助手”，再把云端模型当成“外部专家”，两者各司其职。这套组合用下来，既守住了数据边界，又没有牺牲太多效率。