Intel算力引擎+WorkBuddy：35B大模型本地部署与端云混合实战

1. 端侧算力爆发前夜：为什么35B大模型开始往本地跑

过去一年我身边不少做AI应用的朋友都在干同一件事：把原本跑在云端的模型往本地搬。原因很直接，云端API按token计费，长期用下来成本压不住，而且数据出本地这件事在很多行业里根本过不了合规那一关。但本地部署大模型一直有个尴尬的地方——7B、13B的模型跑起来确实流畅，可一旦上到30B以上的参数规模，普通消费级设备就开始喘了。直到最近我拿到一台搭载Intel酷睿Ultra处理器的笔记本，配合WorkBuddy做了一次35B大模型的本地一键部署，才真正感觉到端侧算力这件事开始有实质性的变化。

这篇文章想聊的就是这套组合的实际体验和落地细节。核心关键词是Intel算力引擎、WorkBuddy、本地部署、35B大模型和端云混合。我会从方案选型的逻辑讲起，把部署过程中踩过的坑、参数怎么调、端云混合到底怎么分工这些事说清楚。适合谁看？如果你手头有一台近两年的Intel平台设备，想在不依赖云端的前提下跑一个真正能干活的大模型，或者你正在评估端云混合架构到底值不值得投入，那这篇内容应该能帮你省下不少试错时间。

先说结论性的判断：35B这个参数量级是目前端侧部署的一个甜蜜点。它比7B、13B明显聪明，在代码生成、长文档理解、多轮对话这些任务上能给出可用的结果；同时又没有大到让本地推理完全跑不动。而Intel这两年在端侧AI加速上的布局，尤其是NPU加核显加CPU的异构算力调度，让这个参数量级的模型在笔记本上跑起来成为可能。WorkBuddy在这个链条里扮演的是部署工具和运行框架的角色，把模型下载、量化、推理引擎配置这些原本需要手动折腾的环节做了一键化封装。

2. 方案整体设计与思路拆解

2.1 为什么是35B而不是7B或70B

选模型规模这件事，本质上是在效果和可运行性之间找平衡。我做过一组粗略的对比测试，在同一台Intel酷睿Ultra 7的笔记本上，用WorkBuddy分别部署7B、13B、35B和70B四个量级的模型，观察推理速度和输出质量的变化。

7B模型在端侧跑起来确实快，首token延迟基本在200毫秒以内，生成速度能到每秒30个token以上。但问题在于，当你让它处理稍微复杂一点的逻辑推理或者长上下文任务时，它经常给出似是而非的答案。13B是一个进步，但提升幅度没有想象中那么大。70B呢？质量确实上了一个台阶，但在没有独立显卡的轻薄本上，即使做了4bit量化，推理速度也会掉到每秒3到5个token，基本没法交互使用。

35B刚好卡在中间。以目前主流的35B级别模型为例，经过4bit量化后模型体积大约在18到20GB之间，对内存的要求是32GB起步，推荐64GB。推理速度在Intel核显加NPU的协同下，能稳定在每秒12到18个token，首token延迟控制在1秒以内。这个水平已经可以支撑实时对话和文档处理了。更重要的是，35B模型在代码补全、技术文档问答、多步骤推理这些场景下的表现，已经接近早期云端大模型的水准。

2.2 Intel算力引擎在端侧到底做了什么

很多人对Intel在AI算力上的印象还停留在“CPU厂商顺便做做AI”。但实际拆开来看，Intel这两年在端侧AI的布局是成体系的。以酷睿Ultra系列为例，一颗芯片里集成了CPU、GPU和NPU三个计算单元，各自有明确的分工。

CPU负责调度和轻量计算，GPU（也就是核显）承担大部分的矩阵运算，NPU则专门处理低功耗的持续推理任务。WorkBuddy在部署35B模型时，会自动识别硬件配置，把模型的不同层分配到最合适的计算单元上。比如注意力机制中的矩阵乘法交给GPU，一些归一化和激活函数交给NPU，CPU负责整体的流程控制。

