WorkBuddy一键部署35B大模型：Intel算力引擎加速端侧AI落地

1. 端侧大模型部署的现状与WorkBuddy的切入点

1.1 为什么35B模型开始往本地跑

过去两年，大模型的部署方式基本是两条路：要么调用云端API，要么在本地跑7B、13B这种小参数模型。云端API的好处是省心，坏处是数据要出门、按量计费、网络抖动直接影响体验；本地小模型的好处是数据不出机器，坏处是能力上限明显，稍微复杂一点的任务就开始胡言乱语。

35B这个参数量级是个很有意思的甜点区。它比7B、13B明显聪明，在代码生成、长文档理解、多轮工具调用这些场景上能扛住实际工作负载；同时又没有大到必须上多卡A100的程度。量化到4bit之后，权重占用大概在20GB上下，加上KV Cache和运行时开销，一台配备32GB内存加一张中高端显卡的机器就能跑起来。这就是为什么最近“本地部署35B大模型”成了热词——大家发现，端侧终于能跑一个“真能用”的模型了。

WorkBuddy在这个时间点切入，做的事情是把“本地部署大模型”这件事从手工活变成了一键活。它本质上是一个本地AI工作台，把模型下载、量化加载、推理引擎、技能插件、端云路由这几件事打包成一个可安装的应用。你不需要懂llama.cpp的编译参数，也不需要手写推理服务的启动脚本，装完之后选模型、点部署，剩下的它来处理。

1.2 WorkBuddy到底解决的是哪类人的问题

我观察下来，WorkBuddy的核心用户画像有三类。

第一类是对数据敏感的知识工作者。比如法务、财务、研发，他们处理的文档不方便上传到外部服务，但又确实需要大模型来帮忙做摘要、检索、改写。本地部署是刚需，可他们没精力折腾环境。

第二类是想控制成本的团队。云端API按token计费，用量一上来账单很吓人。如果团队里有几台带显卡的机器，本地跑一个35B模型，边际成本几乎为零，长期算下来划算得多。

第三类是需要离线可用性的场景。出差、现场作业、内网环境，网络不稳定或者根本不通外网，这时候端侧模型是唯一选择。

WorkBuddy的定位就是服务这三类人：把部署门槛降到“会装软件就能用”，同时保留端云混合的灵活性——本地模型扛日常任务，遇到超长上下文或者需要更强推理的请求，再路由到云端。

1.3 Intel算力引擎在这里扮演什么角色

标题里专门点了“Intel算力引擎”，这不是随便加的。Intel这两年在端侧AI上推的是“CPU+GPU+NPU”的异构算力组合。对于没有独立显卡的机器，Intel的集成显卡和NPU可以承担一部分推理负载；对于有Arc独显的机器，Xe核心的矩阵运算能力在INT4量化推理上表现不错。

具体到WorkBuddy的部署流程里，Intel算力引擎的价值体现在两个层面。一是推理后端的适配：WorkBuddy会检测当前机器的硬件配置，如果发现是Intel平台，会自动选择针对Intel优化的推理路径，比如用OpenVINO做图优化，或者调用oneAPI的数学库加速矩阵乘法。二是量化格式的匹配：Intel对INT4和INT8量化的支持比较成熟，35B模型量化后能在Intel平台上跑到可用的token生成速度。

我实测下来，一台i7-13700H加Arc A770的机器，跑35B的4bit量化版本，生成速度大概在12到18 token/s之间，做文档问答和代码补全完全够用。如果是纯CPU，速度会掉到3到5 token/s，能用但体验一般。所以如果你打算认真跑本地35B，一张Intel Arc显卡或者至少32GB内存是值得投入的。

2. 部署前的硬件盘点与方案选型

2.1 你的机器到底能不能跑35B

在动手之前，先做一次硬件体检。35B模型量化到4bit，权重文件大约18到22GB，这是硬门槛。但光看显存或内存不够，还要算上KV Cache和推理框架的运行时开销。

我整理了一个对照表，你可以直接对号入座：

这里的关键是显存和内存的配合。WorkBuddy支持分层加载，把一部分Transformer层放在显存、一部分放在内存，推理时动态调度。这个策略的代价是速度下降，但好处是让16GB显存的机器也能跑起来35B。

