Jev 101 logo
Jev 101

Guides / 视频转图文攻略

Ollama 决策模型实测：tev1 + nimble 跑在 8GB 显卡上

Ollama 0.35 新增 /v1/systemone 端点实操：拉取 tev1（4B/0.8B，Together AI）与 Nimble（9B，Bespoke Labs），几百毫秒完成工单路由与内容审核，再用同一组 30 张工单对比「强制 JSON schema 的聊天模型」。

速览结论

Ollama 0.35（随 2026-09-29 官宣一同上线）新增了 /v1/systemone 端点——注意这不是聊天端点——让 Jev 系决策模型在你自己的机器上运行。当前有两个模型族：Together AI 的 tev1（4B 与 0.8B，Qwen 3.5 续训）和 Bespoke Labs 的 Nimble 9B（Apache 2.0）。视频在一张 8GB 笔记本显卡上走完了全程：拉模型、通过三次报错学会挑剔的请求格式、跑四页签的 Decision Lab（分流、审核、路由、评分）。在他自制的 30 工单测试（自嘲只是个好开头、不算基准）里，tev1 4B 团队路由 100%、470ms、占 4.7GB 显存；Nimble 96.7% 但单次 1.5s 还溢出到 CPU；0.8B 只要不到 1GB。最有信息量的是对照实验：普通 Qwen 3.5 聊天模型强制 JSON schema 后精度打平、速度还更快（268ms）——但它给不了校准置信度（决策模型的错误全部落在 0.9 以下），也给不了一致性（同一张工单 8 次里 7 次答 billing）。一个实验讲透了本地决策模型的全部卖点。

视频来源

Prompt Engineer 48

8:18sc-qe-gNwKk
访问频道观看原视频