这种异构调度的好处是显而易见的。我实测下来，纯CPU推理35B模型的速度大约是每秒4到6个token，纯GPU能到每秒10到12个token，而三者协同之后能稳定在每秒15个token以上。功耗方面，协同模式比纯GPU模式低了大约20%，这对笔记本的续航来说很关键。

2.3 WorkBuddy的一键部署到底简化了什么

如果你手动部署过本地大模型，应该知道这个过程有多琐碎。先要装Python环境，然后配CUDA或者OpenVINO，接着下载模型权重，做量化转换，配置推理引擎，最后还要写一个服务端脚本来提供API接口。每一步都可能出问题，光是版本兼容性就能折腾一整天。

WorkBuddy把这些步骤打包成了一个流程。你只需要在界面里选择模型规模、量化精度和推理后端，剩下的下载、转换、配置、启动全部自动完成。我粗略算了一下，手动部署一个35B模型从零到能用，熟练工也要两到三个小时；用WorkBuddy的话，主要时间花在模型下载上，实际配置过程不到十分钟。

注意：一键部署不等于零配置。模型下载对网络带宽有要求，35B的4bit量化版本大约20GB，建议在千兆网络环境下操作。另外首次启动时WorkBuddy会做一次硬件能力检测和推理引擎编译，这个过程可能需要五到十分钟，属于正常现象。

2.4 端云混合的架构逻辑

纯本地部署有一个绕不开的问题：本地算力再强，也扛不住极端复杂的任务。比如你让35B模型去处理一个需要检索大量外部知识的任务，或者做超长文档的深度分析，本地推理的时间和内存占用都会急剧上升。这时候端云混合就是更务实的选择。

端云混合的核心思路是任务分级。简单的、涉及隐私的、对延迟敏感的任务放在本地跑；复杂的、需要大规模知识检索的、对成本不敏感的任务交给云端。WorkBuddy在这套架构里提供了一个路由层，你可以设置规则来决定哪些请求走本地、哪些走云端。

我自己的配置是这样的：日常对话、代码补全、本地文档问答全部走本地35B模型；需要联网搜索或者处理超过5万字的文档时，自动切换到云端API。这样既保证了日常使用的隐私和响应速度，又在需要的时候能借助云端算力。成本方面，相比全部走云端，混合模式能省下大约70%的API调用费用。

3. 核心细节解析与实操要点

3.1 硬件门槛到底在哪里

在动手之前，先确认你的设备能不能跑得动35B模型。我把实测的最低配置和推荐配置整理成了表格，你可以对照自己的设备看一下。

这里要特别说一下内存。很多人觉得32GB够了，但实际运行时，模型本身占20GB，系统和其他应用占4到6GB，推理过程中的KV Cache还会动态占用2到4GB。如果你同时开着浏览器和IDE，32GB会非常紧张，系统会频繁使用虚拟内存，导致推理速度断崖式下降。我建议至少48GB，64GB是比较舒服的状态。

3.2 模型量化的选择与取舍

35B模型不可能以FP16精度在端侧运行，量化是必须的。目前WorkBuddy支持几种主流的量化方案，我分别试过之后有一些体会。

4bit量化是端侧部署的默认选择。模型体积从70GB压缩到约20GB，推理速度提升明显，质量损失在可接受范围内。我对比过4bit量化和FP16精度在代码生成任务上的表现，简单函数生成基本一致，复杂算法实现上4bit偶尔会漏掉一些边界条件处理，但整体可用。

5bit和6bit量化是折中方案。体积分别约为25GB和30GB，质量比4bit好一些，但对内存的要求更高。如果你有64GB内存，可以试试6bit量化，在长文档理解任务上确实比4bit稳定。