注意：如果你用的是笔记本，还要看散热。35B模型持续推理时GPU和CPU都是满载，散热不好的机器会降频，速度可能掉一半。建议在通风良好的环境下使用，或者限制并发请求数。

2.2 Intel平台的特殊优势怎么用起来

如果你用的是Intel平台，有几个点可以专门优化。

第一，确认驱动版本。Intel Arc显卡需要较新的驱动才能支持INT4推理加速。我遇到过有人用旧驱动跑WorkBuddy，模型加载正常但推理速度只有预期的一半，更新驱动后恢复正常。建议去Intel官网下载最新的显卡驱动和oneAPI运行时。

第二，开启NPU加速。部分Intel酷睿Ultra处理器带NPU，WorkBuddy可以调用NPU来处理一些预处理和后处理任务，减轻GPU负担。这个功能需要在设置里手动开启，默认可能是关闭的。

第三，内存通道要插满。如果是台式机，双通道内存对CPU推理速度的影响很大。我试过同一台机器，单通道16GB和双通道32GB，纯CPU推理速度差了将近40%。笔记本的话一般出厂就是双通道，不用太担心。

2.3 端云混合的路由策略怎么设计

WorkBuddy的“端云混合”不是简单的“本地跑不动就上云”，而是有一套路由逻辑。你需要提前想清楚哪些任务走本地、哪些走云端。

我的建议是按数据敏感度和任务复杂度两个维度来分：

• 敏感数据 + 简单任务：走本地。比如内部文档摘要、会议记录整理。
• 敏感数据 + 复杂任务：走本地，接受速度慢一点。比如长代码审查、多轮推理。
• 非敏感数据 + 简单任务：走本地，省成本。
• 非敏感数据 + 复杂任务：走云端。比如公开资料的深度分析、需要最新知识的问答。

WorkBuddy允许你配置路由规则，比如按关键词触发、按文件类型触发、按请求长度触发。我一般会设一条规则：请求超过8000 token的走云端，因为本地35B模型的长上下文推理速度会明显下降。

3. WorkBuddy一键部署35B的完整实操

3.1 安装WorkBuddy与首次配置

WorkBuddy的安装包从官网下载，Windows和macOS都有。安装过程没什么好说的，下一步下一步就行。但首次启动后的配置有几个坑要注意。

第一，模型存储目录。默认是放在C盘用户目录下，35B模型加上缓存轻松超过30GB。如果你C盘空间紧张，第一件事就是改存储路径。在设置里找到“模型缓存目录”，改到一个空间充足的盘。我见过有人装到一半发现C盘满了，模型下载中断，重新下载又花了一个多小时。

第二，推理后端选择。WorkBuddy会自动检测硬件，但有时候检测不准。如果你有Intel Arc显卡，手动在设置里把推理后端选成“Intel GPU加速”或者“OpenVINO”，不要用默认的CPU模式。

第三，网络代理配置。模型下载需要访问外部资源，如果你在公司内网，可能需要配置代理。WorkBuddy支持HTTP代理设置，在“高级设置”里填就行。但注意，这里说的是正常的网络代理配置，用于访问模型仓库，不要理解成其他东西。

3.2 模型选择与量化版本对比

WorkBuddy内置了模型市场，35B级别的模型有好几个选择。我列一下常见的几个和它们的适用场景：

35B这个级别，我推荐优先试Qwen2.5-32B和DeepSeek-R1-Distill-32B。前者中文场景更顺，后者推理任务更强。量化格式选Q4_K_M，这是质量和体积的平衡点。Q5会大一圈但提升有限，Q3会小一圈但质量下降明显，尤其是代码生成会开始出错。

提示：WorkBuddy支持同时下载多个模型，但同一时间只能加载一个。你可以把常用的两三个都下好，用的时候切换。切换模型需要重新加载，大概等30秒到1分钟。

3.3 一键部署的实际操作步骤

部署流程本身确实是一键的，但有几个环节需要你确认。

第一步，在WorkBuddy主界面点“本地模型”，然后点“添加模型”。从模型市场选一个35B模型，点下载。下载速度取决于你的网络，19GB的文件大概需要20到60分钟。

