★ FEATURED ARTICLE 最近社区讨论度最高的决策模型除了 Jev 估计没有第二个了。我从它刚放出 demo 就开始跟进说实话一开始只是带着好奇心去试结果发现在技术选型、发布风险评估这类需要给结论还要给理由的场景里它确实比我预想的要稳。但 Jev 是闭源模型API 有配额、有延迟还有数据出境的问题想嵌进我们自己的内部工作流里始终隔着一层。所以我花了两三个月时间基于开源基座做了一版对标的决策模型取名 NeoHorse-Jev-4B权重和推理代码都放到公开仓库了。这篇文章不打算讲一堆文档里已经有的东西主要想把自己踩过的坑、调过的参数、以及怎么在 Windows 上跑起来并接进 Codex 工作流的完整过程分享一遍给同样在考虑本地化部署决策模型的朋友做个参照。先讲结论如果你只有一块普通显卡想本地跑一个能出决策结论的模型NeoHorse-Jev-4B 是个可以真正拿来用的选择但如果你指着它在任何场景下完全取代 Jev那还差一点火候。差距在哪、为什么差、怎么补下面按我的实现顺序展开。1. 为什么要做一个开源版 Jev1.1 Jev 解决的到底是什么问题很多人第一次接触 Jev 都会问它和 ChatGPT 这类通用大模型的区别是什么我自己用下来的体会是——通用模型擅长的是陪聊式问答你问它一个方案行不行它能说得天花乱坠但换个说法问一遍它可能给你另一个相反的结论。这种不稳定性在聊天场景无所谓但在决策场景就是致命的。Jev 这类决策模型把输入输出都做了结构化改造。输入是场景描述 约束条件 候选方案输出是推荐决策 置信度 推理链 风险清单。换句话说它把一个开放的、你怎么看的问题变成了一个可控的、综合考虑这些因素后选哪个的推理问题。这才是它在社区里被广泛讨论的根本原因——它设计出来就不是为了陪你聊天而是为了给下游系统一个可以信任的结论。我们内部用它的典型场景有三个技术选型、发布策略、值班处置。举个例子线上服务告警值班同学以前要翻 runbook、找架构师现在直接把告警文本和备选处置方案扔给模型它给出建议的恢复操作和风险提示值班同学拿着结论去对照执行。这个流程以前走下来要十几分钟现在几十秒就完成第一轮判断了。1.2 闭源模型用起来的三个坎Jev 很好用但我们在试点过程中撞上了三堵墙这也是我决定动手做开源版的直接原因。第一是 API 配额和限流。我们内部每天决策请求量不算高但集中批量压测的时候一会儿一个 429一会儿一个超时。想加大并发就得升级套餐成本直接跟着用量线性涨。第二是数据合规。决策模型处理的是业务数据技术选型涉及成本信息发布策略涉及业务敏感度值班处置甚至涉及事故细节。这些东西过公网 API哪怕只是传个文本法务那一关就过不去。第三是不可定制。闭源模型给不了你 prompt 模板的修改权更别提微调。我们想注入一些内部规范比如任何涉及数据删除的操作必须二次确认只能靠往输入里拼 prompt结果时灵时不灵。这三条里任何一条都决定了它只能被当成一个外部 API 依赖而不是可以被当成基础设施来用的组件。所以我才动了念头做一个开源的、参数规模相近的决策模型把权重、代码、数据构造方案全公开。1.3 目标不是复刻是对齐我在项目立项时给自己定的目标非常明确不追求 1:1 复刻 Jev而是把决策质量对齐到可用线以上——具体就是结论可用性 85% 以上、推理链完整、输出格式稳定、可以在本地部署。NeoHorse 是我们团队名字Jev-4B 代表对标 Jev、4B 参数规模。4B 参数这个选择是权衡过的。再小的模型决策能力明显不够再大的模型部署成本就上来了。4B 在 FP16 精度下占 8.5GB 显存INT4 量化后压到 4.2GB 左右一张消费级显卡就能跑恰好卡在能用和好用的平衡点上。2. 模型本身4B 参数如何撑起决策能力2.1 基座为什么选 Qwen2.5-4B基座模型选了 Qwen2.5-4B-Instruct理由有三个。它的中文指令跟随能力在这个量级里是数一数二的。我们的大部分决策场景是中文文本Jev 在中英混合输入下偶尔会词不达意但 Qwen 系模型对中文的理解要稳得多。其次4B 这个规模在推理成本上优势明显决策任务追求的是快速给结论不是长篇大论。第三是许可友好可以做商用二次开发。有人说怎么不用更大的模型当基座我实际对比过 8B 级别的基座决策质量确实略高但显存占用、推理延迟、部署复杂度都上来了不符合本地化决策这个初衷。决策模型拼的不是知识量而是结构化推理能力这个用 4B 微调完全可以解决。2.2 数据构造是真正花时间的地方整个项目里最耗时间的不是训练是数据。我最后建了 120 万条决策样本每一条都是这样的三元组场景描述、约束条件、候选方案列表以及对应的结构化答案。数据来源分三块。第一块是公开数据集的筛选和清洗把那些带明确决策性质的问答抽出来转成统一格式。第二块是规则模板生成我写了一套决策场景模板自动生成上线时间紧急程度团队人手历史债务这类约束的不同组合。第三块是教师模型迁移用能力更强的大模型当教师把合成场景喂进去让它产出带完整推理链的答案然后再清洗一遍。举个例子合成样本长这样场景产品需要快速上线 A/B 测试框架但研发团队只有 3 人。约束2 周内上线不能引入额外基础设施前端改动尽量少。候选方案自研 SDK、集成第三方 SDK、先用旧方案不做。教师模型会输出一段推理——为什么在人力紧张的情况下优先考虑集成第三方 SDK、自研的什么条件下才值得、旧方案的风险在哪。然后我把这段推理整理成结构化 JSON 存进训练集。人工校正了 5000 条高难度样本主要处理那些模棱两可的边界情况。比如两个方案各有利弊、没有明显最优解的场景我会反复讨论后给出一个带倾向性的答案并写清楚这个倾向成立的前提条件。这些样本对最终模型的质量影响非常大。2.3 输出格式让模型学会先想后说输出格式是我花最多心思设计的一环。模型被要求输出一段固定结构的 JSON{ decision: 推荐采用方案 B集成第三方 SDK, confidence: 0.82, reasoning: [ 研发团队仅 3 人2 周内自研 SDK 风险过高, 第三方 SDK 成熟度高能满足 A/B 测试核心需求, 引入成本可控未违反基础设施约束 ], risks: [ 第三方 SDK 功能可能不完全匹配后续需要二次开发, 上线后需要监控 SDK 稳定性 ], alternative: 如果 A/B 测试需求在未来半年内持续高频可考虑自研 }为什么不直接输出自然语言因为在 agent 工作流里自然语言给机器解析非常容易出错。JSON 格式让决策结果可以被下游系统直接消费agent 拿到这个对象就能决定下一步动作。训练时我要求模型在输出 JSON 之前内部先经过推理过程通过训练让思考内化到生成 JSON 的隐空间中——效果上观察模型确实学会了在有限输出长度内压缩推理链。2.4 训练细节与收敛情况训练配置不算复杂但有几个细节值得记录配置项数值基座模型Qwen2.5-4B-Instruct微调方法LoRArank64, alpha128 DPOSFT 轮数3 epochDPO 轮数1 epoch学习率SFT 5e-5DPO 2e-5批大小128上下文长度32768SFT 阶段的损失在 1.5 个 epoch 之后降到 0.4 左右就不再明显下降继续加轮次反而出现轻微过拟合。DPO 阶段主要做偏好对齐把那些结论正确但推理链太简略的输出当作负样本偏好准确率最后稳定在 78% 上下。一个经验决策模型的输出温度必须低。训练完成后我自己贪新鲜把 temperature 调到了 0.7同一道题跑三次三次结论都不一样。后来统一用 0.1稳定性才上来。决策不是创作不需要随机性需要的是可复现的判断。3. 本地部署全流程和 Windows 避坑3.1 环境准备训练在 Linux 上完成但真正部署时大家的机器五花八门尤其是 Windows 环境让我费了不少功夫。先说推荐环境组件推荐版本Python3.10CUDA12.1 或 12.2PyTorch2.1.2transformers4.40.0accelerate0.29.0vLLM0.4.2Linux 生产推荐llama.cpp最新Windows CPU 方案显存方面FP16 加载大约占 8.5GBINT4 量化后约 4.2GB。有 8G 显存的卡建议直接上量化版没有独立显卡就只能走 CPU 推理。3.2 跑通第一次推理加载和推理代码很简单from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained( NeoHorse/NeoHorse-Jev-4B, torch_dtypefloat16, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(NeoHorse/NeoHorse-Jev-4B) prompt 决策任务 场景线上服务出现延迟告警疑似数据库连接池耗尽。 约束不能重启数据库需要优先恢复可用性。 候选方案 A. 直接扩容数据库连接池 B. 重启应用服务 C. 切换只读流量到从库 请严格按 JSON 格式输出决策结果。 inputs tokenizer(prompt, return_tensorspt).to(cuda) out model.generate(**inputs, max_new_tokens1024, temperature0.1) print(tokenizer.decode(out[0], skip_special_tokensTrue))第一次跑通大概花了半天时间主要浪费在环境依赖冲突上。这东西卡住的时候查日志比瞎试有用得多。3.3 Windows 部署的几个大坑Windows 部署确实比 Linux 麻烦我踩过的坑列成表格问题现象解决方案路径含中文或空格模型加载报路径错误找不到权重文件统一放到纯英文无空格路径例如D:\Models\NeoHorsebitsandbytes 不支持 Windows4bit 量化加载直接报错放弃 bitsandbytes改用 GGUF llama.cpp默认缓存目录在 C 盘模型下载几次后 C 盘空间爆满设置环境变量HF_HOMED:\hf_cache中文 JSON 输出乱码打印结果出现乱码设置PYTHONUTF81后再启动服务显卡驱动太老torch 报 CUDA not available只更新 GPU 驱动即可不必重装 CUDA toolkit最难查的是第二个。bitsandbytes 库在 Linux 上是标配但它在 Windows 下的支持一直有问题。我一开始反复换版本最后直接放弃这条路转用 llama.cpp 加载 GGUF 量化版反而一次就通了。在 Windows 上跑大模型的思路就得跟着生态走别硬刚。3.4 CPU 推理方案如果你的 Windows 机器没有 NVIDIA 显卡也不用灰心。llama.cpp 支持得很好把权重转成 GGUF 的 Q4_K_M 量化版本后可以直接命令行跑llama-cli -m models/NeoHorse-Jev-4B-Q4_K_M.gguf ^ -p 决策任务... -n 512 --temp 0.1实测在一台 7840U 的笔记本上大约每秒 3 到 5 个 token一条完整的决策建议大概要一分钟到两分钟。如果每天只有几十次低频决策请求这个速度完全能接受。但要是高频调用还是建议配一块显卡。4. 把模型接进 Codex决策模型怎么真正干活4.1 为什么要单开一个决策层Codex 这类 agent 工作流框架擅长的是检索代码、改文件、跑测试这些执行类任务。但遇到真正需要下判断的节点——比如两套重构方案选哪套、发布遇到阻塞是回滚还是继续等——通用 agent 就有点飘经常给出的理由前后矛盾。我们后来的做法是把 NeoHorse-Jev-4B 作为一个独立工具暴露给 Codex让它负责决策这个环节Codex agent 负责执行。这叫决策层与执行层分离。通用模型当执行器专用决策模型当裁判。分工之后整体流程的可控性明显提升了——决策结果有了固定的 JSON 结构Codex 拿到什么字段就做什么动作不会再因为模型心情不同而改变策略。4.2 以 API 方式接入接入方式不复杂先在本地起一个 FastAPI 服务具体代码见第 5 节然后在 Codex 的工具声明里把它注册成一个 function{ type: function, function: { name: decision_engine, description: 调用 NeoHorse-Jev-4B 输出结构化决策结果, parameters: { type: object, properties: { scenario: {type: string, description: 场景描述}, constraints: {type: string, description: 约束条件}, options: {type: array, items: {type: string}, description: 候选方案列表} }, required: [scenario, constraints, options] } } }之后 Codex 在执行过程中一旦遇到需要做选择的任务就会自动把场景和选项整理成参数发起 HTTP 请求到我本地的决策服务拿到 JSON 返回值再根据decision字段继续执行。整个过程对 agent 来说是透明的它只看到一个工具被调用了。4.3 一个完整实测例子重构方案选型拿我们真实发生过的一个场景来看。当时需要重构一个老模块我让 Codex 起草重构方案到了选型环节它调用 decision_engine输入大概是场景老模块代码耦合度高现有测试覆盖率不足 40%。约束重构期间不能停服超过 4 小时团队只有 2 名后端开发Q3 结束时必须上线。候选方案渐进式重构、完全重写、保持现状只做局部优化。NeoHorse-Jev-4B 返回的结果是{ decision: 渐进式重构, confidence: 0.74, reasoning: [ 完全重写风险太高覆盖率不足的情况下无法验证等价性, 渐进式重构可以把拆分后的每个模块独立验证, 约束中 4 小时停服上限对渐进式重构影响最小 ], risks: [ 重构周期可能超出 Q3 截止时间需要设定每两周一个里程碑, 局部优化在人力不足时可以快速交付但无法解决核心耦合问题 ], alternative: 若团队能增加一名前端支援可考虑完全重写 }同一场景我也用 Jev 跑过一次。Jev 的结论也是渐进式重构置信度给到 0.81推理链更完整但 risk 只提了一条重构周期可能超出截止时间。NeoHorse 在风险覆盖上反而更细这是中文训练样本多带来的一个优势。两个模型的结论方向一致差别在细节的颗粒度上。这个决策模型出结论 agent 执行的组合我们内测跑了三周决策引擎实际被调用 400 多次处理了技术选型、发布判断、告警处置各类任务。最大的收益不是速度快而是每次决策都有日志事后复盘可以直接看模型当时为什么做了这个选择。5. API 化封装和性能调优5.1 FastAPI 服务骨架接入 Codex 之后模型就从一个 Python 脚本变成了一个需要长期稳定运行的服务。我用 FastAPI 做了简单封装from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleNeoHorse Decision API) class DecisionRequest(BaseModel): scenario: str constraints: str options: list[str] class DecisionResponse(BaseModel): decision: str confidence: float reasoning: list[str] risks: list[str] alternative: str app.post(/decision, response_modelDecisionResponse) def decision_endpoint(req: DecisionRequest): return run_neohorse_decision(req.scenario, req.constraints, req.options)里面run_neohorse_decision就是拼接 prompt、调用模型、解析 JSON 输出的函数。解析 JSON 这一步很容易出问题模型偶尔会输出带多余前后缀的 JSON我在解析函数里做了容错处理先尝试直接 json.loads失败就截取第一个{到最后一个}之间的内容再试。5.2 并发和显存调优如果只在 Windows 本地用上面的服务加块显卡就够了。但要是放在 Linux 生产环境、多团队共用建议直接换 vLLM 做推理框架吞吐会好看很多。vLLM 的启动参数我调过几轮最终用的是python -m vllm.entrypoints.openai.api_server \ --model NeoHorse/NeoHorse-Jev-4B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768 \ --port 8000并发和延迟的关系我在一台 A10 24G 上简单压过并发数平均延迟显存占用1780ms8.5GB4850ms8.8GB81.1s9.4GB161.6s10.2GB4 并发以内基本无感8 并发开始有明显排队16 并发延迟接近翻倍。对决策场景来说单机 8 并发是合理的使用上限超过这个量就该起多副本了。5.3 稳定性的三个细节跑了一段时间之后我加了三个稳定性措施都花的功夫不大但收益明显。第一个是输出格式校验失败时重试。模型偶尔会输出残缺 JSON我设置了解析失败自动重试最多重试两次重试时把 temperature 收到 0.05基本能解决。第二个是请求缓存。决策场景里相同或相似的请求经常出现我在 API 层加了 LRU 缓存相同输入在 5 分钟内直接返回上一次结果省了一次推理。实测缓存命中率有 15% 左右不算高但聊胜于无。第三个是完整日志。每个请求我都会记录输入摘要、模型输出、响应耗时。这些日志在事后分析为什么模型当时给了这个建议时价值极大。决策模型最怕的不是答错是答错了你不知道为什么。6. 实测结果、已知短板和后续计划6.1 评测集怎么设计的为了不显得自说自话我拉了一个 2000 条的评测集覆盖四类场景技术选型 500 条、发布与运维处置 500 条、成本决策 400 条、产品策略 600 条。每条样本都有人工标注的参考答案和理由用三个维度打分结论可用性1-5 分、推理链完整性1-5 分、JSON 格式合法率百分比。这个评测集本身还在打磨有些边界样本标注可能有主观性但整体上能反映模型在真实业务决策场景里的能力。6.2 与 Jev 的对比结果跑完评测拿公开的 Jev 接口做了同期对比评测项JevNeoHorse-Jev-4B结论可用性4分以上占比91.6%87.2%推理链完整度平均分4.314.08JSON 格式合法率97.8%95.4%单次决策平均延迟1200msAPI780ms本地中文业务场景可用性86%89%整体对齐到 Jev 的 86% 左右。差距最明显的在推理链完整度——Jev 给出的推理链更长、更有层次我们的模型有时会省掉中间一步推导。但在中文业务场景上因为我们的训练数据中中文决策样本占比高反而略有优势。6.3 已知短板有三个问题我目前还没解掉。一是多目标冲突决策弱。当约束条件超过五个而且互相牵制的时候——比如成本要降、时间要快、质量不能打折扣、合规不能碰、团队资源还不够——模型容易顾此失彼给出的结论会忽略某个约束。这个在约束数少的场景里不太出现一旦复杂就露馅。二是长上下文利用率一般。虽然支持 32K 上下文但当真塞进很长的场景描述和 20 个以上候选方案时模型倾向于关注前面的选项后面的容易被忽略。这也是小模型的通病。三是缺乏事后反思机制。模型没有记忆同样的错误场景换个时间问它还是会用同样的方式错。要让决策模型真正进化需要外部系统把历史反馈也作为输入的一部分喂进去但这个改造工作量不小目前还没做。6.4 下一步计划接下来几个方向按优先级排先把评测集完整开源让大家能复现基准然后试试 GRPO 做强化学习对齐看能不能把推理链完整度补上来再就是扩展决策输出的字段打算在现有 JSON 结构里加上由谁决策何时复核成本估算区间这些更细的字段让决策结果更可执行。最后说一个我个人的体会算是给想做类似项目的人一个预警千万别把决策模型当成万能钥匙。它适合的场景是约束明确、选项有限、需要快速给结论的决策。一旦你的场景里存在大量没说出口的隐性规则——比如团队政治、历史包袱、产品方向没对齐——模型再强也给不了正确答案这时候最优先要做的不是换更大的模型而是把隐性信息显式写进 constraints 里。NeoHorse-Jev-4B 的权重和代码我都放在公开仓库里了熟悉这套流程的朋友可以拉下去跑一跑不管是提 issue 还是直接贡献训练样本都欢迎。这个方向离天花板还远值得一起折腾。
阅读完成 · 觉得有帮助？