8bit量化我不推荐在端侧用。体积接近40GB，推理速度下降明显，而且质量提升相比6bit并不显著。这个精度更适合有独立显卡的场景。

实操心得：WorkBuddy在量化选项里有一个“自动选择”的开关。我的建议是第一次部署时打开它，让工具根据你的硬件配置自动选一个平衡点。跑起来之后如果觉得质量不够，再手动调整到更高的量化精度。

3.3 WorkBuddy的安装与初始配置

WorkBuddy的安装过程本身不复杂，但有几个细节容易出问题。我从官网下载安装包之后，双击运行，安装程序会自动检测系统环境。这里要注意的是，如果你的系统缺少某些运行库，安装程序会提示你安装，不要跳过这一步。

安装完成后首次启动，WorkBuddy会引导你做一个硬件能力检测。这个过程会测试CPU、GPU和NPU的算力，大约需要两到三分钟。检测完成后会给出一个评分和建议的模型规模。我的设备检测下来建议部署35B模型，4bit量化，推理后端选择OpenVINO。

接下来是配置模型存储路径。默认路径在C盘的用户目录下，但35B模型加上缓存会占用大量空间，建议改到其他盘。在设置里找到“存储路径”选项，修改为你空间充足的盘符。这里有一个坑：路径中不要包含中文和特殊字符，否则模型加载时可能报错。

3.4 推理后端的选型对比

WorkBuddy支持多种推理后端，不同的后端在性能和兼容性上有明显差异。我实测了三种主流方案，数据如下。

OpenVINO是Intel自家的推理框架，对自家硬件的优化最到位，速度和内存占用都是最优的。ONNX Runtime的兼容性更好，如果你之后想把模型迁移到其他平台，用ONNX格式会更方便。DirectML是Windows的通用方案，性能一般，但胜在什么显卡都能跑。

我的建议很直接：如果你是Intel平台，无脑选OpenVINO。WorkBuddy在检测到Intel硬件时会默认选这个后端，你不需要改。

3.5 端云混合的路由规则怎么设

端云混合的配置在WorkBuddy的“模型路由”面板里。你可以设置多条规则，每条规则包含触发条件和目标模型。我把自己用的规则分享出来，你可以参考。

第一条规则：所有包含“本地文件”“隐私”“内部”关键词的请求，强制走本地模型。这条规则是为了确保敏感数据不出本地。

第二条规则：请求的上下文长度超过32000 token时，自动切换到云端模型。本地35B模型虽然支持长上下文，但超过32K之后推理速度会明显下降，交给云端更划算。

第三条规则：涉及实时信息查询的请求，走云端模型并开启联网搜索。本地模型的知识截止日期是固定的，查不了最新信息。

第四条规则：其余所有请求默认走本地模型。这样日常使用中大部分请求都在本地处理，只有少数特殊情况才调用云端。

注意：路由规则的优先级是从上到下匹配的，第一条匹配到的规则生效。所以要把最具体的规则放在前面，最通用的放在最后。

4. 实操过程与核心环节实现

4.1 从零开始的一键部署全流程

我把整个部署过程拆成了七个步骤，跟着走一遍基本不会出问题。

第一步，确认系统版本和驱动。Windows 11需要23H2以上，显卡驱动建议更新到最新版本。你可以在WorkBuddy的“环境检测”页面看到具体的版本要求，不满足的项会标红。

第二步，安装WorkBuddy。从官网下载安装包，双击运行，按照提示完成安装。安装完成后不要急着启动，先重启一次系统，确保驱动和服务都正常加载。

第三步，启动WorkBuddy并完成硬件检测。这个过程会自动运行，你只需要等待。检测完成后会显示硬件评分和建议配置。

第四步，选择模型。在模型库中找到35B级别的模型，WorkBuddy会列出多个可选版本。我选的是指令微调版本，更适合对话和任务执行。点击“部署”按钮。

