Hugging Face 最近在自家 OpenClaw 仓库做了一轮实验：把 Gemma 4-26B 和 Qwen 3.6-35B 这类本地模型拉出来，让它们实时给 Issue 和 PR 做分类、贴标签，顺便决定要不要拉人来处理。整套方案跑在一台 NVIDIA GB10 上，统一内存 128 GB，模型本地推理速度能冲到每秒数百 token。听起来并不炸裂，但细看工程细节，这套东西给"本地模型替代云端 API 做自动化任务"提供了一个相当完整的范本。
为什么要在本地跑一个分类器
月费 200 美元的"分类工作"被盯上了
ChatGPT Pro 订阅每月 200 美元，能换来顶级的对话能力，但 Hugging Face 团队意识到，他们 90% 的使用场景其实很简单：判断一条 Issue 是不是 bug、是不是需要人工介入、该转给哪个模块的负责人。这种"看一眼内容然后打标签"的活儿，根本不需要一个万亿参数的云端大脑。更尴尬的是，云端方案有延迟——用户提完 Issue，往往等上好几分钟才有自动回复，体感很差。本地推理的响应时间可以压到几秒钟，对实时通知场景几乎是降维打击。
128 GB 统一内存改变的游戏规则
GB10 这颗芯片的特殊之处在于 CPU 和 GPU 共享 128 GB 统一内存，这直接抹平了过去"大模型塞不进显存"的门槛。Gemma 4-26B 的全精度权重大约 50 GB 左右，Qwen 3.6-35B 也差不多，两者在 GB10 上都不需要做激进的量化就能完整加载。经过推理框架的性能调优，模型在本地可以稳定输出每秒数百 token——对分类任务而言，这相当于把一次请求的端到端延迟压进了秒级。云端 API 即便速度快，也要走公网、排队、还要付 token 费，本地方案的边际成本几乎只剩电费。
工程防线：只读 Shell 和 Agent Harness
reposhell：给模型戴上"只能看不能动"的镣铐
让 LLM 直接接触 Git 仓库有巨大风险：提示词注入。攻击者完全可以在 Issue 正文里塞一段诱导文本，让模型执行 git push --force 或者 rm -rf。这种事在小项目上也许只是笑话，在生产环境就是灾难。Hugging Face 的解法是 reposhell——一个被严格限制权限的自定义 shell，只暴露 read 类操作（ls、cat、git log、git diff），任何写入、删除、网络请求命令一律拒绝。这样即便模型被注入，它能造成的破坏也被锁死在"读文件"这个圈子里。
Pi agent harness：让模型有步骤地"思考"
光有只读 shell 还不够，模型需要知道"什么时候读什么"。Hugging Face 用了一套叫 Pi agent 的 agent harness 框架来驱动整个流程。简单说，它把分类任务拆成几个阶段：先让模型概览仓库结构，再读相关文件的最新 diff，然后结合 Issue 文本给出分类结论。harness 的作用是在每一步之间插入校验和上下文整理，防止模型上下文窗口溢出，也避免它陷入无限循环的"再读一遍"困境。这种"分步推理 + 工具调用"的模式，本质上是把 ReAct 类 agent 思路压缩进了一个极窄的分类场景。
实测表现与成本对照
本地 200 token/s 是什么概念
分类一条 Issue 通常需要模型读几百到一两千 token 的上下文，再输出几十个 token 的结论（比如"bug / feature request / docs / need-human"四选一加上简短理由）。模型生成端 200+ token/s 的速度，意味着单条分类的模型推理时间不超过 1 秒。再算上文件读取和 agent harness 的调度开销，整条链路从 Issue 创建到自动标签落定，延迟稳定在 5 秒以内。放在 GitHub 通知的时间线里看，用户还没来得及刷新页面，机器人已经回复了第一条评论。
200 美元月费 vs. 一台 GB10 的电费
账很好算。ChatGPT Pro 每月 200 美元，一年 2400 美元。GB10 设备一次性投入（参考 DGX Spark 的定位大约在数千美元级别），按 7×24 满载运行估算电费，月均几十美元。一年下来本地方案的运行成本不到云端订阅的三分之一，而且没有任何 token 配额焦虑。对于 Hugging Face 这种每天可能涌进几十上百条 Issue 的开源项目，这笔账怎么算都划算。唯一的隐性成本是运维——本地模型偶尔会"胡说八道"，需要人工抽样审计分类结果，及时调整 prompt 或切换模型版本。
这套配方能复制到哪些场景
开源项目的"自动化前台"
任何维护者头疼的 GitHub 仓库都能直接套用：自动识别重复 Issue、归类到对应模块、标记优先级、@相关维护者。Hugging Face 把方案和模型配置都放出来了，其他团队只需要改改 prompt 模板和分类标签就能跑起来。这种"开箱即用的 triage 机器人"对中小型开源项目尤其友好，毕竟大部分维护者没有精力给每条 Issue 做第一轮筛选。
企业内部工单系统的平替方案
思路完全可以平移到 Jira、Linear、禅道这类内部工单系统。分类规则本地化、敏感数据不出网、推理延迟可控——这三点对很多受合规约束的企业来说是刚需。如果再叠上向量检索做历史工单匹配，本地模型完全能撑起一个不依赖任何外部 API 的智能工单分拣流水线。
回到这次实验本身，它最大的价值不是证明 Gemma 4 或 Qwen 3.6 有多强，而是展示了一套工程上可落地的"本地 agent 替代云端订阅"的样板间。只读 shell 防注入、agent harness 分步调度、统一内存硬件兜底性能——三个组件缺一不可。当硬件门槛被 GB10 这类设备降到桌面级，"每月 200 美元的云端依赖"就不再是不可替代的默认选项了。