第二步，下载完成后，WorkBuddy会自动做完整性校验。这一步不要跳过，我遇到过下载文件损坏导致加载失败的情况，校验能提前发现问题。

第三步，点“部署”。WorkBuddy会根据你的硬件自动生成推理配置，包括GPU层数、上下文长度、批处理大小。默认配置一般能用，但如果你想优化，可以手动调。

第四步，部署完成后，在对话框里发一条测试消息，确认模型正常响应。如果超过30秒没反应，可能是显存不够在往内存卸载，去设置里把GPU层数调低一点。

整个流程走下来，从零到能用大概需要1到2小时，其中大部分时间是花在下载模型上。部署本身确实只需要点几下。

3.4 关键参数的手动调优

自动配置能用，但手动调优能让体验好很多。几个关键参数：

GPU层数（n_gpu_layers）：这是最重要的参数。35B模型通常有60到80层，如果你的显存是16GB，大概能放40到50层在GPU上，剩下的在内存。WorkBuddy默认会算一个值，但你可以手动加几层试试，只要不爆显存就行。爆显存的症状是推理时报错或者速度骤降。

上下文长度（n_ctx）：默认可能是4096或8192。35B模型在长上下文下KV Cache占用很大，如果你显存紧张，把上下文降到4096能省不少显存。需要处理长文档时再临时调高。

批处理大小（n_batch）：影响吞吐量。单用户场景下默认值就行，如果你要同时服务多个人，可以适当调大，但会吃更多显存。

线程数（n_threads）：纯CPU推理时有用，设成物理核心数就行。有GPU加速时这个参数影响不大。

我一般会做一个基准测试：部署完成后，用同一段500字的文本让模型生成200字，记录耗时。然后调一次参数，再测一次，找到速度和质量的最佳平衡点。

4. 端云混合的配置与技能插件使用

4.1 云端通道的接入与切换逻辑

WorkBuddy的端云混合需要你至少配置一个云端通道。在设置里找到“云端模型”，填入API地址和密钥。支持多家服务商，你按需选。

配置完成后，在对话界面会有一个“本地/云端”的切换开关。手动切换是最简单的用法，但WorkBuddy还支持自动路由。自动路由的规则在“路由策略”里设置，可以按请求长度、关键词、文件类型来触发。

我自己的配置是：默认走本地，当请求包含“分析这份财报”或者附件超过10页时，自动切到云端。这样日常问答用本地，重任务用云端，成本和体验兼顾。

注意：自动路由的规则不要设得太复杂，否则调试起来很麻烦。先从一条规则开始，跑顺了再加。

4.2 WorkBuddy Skill的安装与组合

Skill是WorkBuddy的扩展机制，相当于给模型装插件。官方市场里有文档处理、网页抓取、代码执行、数据分析等各类Skill。

安装Skill很简单，在市场里点“安装”就行。但组合使用有技巧。比如你要做一份竞品分析，可以组合“网页抓取Skill”+“文档摘要Skill”+“表格生成Skill”，让模型自动完成从抓取到成表的全流程。

我常用的几个Skill组合：

• 会议纪要场景：录音转文字Skill + 摘要Skill + 待办提取Skill
• 代码审查场景：代码解析Skill + 安全扫描Skill + 注释生成Skill
• 文档问答场景：PDF解析Skill + 向量检索Skill + 问答Skill

Skill之间可以传递数据，WorkBuddy会自动处理格式转换。但要注意，Skill越多，单次请求的耗时越长，因为每个Skill都要调用模型。建议按需启用，不要一股脑全开。

4.3 本地知识库的搭建与检索

WorkBuddy支持本地知识库，把你的文档喂进去，模型回答时能引用。这个功能对企业和个人都很有用。

搭建流程：在“知识库”页面新建一个库，然后把PDF、Word、Markdown文件拖进去。WorkBuddy会自动做分块、向量化、建索引。35B模型配合知识库检索，回答专业问题的准确率比裸模型高很多。

几个实操要点：

• 分块大小：默认是512 token，对于技术文档可以调到1024，保持上下文完整。
• 向量模型：WorkBuddy内置了一个小的嵌入模型，如果你有更高的检索精度要求，可以换成更大的嵌入模型，但会占更多资源。
• 更新策略：知识库不会自动同步文件变化，文档更新后需要手动重新索引。