分步图文攻略

  1. 1

    从官方公告开始：Ollama 学会了 System One

    视频开场是 Ollama 2026 年 9 月 29 日的博客：「Ollama 现已支持 Jev 系决策模型」。基于 TypeSafe Jev API 的决策模型从此可以在你自己的机器上通过新端点运行——公告强调三点：无额外费用、本地运行延迟更低、当天即有三款新模型可用。后面要用到的伏笔也在这页里：新 API 要求 Ollama 0.35 或更高版本，动手前先 ollama --version。视频作者恰好是 0.35.0——压线达标。

    Ollama 2026 年 9 月 29 日博客公告：支持 Jev 系决策模型，无额外费用、本地更低延迟、三款新模型经 Ollama 上线
    2026-09-29 官宣：Jev 系决策，本地跑，零额外费用。跳转至 0:25
  2. 2

    认识阵容：tev1 两个尺寸 + Nimble 9B

    ollama list 里多了三个模型。tev1 来自 Together AI：4B 版（「一款来自 Together AI 的快速分类决策模型」，下载 4.5GB）和 0.8B 版（811MB），都以 Qwen 3.5 为底座续训。Nimble 是 Bespoke Labs 的 9B 模型，Apache 2.0 协议（文件 7.5GB）。官方公布的基准成绩：tev1 4B 拿 73.3%，Nimble 拿 75.7%——视频特意标注这是厂商数字，然后跑了自己的测试。两个模型页都离一条 ollama run 命令不远。

    ollama list 输出：tev1 0.8b 811MB、nimble latest 7.5GB、tev1 latest 4.5GB 三个模型并列
    811MB、4.5GB、7.5GB——整个决策模型菜单装得进一台笔记本。跳转至 2:13
  3. 3

    用三次报错学会请求格式

    这不是聊天端点——是 11434 端口上的 /v1/systemone，请求体带 model、state 和若干命名问题。第一发 curl 直接报错：「question team: instructions must be a nonempty string, object, or array」。第二发错得更友好：choice 的 criteria 必须是「选项 key → 描述」的 map（比如 billing → 付款与退款）。第三发教你 score 的 criteria 是描述数组，不是 map。每条报错都会告诉你缺什么——但教训是刚性的：schema 刚性、校验刚性。先抄格式，再自由发挥。

    终端显示 curl 调用 localhost 11434 v1 systemone 返回错误：question team 的 instructions 必须是非空字符串
    三连报错的第一发：每个问题都必须带 instructions 字符串。跳转至 2:32
  4. 4

    一次调用、三个类型化问题、4 个输出 token

    格式对了之后，一个请求对同一张工单问三个问题，答案一次性全部返回：billing 0.9975（choice）、客户愤怒 0.87（noul）、紧急度 0.65（score）。解释速度的数字是那个「4」：输出只有 4 个 token。模型什么都不生成——答案和概率在一次前向里直接算出来，这就是决策端点敢挂在每条消息热路径上的原因。单次请求最多可以塞 64 个问题。

    结果卡片：billing 0.9975、angry 0.87、urgency 0.65，一次 systemone 请求只输出 4 个 token
    billing 0.9975 + angry 0.87 + urgency 0.65——输出只有 4 个 token。跳转至 3:15
  5. 5

    看它分流：四页签的 Decision Lab 应用

    作者把端点包进一个 Gradio 小应用。分流页签里，「我的卡被扣了两次款，我要退款」以 0.99 置信度路由到 billing，耗时 733ms（输入 794 token、输出 4 个）；「API 返回 500，生产挂了」以 0.94 进 tech。最有说服力的一条：「非营利组织有折扣吗？」落在 sales——整句话没有一个行业关键词。模型读的是意图不是词表，而且每个答案都带一个可以拿去做门控的数字。

    Decision Lab 分流页签：双扣款退款工单以 0.99 置信度路由到 billing，angry 0.88、urgency 0.60，耗时 733ms
    退款工单 → billing 0.99，733ms；看意图，不看关键词。跳转至 3:35
  6. 6

    内容审核 = 一次前向里的三个 yes/no 闸门

    审核页签对每条消息并行发三个 noul 问题：spam、个人隐私、毒性。一条诈骗消息（「恭喜!! 你赢了 1000 美元，点击 http://free-cash.xyz 并发送你的卡号」）返回 spam 0.97 BLOCK、pii 0.95 BLOCK、toxic 0.09 放行。应用里的规则很简单：超过 0.75 就拦。每个闸门暴露各自独立的概率，所以「卡号泄露」和「诈骗链接」可以走不同的处置策略——不用第二次模型调用。

    审核页签：诈骗中奖消息 spam 0.97 与 pii 0.95 双双 BLOCK，toxic 仅 0.09，适用 75% 拦截规则
    spam 0.97、pii 0.95、toxic 0.09——三个闸门，一次前向。跳转至 4:10
  7. 7

    诚实时刻：一句友好消息被打了 spam 0.66

    「Hi, I am John, call me on +1 415 555 0134」——个人隐私闸门正确触发（0.98），但 tev1 给 spam 打了 0.66，Nimble 打了 0.49。留电话的打招呼不常见，但不诈骗，模型在犹豫。这个犹豫正是作者把拦截阈值设成 0.8 而不是默认的 0.5 的原因：阈值是你看过真实误报之后做出的策略决定，不是一个可以直接抄的数字。这一分钟是全片最值得搬走的经验。

    友好消息的审核结果：pii 0.98 正确拦截，但 spam 只打 0.66，逼近阈值构成误报案例
    友好消息 spam 0.66——他的拦截线因此画在 0.8。跳转至 4:22
  8. 8

    30 工单自测：tev1 4B 路由零失误

    他自己写了 30 张客服工单，每张都标好正确团队和愤怒等级——并明确说明这是个人自测，不是公开基准。结果：tev1 0.8B 团队 86.7%、愤怒 76.7%，235ms，占 0.9GB；tev1 4B 团队满分 100%、愤怒 83.3%，470ms，4.7GB 全在 GPU 上；Nimble 9B 愤怒检测最强（96.7%）、团队 96.7%——但单次要 1.5 秒。他给 8GB 笔记本的结论：跑 tev1 4B；Nimble 需要 12GB 以上才值得；0.8B 是显存告急时的退路。

    30 张自标注工单的团队准确率条形图：tev1 0.8b 86.7%、nimble 9b 96.7%、tev1 4b 100%
    他的 30 张工单：0.8B 86.7%，Nimble 96.7%，tev1 4B 干净的 100%。跳转至 6:12
  9. 9

    Nimble 慢在哪：10GB 塞不进 8GB 卡

    ollama ps 解释了 Nimble 的 1.5 秒：加载后约占 10GB，对 8GB 显卡意味着大约 40% 的计算落在 CPU 上。还有一个并发陷阱：tev1 还在显存里时调用 Nimble，直接吃到一个 host 侧 500（CUDA host buffer 分配失败），直到他 ollama stop tev1 才恢复。小卡的操作守则：一次只驻留一个决策模型；像规划部署一样规划你的卸载。

    ollama ps 输出：nimble 占用 10GB、CPU 40% GPU 60%，附注「10 GB does not fit 8 GB」
    Nimble 的 10GB：40% CPU 溢出，是精度领先付出的代价。跳转至 6:06
  10. 10

    对照实验：把聊天模型按进 JSON 里

    「为什么不直接让普通模型输出 JSON？」他拉了 Qwen 3.5 4B，强制 JSON schema，跑同一组 30 张工单：团队 96.7%、愤怒 96.7%，耗时 268ms——精度与 Nimble 打平，速度还领先所有决策模型。那决策模型到底买到了什么？两样聊天路线给不了的东西。第一，校准概率：tev1 4B 零路由错误，0.8B 的四个错误全部低于 0.77，Nimble 唯一的错误是 0.83——「低于 0.9 转人工」是一条真的能跑的规则。第二，一致性：同一张工单，聊天模型 8 次里 7 次答 billing、1 次答 tech support，而且对自己的置信度只字不提。

    计时卡片对比：强制 JSON schema 的 Qwen 3.5 4B 聊天模型 268ms，对比 tev1 4B 470ms 与 nimble 9B 1.5s，注记「精度打平、聊天更快」
    精度打平、聊天更快；置信度与一致性——Jev 系赢。跳转至 6:52
  11. 11

    置信度对上真值：门控才真正成立

    收尾的散点图把 30 工单测试里的每个答案画成「置信度 vs 对错」。让自动化变安全的模式清晰可见：tev1 4B 的错误答案根本不存在，Nimble 唯一的失手停在 0.83，0.8B 的错误全部聚在 0.77 以下。错误都活在低置信区，0.9 这样的阈值就能把拿不准的案例转给人工、同时几乎不牺牲正确答案——和托管 Jev API 卖的是同一个置信度门控模式，只是这次它跑在你应用旁边。

    30 工单答案的置信度对错散点图：红色错误答案全部聚在 0.9 转人工线以下
    错误都住在 0.9 以下——阈值这才称得上诚实。跳转至 7:00
  12. 12

    坑位清单：实验标签与 30 张工单的视野

    结论页分得很干净。好的：本地、免费、无 API key、几百毫秒出答案、概率可以直接拿来门控、单次 64 问。坑：请求格式挑剔、Nimble 挤不进 8GB 卡、tev1 系列挂着实验标签——官方页面明说它们可能出错。他自己的收尾方式值得照抄：30 张工单是个好开头，不是证明。在任何自动执行之前，用你自己标注的数据做验证，并始终给阈值以下留一条人工复核通道。

    警告卡片：不要让它成为唯一的检查——官方页面注明可能出错、置信度低于 0.9 应转人工
    好开头，不是证明——实验标签在做实事。跳转至 7:38