第五步，配置量化精度和推理后端。按照前面说的，量化选4bit，后端选OpenVINO。如果你的内存有64GB，可以试试6bit量化。

第六步，等待模型下载和转换。这是最耗时的环节，20GB的模型在百兆网络下大约需要半小时。下载完成后WorkBuddy会自动做格式转换和推理引擎编译，这个过程大约五到十分钟。

第七步，启动推理服务。在WorkBuddy的“服务管理”页面点击启动，等待状态变为“运行中”。然后你就可以在对话界面里测试了。

4.2 首次推理的性能调优

模型跑起来之后，默认参数不一定是最优的。我建议做几项调优，能明显改善使用体验。

首先是上下文长度。WorkBuddy默认设置是4096 token，这个值偏保守。35B模型支持更长的上下文，你可以调到8192甚至16384。但要注意，上下文越长，KV Cache占用的内存越多，推理速度也会下降。我的经验是8192是一个比较好的平衡点。

其次是批处理大小。这个参数影响的是同时处理多个请求时的吞吐量。如果你主要是单人使用，保持默认的1就行。如果要做服务端部署给多人用，可以调到4或8，但内存占用会成倍增加。

然后是温度参数。默认的0.7适合创意类任务，但如果你主要用模型做代码生成或者技术问答，建议调到0.3到0.5，输出会更稳定、更准确。

最后是重复惩罚。默认值1.1有时候会导致模型在长文本生成时出现重复。如果遇到这个问题，可以调到1.15或1.2。

4.3 端云混合的实际配置记录

端云混合的配置分为两部分：本地服务的暴露和云端API的接入。

本地服务方面，WorkBuddy启动推理服务后，会在本地监听一个端口，默认是11434。你可以在设置里修改端口号，也可以设置访问密钥。如果你只在本地使用，不需要暴露到局域网，保持默认即可。

云端API的接入需要你有一个云端模型的API Key。在WorkBuddy的“云端模型”设置里填入API地址和密钥，然后测试连接。连接成功后，云端模型会出现在路由规则的可选目标里。

路由规则的配置界面很直观，左边是条件设置，右边是目标选择。条件支持关键词匹配、上下文长度判断、请求来源识别等。我前面分享的四条规则就是在这里配置的。

配置完成后建议做一次测试。在对话界面里分别发送一条包含“本地文件”的请求和一条需要联网搜索的请求，观察WorkBuddy的路由日志，确认请求被正确分发到了不同的模型。

4.4 实际任务中的性能表现

我用这套配置跑了几个典型任务，记录一下实际表现。

代码生成任务：让模型写一个Python的快速排序实现，本地35B模型在3秒内完成了生成，代码可以直接运行。对比云端模型，质量基本一致，但本地没有网络延迟，整体响应更快。

长文档问答：上传了一份50页的技术文档，让模型总结核心观点。本地模型处理这个任务用了大约40秒，输出质量不错，但中间有两次因为上下文接近上限而出现了信息遗漏。后来我把这个任务的路由规则改成了云端处理，效果更稳定。

多轮对话：连续进行了20轮技术讨论，本地模型保持了良好的上下文连贯性，没有出现明显的遗忘或重复。内存占用稳定在24GB左右，没有持续增长。

批量处理：同时提交了10个代码审查请求，本地模型逐个处理，总耗时约2分钟。如果走云端API，按token计费大约需要0.5元，本地处理则是零成本。

5. 常见问题与排查技巧实录

5.1 部署阶段的高频问题

模型下载中断怎么办？这是最常见的问题。WorkBuddy支持断点续传，重新启动下载任务即可。如果反复中断，建议检查网络稳定性，或者换一个下载源。在设置里可以配置镜像源，国内用户建议选择国内的镜像。

提示内存不足怎么处理？首先确认你的物理内存是否达到32GB。如果达到了但仍然报错，检查是否有其他程序占用了大量内存。浏览器是内存大户，部署和运行模型时建议关闭不必要的标签页。另外，可以在WorkBuddy的设置里调低上下文长度和批处理大小，这两个参数直接影响内存占用。