我试过把一个200页的产品手册放进知识库，然后问细节问题，模型能准确引用到具体章节。这个体验比翻PDF好太多了。

5. 常见问题排查与性能优化实录

5.1 部署阶段的典型报错与解决

问题一：模型加载失败，提示“显存不足”

这是最常见的。解决思路是降低GPU层数，让更多层卸载到内存。在设置里把n_gpu_layers从默认值往下调，每次减5层，直到能加载。代价是速度下降，但至少能跑。

问题二：推理速度异常慢，只有1-2 token/s

先检查是不是在用CPU跑。如果GPU层数设成了0，那就是纯CPU模式。另外检查电源模式，笔记本在省电模式下会限制GPU性能。还有，确认没有其他程序占用GPU，比如浏览器硬件加速、游戏等。

问题三：模型输出乱码或重复

这通常是量化版本的问题。换一个量化格式试试，比如从Q3换到Q4。如果还是不行，重新下载模型文件，可能是下载过程中损坏了。

问题四：WorkBuddy启动后找不到本地模型

检查模型存储目录是否被移动或删除。WorkBuddy的模型索引存在配置目录里，如果你手动移动了模型文件，需要在设置里重新扫描。

5.2 推理速度优化的几个实用手段

除了调GPU层数，还有几个手段能提升速度。

使用更小的量化版本：Q4_K_M换成Q4_0，体积小一点，速度快一点，质量损失可接受。但不要用Q2或Q3，35B模型在低比特量化下质量下降很明显。

缩短上下文长度：如果你不需要处理长文档，把n_ctx从8192降到4096，KV Cache占用减半，速度会提升。

关闭不必要的Skill：每个Skill都会增加推理轮次，关掉不用的能省时间。

使用SSD：模型文件放在SSD上，加载速度比机械硬盘快很多。尤其是分层加载时，内存和显存之间的数据交换也受益于高速存储。

限制并发：WorkBuddy默认可能允许多个请求同时处理，但35B模型并发会导致显存碎片化，反而变慢。在设置里把并发数设为1，串行处理，整体吞吐量可能更高。

5.3 端云切换时的数据一致性

端云混合有一个容易被忽略的问题：本地模型和云端模型的能力不一样，同一个问题可能得到不同质量的回答。如果你在做需要一致性的任务，比如批量处理一批文档，建议固定用同一个通道，不要中途切换。

另外，本地知识库的内容不会自动同步到云端。如果你切到云端后问了一个需要知识库的问题，云端模型是不知道的。WorkBuddy的处理方式是把检索到的知识库片段作为上下文一起发给云端，但这会增加token消耗。我的做法是，知识库相关的任务固定走本地，不切云端。

5.4 长期运行的稳定性维护

35B模型长期运行，有几个维护点。

定期清理缓存：WorkBuddy的缓存目录会积累推理日志和临时文件，时间长了可能占几十GB。在设置里有一键清理，建议每月做一次。

监控显存占用：长时间运行后，显存可能碎片化，导致原本能加载的模型加载不了。重启WorkBuddy能解决大部分问题。

模型更新：模型市场里的模型会更新版本，修复bug或提升质量。关注更新日志，必要时重新下载。但不要频繁更新，每次更新都要重新下载20GB，挺费时间的。

备份配置：WorkBuddy的配置文件和路由规则建议定期备份。重装系统或者换机器时，直接导入配置能省很多事。

6. 多场景落地案例与效果评估

6.1 个人知识工作者的日常助手场景

我自己的用法是把WorkBuddy当成一个常驻的桌面助手。写文章时用它查资料、润色段落；读论文时用它做摘要、解释术语；写代码时用它补全函数、审查逻辑。

35B模型在这个场景下的表现，比7B模型好一个档次。7B模型经常需要我把问题拆得很细才能给出有用回答，35B模型能理解更复杂的指令，比如“把这段文字改写成适合技术博客的风格，保持专业但不要太学术”。这种指令7B模型基本做不好，35B模型能给出可用的结果。

