
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上推的是“CPUGPUNPU”的异构算力组合。对于没有独立显卡的机器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和推理框架的运行时开销。我整理了一个对照表你可以直接对号入座硬件配置权重存放推理速度预期是否推荐24GB显存独显全量加载到显存25-40 token/s强烈推荐16GB显存 32GB内存部分卸载到内存10-18 token/s推荐12GB显存 32GB内存较多层卸载到内存6-12 token/s可用纯CPU 32GB内存全部在内存2-5 token/s应急可用纯CPU 16GB内存放不下无法运行不推荐这里的关键是显存和内存的配合。WorkBuddy支持分层加载把一部分Transformer层放在显存、一部分放在内存推理时动态调度。这个策略的代价是速度下降但好处是让16GB显存的机器也能跑起来35B。注意如果你用的是笔记本还要看散热。35B模型持续推理时GPU和CPU都是满载散热不好的机器会降频速度可能掉一半。建议在通风良好的环境下使用或者限制并发请求数。2.2 Intel平台的特殊优势怎么用起来如果你用的是Intel平台有几个点可以专门优化。第一确认驱动版本。Intel Arc显卡需要较新的驱动才能支持INT4推理加速。我遇到过有人用旧驱动跑WorkBuddy模型加载正常但推理速度只有预期的一半更新驱动后恢复正常。建议去Intel官网下载最新的显卡驱动和oneAPI运行时。第二开启NPU加速。部分Intel酷睿Ultra处理器带NPUWorkBuddy可以调用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级别的模型有好几个选择。我列一下常见的几个和它们的适用场景模型量化格式权重体积特点适合场景Qwen2.5-32B-InstructQ4_K_M约19GB中文强指令跟随好中文文档处理、客服Llama-3.3-70BQ4_K_M约40GB英文强推理深英文代码、分析DeepSeek-R1-Distill-32BQ4_K_M约19GB推理链强数学、逻辑题Yi-34BQ4_K_M约20GB长上下文长文档理解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 问答SkillSkill之间可以传递数据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或Q335B模型在低比特量化下质量下降很明显。缩短上下文长度如果你不需要处理长文档把n_ctx从8192降到4096KV 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%92%指令跟随88%95%中文表达90%93%代码生成82%90%响应速度15 token/s50 token/s数据隐私完全本地需上传边际成本接近零按量计费结论是本地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工作台。