常见问题（FAQ）

Ollama 的决策模型 tev1 和 Nimble 是什么？

两个经 Ollama 0.35 的 /v1/systemone 端点提供的 Jev 系决策模型族。tev1 来自 Together AI，有 4B（4.5GB）和 0.8B（811MB）两个尺寸，都以 Qwen 3.5 为底座续训；Nimble 是 Bespoke Labs 的 9B 模型（Apache 2.0，下载 7.5GB、加载约 10GB）。TypeSafe 公布的公开基准：tev1 4B 拿 73.3%、Nimble 拿 75.7%；视频的 30 工单自测里 tev1 4B 团队路由 100%、Nimble 96.7%。

Ollama System One 端点怎么调才不会报错？

POST 到 http://localhost:11434/v1/systemone，JSON 体含 model、state（你的文本）和 questions。视频里用三次报错换来的三条规则：每个问题必须有非空 instructions 字符串；choice 问题的 criteria 是「选项 key → 描述」的 map；score 问题的 criteria 是描述数组。单次请求最多 64 个问题，答案带每个选项的概率一次返回。

8GB 显卡该跑哪个模型？

tev1 4B。它在视频的 30 工单路由测试里拿到 100%、470ms，且完整装进 4.7GB 显存。Nimble 9B 愤怒检测更准（96.7%），但加载约 10GB、约 40% 计算溢出到 CPU、单次 1.5 秒——给它 12GB 以上再考虑。0.8B（811MB、235ms）留给显存紧张的机器，代价是实打实的精度下滑（86.7%）。另外：加载下一个大模型前先卸载上一个，可以避开 host 侧 CUDA 500。

强制 JSON 的聊天模型精度都打平了，为什么还要决策模型？

因为精度不是契约的全部。视频里 Qwen 3.5 4B 强制 JSON schema 后拿到同样的 96.7/96.7，速度还更快（268ms）。但它给不了两样东西：校准置信度（决策模型的错误全部低于 0.9，阈值能兜住；聊天模型没有任何等价物）和一致性（同一张工单 8 次里 7 次答 billing、1 次答 tech support）。如果你只需要一个答案、且能容忍无声翻转，schema 约束生成够用；如果你要对着一个数字做自动化，就需要校准概率。完整的契约对比见我们的 Jev vs JSON mode recipe。

这些模型能上生产吗？

按实验品对待。官方 tev1 页面写明模型可能出错，视频收尾也自嘲「30 张工单是个好开头，不是证明」。视频给出的诚实模式：从自己的误报出发定阈值（那句被打 0.66 的友好消息就是标准案例）、低于约 0.9 一律转人工、在任何自动执行之前先用自己业务的标注数据做验证。

这和托管 Jev API 有什么区别？

交互形状一样——state 加类型化问题进、答案加概率出——但算力是你自己的：无 API key、无按 token 计费、数据不出机器，消费级硬件上几百毫秒延迟。托管 Jev API 仍是零运维选项，校准过的 RLCD 概率和更高的精度上限都在那边；本地路线用一些精度换成本、隐私和延迟控制。云与本地的取舍在我们的 Jev vs Ollama 指南里有完整对比。

相关推荐

Jev vs Ollama：本地与云端的类型化决策

这期视频用数字量化的那个决策框架——本地路线什么时候赢过托管 API，什么时候赢不了。

阅读

Jev vs JSON Mode：零重试类型化决策

第 10 步对照实验背后的完整契约对比：重试税、输出计费、校准 vs schema 约束生成。

阅读

本地跑 Jev 系模型

在自己的硬件上伺服 Kev、SemIf、Von——Ollama 路线之外的手动安装版。

阅读

训练你自己的 Jev：微调路线

tev1 本身就是续训过的 Qwen 3.5——想自己造一个，这是「标注到阈值」的全流程。

阅读

更多视频攻略