花了两万多配的机器平时就跑个聊天机器人GPU占用率不到10%这不叫本地部署这叫暴殄天物。这是我一个朋友上周跟我吐槽的原话。他跟着网上的教程用 Ollama 在本地跑起了 DeepSeek满心欢喜以为从此拥有了自己的 AI 工作站。结果新鲜劲一过发现这台机器 90% 的时间都在吃灰——人在公司家里的 GPU 闲着人在路上手机上的 AI 只能调云端 API。本地部署的价值被锁死在了那台机器面前这恐怕是很多人折腾完本地大模型之后最深的挫败感。本地部署大模型的真正魅力从来不在于我能跑起来一个模型而在于我能随时随地、以极低的边际成本调用这份算力。折腾过 DeepSeek、Qwen 或者 ComfyUI 的朋友应该都有同感模型下载下来只是第一步怎么让它物尽其用才是真正的技术活。这篇内容我准备结合自己这段时间的实操聊一聊如何把本地部署的 AI 算力彻底用起来重点讲讲为什么我最终选了 UU远程 作为通路以及怎么从零到一打通家里算力 手边终端这条链路。无论你是刚用 Ollama 跑通 DeepSeek 的新手还是已经在本地部署了 ComfyUI、Dify 甚至自己在折腾 Agent 的老手这篇都值得看完——尤其是那些机器性能不错但利用率不高的朋友这篇就是冲着你写的。1. 本地部署不只是跑个模型先想清楚你要榨干的是什么很多人的本地部署之路是从一句我要在本地跑 DeepSeek开始的。这一步没错但绝大多数人止步于此——模型能对话了就感觉自己任务完成了。实际上本地部署的完整价值链条比这长得多也复杂得多。1.1 本地算力真正的稀缺价值在哪里先说个反直觉的观点对大多数个人用户和中小企业来说本地部署最大的价值不是省钱而是可控性和可用性。调用云端 API 当然省事但你会发现几个绕不开的痛点一是数据隐私某些业务数据和对话内容你根本不想经过第三方服务器二是延迟和稳定性API 接口的响应速度受制于网络和对方服务端负载高峰期能慢到让你怀疑人生三是边际成本当你需要批量处理任务、做大量推理实验时API 的计费会让你看着账单心疼。本地部署解决的就是这三件事。尤其像 DeepSeek 这种开源模型本地跑起来之后你实际上获得的是一个完全自主的推理引擎。但这里有个关键认知本地部署的硬件投入属于沉没成本你只有不断让它产出结果这笔投资的回报率才为正。所以榨干算力不是一句口号而是本地部署这件事本身就要求你必须走到的一步。1.2 谁在真正消耗算力从 DeepSeek 对话到 ComfyUI 渲染的算力画像搞清楚算力去哪了才知道怎么榨干它。我在本地主要跑三类负载每一类的资源消耗模式完全不一样大语言模型推理Ollama DeepSeek / Qwen这是典型的短时高并发场景。单次对话生成的 token 数量有限但生成过程中 GPU 的算力占用会瞬间拉满。这类负载的特点是单次请求时间短几秒到几十秒但频次可以很高而且是多路并发时才能有效压满显卡。ComfyUI 图像生成这是典型的稳定高占用场景。生成一张图可能需要几十秒到几分钟GPU 利用率全程维持在 90% 以上。这类负载是真正的算力吞金兽但也正因为耗时较长你往往不需要守在机器旁边远程提交任务后等着收图就行。Dify / Agent 工作流这是混合型负载。一个 Agent 任务可能先调用本地大模型做推理再调用图像模型生成配图中间还穿插着向量检索之类的操作。资源利用不均匀但整体越复杂的工作流对算力的综合调度要求越高。我在实际使用中发现大多数人的算力浪费不是因为模型跑不起来而是因为人不在机器前。你在上班的时候家里的 GPU 是闲着的你在开会的时候ComfyUI 渲染队列是空的。这不是硬件不够强而是访问链路没有打通。所以真正要解决的问题不是怎么把 GPU 跑满而是怎么让 GPU 随时听你调遣。1.3 先搭好模型运行底座Ollama 之外的选择与取舍既然要谈榨干算力底座的选型就很重要。目前本地部署大模型的主流方案有这么几类Ollama最省心的选择安装即用命令行工具做得很顺手模型管理一键完成。适合刚入门、想快速验证效果的人。llama.cpp 系列更底层的推理框架支持量化模型对低显存场景更友好。缺点是配置麻烦适合动手能力强、想极致压榨硬件性能的人。vLLM面向生产环境的高性能推理框架支持连续批处理并发性能极强。如果你的目标是搭建一个多用户使用的推理服务这是目前最优解但对个人玩家来说学习曲线比较陡。我自己现在的方案是 Ollama DeepSeek-R1 蒸馏版同时配合 ComfyUI 做图像生成。选择 Ollama 的理由很简单它提供了统一的本地 API 服务默认监听在 11434 端口后续做远程映射和接口调用都非常方便。相比之下如果你直接跑 Python 脚本加载模型虽然更灵活但做远程访问时的工程量会大很多。提示本地部署模型之前先确认你的硬件驱动和 CUDA 版本。我的排查经验是90% 的模型能跑但特别慢问题根源都在于推理进程压根没有走 GPU而是默默跑在 CPU 上。运行nvidia-smi看一下进程列表如果看不到你的模型进程基本可以断定是 CUDA 库没配对。2. 算力从本地独占到随处可达为什么我选中了 UU远程模型能在本地跑了接下来最关键的一步就是打通访问链路。这件事看着简单做起来水很深。我在这个环节踩过的坑可能比跑模型本身还多。2.1 公网 IP、端口映射和第三方穿透方案的痛点复盘先说说那些看上去可行的方案实际用起来是什么体验。公网 IP 路由器端口映射要求你有公网 IP还要在路由器上配端口转发然后还要搞定动态 DNS。我折腾过结果是运营商根本不给你分配公网 IPv4打电话申请还要各种理由。就算申请下来了家里的宽带 IP 经常变DDNS 解析延迟和穿透成功率都让人头疼。第三方内网穿透服务市面上有很多基于 frp 或类似原理的穿透服务配置起来不算难但有几个绕不开的问题免费版限速严重传个大一点的模型文件能等到崩溃服务器节点在国外的话延迟高到你敲一个字符等半秒还有就是安全问题流量绕行第三方服务器总让人不太放心。自建 frp 服务器如果你恰好有一台云服务器用 frp 自建内网穿透是可以的。但这意味着你还要维护一台服务器的安全补丁、流量费用和带宽上限终归是笔额外开销。这些方案也不是不能用就是每种都缺了点什么要么太折腾要么太慢要么不够安全。直到朋友给我推荐了 UU远程我才觉得这件事终于有了一个正经解。2.2 UU远程的技术底牌不只是一条加密通道先说清楚 UU远程是什么它是一款远程控制软件但它的底层技术实力比我用过的很多同类产品要好得多。经过这段时间的使用我把它和普通远程控制工具的区别总结为三点智能路由与带宽调度UU远程的传输协议会根据当前网络情况自动选择最优线路。实测下来在公司网络环境访问家里的机器画面响应速度明显比传统远程桌面方案要顺滑。低延迟交互优化远程操作中最影响体验的就是延迟。UU远程在编码和解码层面做了不少优化对我来说最直接的感受是远程操作 ComfyUI 的节点拖拽和参数调整时几乎感觉不到迟滞。安全链路建立方式它不需要你在路由器上开任何端口也不需要把自己的机器暴露到公网而是通过客户端之间的点对点或中继加密通道建立连接。这意味着即使你是纯内网环境只要能上网就能安全访问到家里的算力。类似的远程工具我也对比过几款操作简洁度上 UU远程对新手更友好很多同类软件设置向导复杂打开先填一堆端口配置而 UU远程 可以说是极简路线登录、配对、连接三步完事。2.3 本地模型服务与 UU远程 的天然契合点为什么说 UU远程 特别适合远程调本地算力这个场景关键在于它的双重身份既能当远程桌面用又能当远程网络通道用。当我把本地部署的 Ollama 服务绑定到 127.0.0.1 时通过 UU远程 连接到那台机器后我可以在对方的本地网络上直接访问这个地址不需要额外改任何配置。这意味着什么意味着我在 MacBook 上可以写一个 Python 脚本通过 UU远程 提供的虚拟网络路径直接向家里那台 Windows 机器上的 Ollama 发出推理请求。这种感觉就像是那台 GPU 服务器变成了我随身携带的计算资源。另外UU远程 支持安卓 7.0 及以上版本手机安装客户端之后也能随时连回家里。我在外面用手机提交一个 ComfyUI 生成任务到家的时候图已经渲染好躺在那里了。这种体验是以前守着机器操作时完全无法想象的。3. 端到端实操从部署环境到手机遥控的完整链路搭建理论铺垫差不多了下面进入实操环节。这一部分我会按我实际操作的顺序完整跑一遍从环境准备到手机直连的流程每一步都标注关键细节和容易踩的坑。3.1 环境准备硬件、系统和软件清单先说我的环境供参考算力端Windows 10 主机RTX 4070 Ti Super 16GB 显存64GB 内存千兆有线网络控制端固定MacBook Pro日常办公主力机控制端移动安卓手机安装 UU远程 客户端软件层面算力端装了三样核心东西Ollama代理 DeepSeek-R1 蒸馏版 7B/14B 模型ComfyUI配合 SD 系列模型做图像生成UU远程 客户端负责打通访问链路这里特别强调一下如果你准备用 UU远程 做算力远程调度先装好算力端的模型服务再装 UU远程。两者之间没有依赖冲突但先把服务跑通、本地测试无误再接入远程排查问题会容易很多。3.2 算力端配置让模型服务监听在安全可达的地址上这是整个链路里最关键的一步也是很多人搞不明白的一步。Ollama 默认安装后服务只监听 127.0.0.1也就是说只有本机可以访问。如果你想让同一局域网内的其他设备也访问这台机器的 Ollama 服务需要修改环境变量让服务监听在 0.0.0.0。操作步骤在 Windows 上打开编辑系统环境变量新建一个系统变量变量名为OLLAMA_HOST值为0.0.0.0。设置完成后重启 Ollama 服务。这时候你在局域网内的另一台设备上访问http://算力端IP:11434就能看到 Ollama 的响应了。提示如果你只是通过 UU远程 的远程桌面功能来操作算力端那么 OLLAMA_HOST 保持默认 127.0.0.1 就可以不需要做任何网络暴露。但如果你想像我一样在控制端直接用脚本调用本地模型 API那么把监听地址放开是必要的一步。安全方面你不需要担心因为 UU远程 建立的链路是加密的虚拟通道外面的人扫描不到你这台机器上开放的端口。ComfyUI 的配置逻辑类似。启动命令里加--listen 0.0.0.0就能放开局域网访问默认端口是 8188。需要注意的是如果你要让 ComfyUI 支持 API 调用还要注意--enable-cors-header参数不然从 Web 页面发起的跨域请求会被拦掉。3.3 控制端接入MacBook 和安卓手机的双通道验证算力端准备就绪后接下来就是接入环节。在算力端Windows安装 UU远程 客户端注册账号并登录在控制端MacBook 和手机安装对应系统的 UU远程 客户端使用同一账号登录登录后控制端会自动发现同一账号下的在线设备点击连接就能进入远程桌面我第一次用的时候整个过程只花了五分钟。这里要表扬一下 UU远程 的连接速度基本是秒连不像某些工具先来个几秒钟的握手动画。而且安卓 7.0 这个兼容门槛很低就算是几年前的旧手机也能当遥控器用真的不用为了这事儿换手机。连接成功之后你可以做两个验证打开浏览器访问http://127.0.0.1:11434在远程桌面的浏览器里确认 Ollama 服务正常在 MacBook 的终端跑一个测试命令通过 UU远程 的虚拟局域网能力直接访问算力端的 11434 端口看能不能拿到模型列表验证通过后你的本地算力就算是真正接入互联网了但这里的互联网是 UU远程 私有虚拟链路构成的安全网络不是裸奔公网。3.4 远程调用接口用一段 Python 代码调用家里的 DeepSeek这是我最喜欢的部分也是榨干算力的实质操作——让远程机器成为你代码里的一个函数。在 MacBook 上我写了一段 Python 脚本核心逻辑就是向家里的 Ollama 服务发送一个流式推理请求import requests import json OLLAMA_URL http://算力端在UU远程中的访问地址:11434/api/chat payload { model: deepseek-r1:14b, messages: [ {role: user, content: 帮我写一段Python代码实现递归遍历目录并统计文件大小} ], stream: True } response requests.post(OLLAMA_URL, jsonpayload, streamTrue) for line in response.iter_lines(): if line: chunk json.loads(line) if not chunk.get(done, False): print(chunk.get(message, {}).get(content, ), end, flushTrue)这段代码跑通的瞬间你会真正理解算力自由的含义——你的终端在哪里算力就在哪里。我在咖啡馆、高铁上、客户现场都这么干过只要手机有信号家里的 GPU 就是我的远程协处理器。同样的逻辑也适用于 ComfyUI 的 API。你可以在控制端写一个 HTTP 请求提交一个包含工作流 JSON 和图片参数的 POST 请求到http://算力端地址:8188/promptComfyUI 就会开始排队渲染完成后通过 WebSocket 通知你结果或者直接访问输出目录拿图。4. 榨干算力的进阶玩法并发调用、工作流编排与光谱优化链路打通了但这只解决了能用的问题。接下来才是正题怎么让算力真正被榨干而不是辛苦搭好链路之后每天就跑一两个请求。4.1 Ollama 并发参数调优让一块 GPU 干多份活很多人不知道Ollama 默认对并发请求的处理是串行的——一个请求处理完下一个才开始。这导致当你批量提交任务时GPU 利用率像心电图一样波动大部分时间是空闲的。通过设置环境变量OLLAMA_NUM_PARALLEL可以改变这个行为。这个参数控制的是同时处理的请求数量我实测下来把它设为 4 之后GPU 的利用率有了质的提升。配合另一个参数OLLAMA_MAX_LOADED_MODELS你还可以让多个不同模型同时驻留在显存中减少模型切换时的加载耗时。我的建议配置参数推荐值说明OLLAMA_NUM_PARALLEL4同时处理请求数太高会导致单请求响应变慢OLLAMA_MAX_LOADED_MODELS2同时驻留的模型数量取决于显存容量OLLAMA_KEEP_ALIVE5m模型请求结束后的驻留时间避免频繁加载这里有个平衡点要掌握并发数不是越大越好。如果显存只有 8GB跑 7B 量化模型时并发调到 4 可能直接把显存撑爆。我的经验是先小步快跑从 2 开始逐步往上加每次调整后跑同一个测试脚本观察响应时间和显存占用找到甜点值。4.2 把 ComfyUI 变成远程渲染农场批量出图、队列管理的实战ComfyUI 单机部署之后如果你只是偶尔远程操作一下界面生成一张图那算力利用率还是不够看。真正的玩法是把它变成一个渲染农场。我的做法是写了一个批处理脚本定时从某个目录读取待处理的任务 JSON里面包含工作流配置和参数逐条提交给 ComfyUI 的 API。这样到了晚上家里的 GPU 会自动开始跑白天积累下来的渲染任务第二天早上一睁眼就能收到一整套成品图。要点有几个用POST /prompt提交任务前一定要先把工作流 JSON 里的seed字段改成随机值不然每次生成的都是同一张图给每个任务设置唯一的client_id然后用 WebSocket 监听http://算力端地址:8188/ws?clientIdxxx获取进度和完成事件如果渲染队列长时间不消费检查一下是不是工作流里用了某些节点库而算力端没装对应的自定义节点我踩过最深的坑是远程提交一个 ComfyUI 任务时报 400 错误反复排查后发现是工作流 JSON 里引用了本地文件路径而那个路径是我 MacBook 上的路径算力端当然找不到。后来统一改为相对路径 算力端共享目录问题就解决了。4.3 借助 Dify 和 Agent 工作流把多个模型串成一条生产线单一模型的调用再频繁也有限度真正能把算力吃透的是把本地这些模型串成一条生产线。我是用 Dify 来编排工作流的它支持接入本地 Ollama 服务作为一个自定义模型供应商也支持调用 HTTP 节点来触发 ComfyUI 渲染。一个具体例子我搭建了一个自动配图写稿Agent。当我在手机端或 Web 端提交一个主题后Dify 工作流先调用本地 DeepSeek 生成文章框架再通过 HTTP 节点把文章关键词提交给 ComfyUI 生成配图最后把所有内容汇总返回。整个过程全部在本地算力端完成云端只承担协调和展示的角色。这个工作流跑起来后我的 4070 Ti Super 在白天也能保持较高的利用率——因为 Dify 本身跑在同一台机器上你随时随地通过 UU远程 打开 Dify 的后台都能看到任务运行状态。这种人不在场但生产线运转的感觉才是榨干算力的终极形态。4.4 算力优化的监测工具与调优思路想要持续优化你得知道算力端每一刻在干什么。分享几个实用工具nvidia-smi查看 GPU 利用率、显存占用、温度。写个定时任务把输出记录到文件跑一段时间后分析利用率曲线。Ollama 自带的日志通过journalctl -u ollama或 Windows 事件查看器能看到每次请求的处理耗时和模型加载情况。ComfyUI 的队列管理页面/queue接口能返回当前排队状态可以用来做任务量统计。基于这些数据我最近的优化动作是把 DeepSeek-R1 蒸馏版从 14B 换回 7B因为分析发现 80% 的日志请求根本用不到 14B 的推理深度换小模型后并发能力反而翻倍了。算力这种东西适合的才是最好的别光盯着参数规模看。5. 这条路走下来我的三点实用心得聊到这里该分享的链路已经完整了。最后说几点我实际跑了这段时间的感受供准备入坑或正在折腾的朋友参考。第一别追求一步到位。很多人一上来就想把所有模型部署好、把所有链路打通结果这个星期卡在驱动下个星期卡在端口映射折腾半个月就放弃了。我的建议是先跑通最小闭环一台机器、一个 Ollama、一个 UU远程哪怕只是实现在公司远程打开家里机器的命令行跑一条模型推理也算成功了。在这个基础上逐步加 ComfyUI、Dify、并发调优每一步都能验证每一步都有正向反馈这事才做得下去。第二安全这根弦不能松。虽然 UU远程 的链路本身是加密的但你在算力端放开监听地址时还是要意识到这台机器暴露在远程可达的状态。建议给模型服务加上简单的鉴权Ollama 支持自定义 API Key 或通过代理层做 Token 校验ComfyUI 的端口也尽量不要用默认的 8188换成不常见的端口能减少很多扫描流量。我见过有人直接把 Ollama 的 11434 端口映射到公网结果日志里被打满了乱七八糟的请求。第三也是最核心的一点算力这东西用起来才叫资产闲置着就是负债。本地部署的价值不在于你跑通的那一瞬间而在于未来一年里它持续给你产出的结果。把 UU远程 装好、把自动化任务链跑起来之后我的工作方式发生了很大变化——我现在更愿意把一些批量处理、实验性、数据敏感的任务放到本地执行因为我知道自己有了一条随时可用的高速通道。这种安全感是花钱调用云端 API 给不了的。折腾这套东西的每一步几乎都会遇到文档里找不到答案的问题。我的经验是先复现别人的成功路径再根据自己的场景做微调。希望这篇内容能让你少走几步弯路。