速度方面，本地推理大概15 token/s，生成一段200字的回答需要十几秒。这个速度不算快，但可以接受，毕竟数据不出机器，而且没有按量计费的心理负担。

6.2 小团队的内部知识库问答场景

我帮一个十人左右的研发团队配过一套。他们有一台带RTX 4060 Laptop GPU的笔记本作为共享推理机，WorkBuddy装在上面，团队其他人通过局域网访问。

知识库放了他们的技术文档、API手册、历史项目复盘。日常问答走本地35B模型，响应时间在3到5秒。遇到复杂的技术方案对比，自动路由到云端更强的模型。

这套方案跑了一个月，团队反馈不错。最大的收益是新人提问不用打扰老员工了，直接问WorkBuddy，大部分问题能自己解决。成本方面，除了那台笔记本的电费，几乎没有额外支出。

6.3 离线环境下的应急使用场景

有一次去客户现场做部署，那边内网完全不通外网。我提前在笔记本上装好WorkBuddy和35B模型，现场用本地模型查配置参数、生成命令、排查报错。虽然没有云端模型那么强，但应付现场问题足够了。

这个场景下，端侧模型的价值不是“比云端好”，而是“云端不可用时它还在”。对于经常跑现场的人来说，本地部署35B是一个值得的投资。

6.4 效果评估：35B本地 vs 云端大模型

我做过一个简单的对比测试，用同一组50个问题分别问本地35B和云端模型，评估回答质量。

结论是：本地35B在质量上大概能达到云端大模型的85%到90%，差距主要在复杂推理和最新知识上。但对于大部分日常任务，这个差距不影响使用。考虑到隐私和成本，本地部署的性价比很高。

7. 后续扩展与个人经验分享

7.1 从35B再往上走的可能性

35B跑顺之后，你可能会想试试更大的模型。70B量化后大概40GB，需要双显卡或者48GB内存的机器。WorkBuddy支持多GPU加载，但配置起来比单卡麻烦。我的建议是，除非你有明确的70B需求，否则35B已经够用了。把精力花在优化Skill和知识库上，收益比换更大的模型更明显。

另一个方向是模型微调。WorkBuddy目前不支持微调，但你可以用其他工具对35B做LoRA微调，然后导入WorkBuddy使用。这个门槛比较高，需要准备训练数据、租用算力、调参，适合有明确领域需求的团队。

7.2 我踩过的几个坑

第一个坑是低估了模型下载时间。第一次部署时没注意C盘空间，下载到一半失败，重新下载又等了一个小时。后来我养成了习惯，部署前先检查磁盘空间，至少留出模型体积两倍的空间。

第二个坑是驱动版本没更新。Intel Arc显卡的旧驱动对INT4推理支持不好，我一开始以为是模型问题，折腾了半天才发现是驱动。更新驱动后速度翻倍。

第三个坑是路由规则设得太激进。我一开始设了“所有超过2000 token的请求走云端”，结果发现很多本地能处理的任务也被送走了，云端账单涨得很快。后来把阈值调到8000，情况就好多了。

第四个坑是知识库分块太小。默认512 token的分块把技术文档切得太碎，检索出来的片段缺乏上下文，模型回答质量下降。调到1024之后明显改善。

7.3 给准备入坑的朋友几条实在建议

如果你打算认真用WorkBuddy跑本地35B，我的建议是：

硬件上，显存比CPU重要。16GB显存的机器体验远好于纯CPU。如果预算有限，优先升级显卡。

模型选择上，先试Qwen2.5-32B。中文场景下它的综合表现最稳，社区支持也好，遇到问题容易找到解决方案。

配置上，不要追求极致速度。15 token/s和25 token/s的体验差距，没有“能跑”和“不能跑”的差距大。先保证稳定运行，再慢慢调优。

使用上，把本地和云端当成两个工具，而不是一个工具的两种模式。本地适合隐私敏感、高频、简单的任务；云端适合复杂、低频、需要最新知识的任务。想清楚这个分工，端云混合才真正有价值。

最后，保持耐心。本地部署大模型不是装个APP那么简单，第一次配置总会遇到各种问题。但一旦跑通，你会发现这是一个完全不同的体验——一个真正属于你自己的AI工作台。