推理服务启动失败怎么排查？先看日志。WorkBuddy的日志文件在安装目录的logs文件夹下，里面有详细的错误信息。常见的失败原因包括端口被占用、模型文件损坏、推理引擎版本不匹配。端口问题可以在设置里换一个端口；模型文件损坏需要重新下载；引擎版本问题通常更新WorkBuddy就能解决。

NPU没有被调用是什么原因？检查驱动版本。NPU需要较新的驱动才能正常工作，建议去Intel官网下载最新的驱动包。另外，确认WorkBuddy的推理后端选的是OpenVINO，其他后端可能不支持NPU调度。

5.2 运行阶段的性能问题

推理速度突然变慢怎么办？最常见的原因是内存不足导致系统开始使用虚拟内存。打开任务管理器看一下内存占用，如果接近100%，说明需要关闭一些后台程序，或者降低模型的量化精度。另一个可能的原因是设备过热导致降频，检查一下散热情况。

输出质量下降怎么调整？如果发现模型输出变得敷衍或者逻辑混乱，先检查上下文长度是否接近上限。上下文快满的时候，模型的表现会明显下降。另外，温度参数调得太高也会导致输出不稳定，建议降到0.5以下试试。

端云切换不生效怎么排查？检查路由规则的优先级顺序，确保具体规则在通用规则前面。然后看路由日志，确认请求是否被正确匹配。如果规则配置没问题但切换不生效，可能是云端API的连接有问题，在设置里重新测试一下连接。

5.3 常见问题速查表

5.4 几个容易被忽略的细节

第一个细节是模型缓存目录的管理。WorkBuddy在运行过程中会产生缓存文件，包括KV Cache的持久化数据和推理中间结果。这些文件会随着使用时间增长而累积，建议定期清理。在设置里有“清理缓存”的选项，我一般每周清理一次。

第二个细节是系统电源模式。笔记本在“节能”模式下会限制CPU和GPU的性能，导致推理速度大幅下降。部署和运行模型时，建议把电源模式调到“最佳性能”。如果在意续航，可以在不使用时切回节能模式。

第三个细节是WorkBuddy的版本更新。这个工具迭代比较快，新版本通常会优化推理性能、增加新的模型支持、修复已知问题。建议开启自动更新，或者至少每个月手动检查一次。

第四个细节是模型的选择。35B只是一个参数量级，不同厂商、不同训练数据的35B模型在实际表现上差异很大。WorkBuddy的模型库里有多个选择，建议先都试一下，找到最适合你使用场景的那个。我自己的体验是，代码类任务选代码微调版本，通用对话选指令微调版本，效果差别很明显。

5.5 关于端云混合的成本账

最后算一笔账。假设你每天使用大模型处理100个请求，平均每个请求消耗500 token的输入和500 token的输出。全部走云端API的话，按目前主流云端模型的价格，每天的成本大约在3到5元，一个月就是90到150元。

采用端云混合之后，大约80%的请求在本地处理，只有20%的复杂请求走云端。本地推理的电费成本几乎可以忽略不计，云端成本降到每天不到1元，一个月不到30元。省下来的钱虽然不算多，但长期来看，一年能省下近千元。更重要的是，本地处理带来的隐私保障和响应速度提升，这些价值不是用钱能衡量的。

我在实际使用中还发现一个额外的好处：本地模型不会因为网络波动而中断服务。有一次家里网络出了故障，云端API完全不可用，但本地模型照常工作，那天的任务一点没耽误。这种可靠性在关键时刻真的很重要。

这套方案目前已经稳定运行了三个月，期间处理了代码生成、文档分析、技术问答等各类任务，整体表现超出预期。如果你也在考虑端侧部署大模型，35B加WorkBuddy加Intel平台的组合值得一试。