最近社区讨论度最高的决策模型，除了 Jev 估计没有第二个了。我从它刚放出 demo 就开始跟进，说实话一开始只是带着好奇心去试，结果发现在技术选型、发布风险评估这类需要"给结论还要给理由"的场景里，它确实比我预想的要稳。但 Jev 是闭源模型，API 有配额、有延迟，还有数据出境的问题，想嵌进我们自己的内部工作流里，始终隔着一层。所以我花了两三个月时间，基于开源基座做了一版对标的决策模型，取名 NeoHorse-Jev-4B，权重和推理代码都放到公开仓库了。这篇文章不打算讲一堆文档里已经有的东西，主要想把自己踩过的坑、调过的参数、以及怎么在 Windows 上跑起来并接进 Codex 工作流的完整过程分享一遍，给同样在考虑本地化部署决策模型的朋友做个参照。

先讲结论：如果你只有一块普通显卡，想本地跑一个能出决策结论的模型，NeoHorse-Jev-4B 是个可以真正拿来用的选择；但如果你指着它在任何场景下完全取代 Jev，那还差一点火候。差距在哪、为什么差、怎么补，下面按我的实现顺序展开。

1. 为什么要做一个"开源版 Jev"

1.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 训练细节与收敛情况

训练配置不算复杂，但有几个细节值得记录：

SFT 阶段的损失在 1.5 个 epoch 之后降到 0.4 左右就不再明显下降，继续加轮次反而出现轻微过拟合。DPO 阶段主要做偏好对齐，把那些"结论正确但推理链太简略"的输出当作负样本，偏好准确率最后稳定在 78% 上下。

一个经验：决策模型的输出温度必须低。训练完成后我自己贪新鲜把 temperature 调到了 0.7，同一道题跑三次，三次结论都不一样。后来统一用 0.1，稳定性才上来。决策不是创作，不需要随机性，需要的是可复现的判断。

3. 本地部署全流程和 Windows 避坑

3.1 环境准备

训练在 Linux 上完成，但真正部署时大家的机器五花八门，尤其是 Windows 环境让我费了不少功夫。先说推荐环境：

显存方面，FP16 加载大约占 8.5GB，INT4 量化后约 4.2GB。有 8G 显存的卡建议直接上量化版，没有独立显卡就只能走 CPU 推理。

3.2 跑通第一次推理

加载和推理代码很简单：

from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained( "NeoHorse/NeoHorse-Jev-4B", torch_dtype="float16", device_map="auto" ) tokenizer = AutoTokenizer.from_pretrained("NeoHorse/NeoHorse-Jev-4B") prompt = """决策任务： 场景：线上服务出现延迟告警，疑似数据库连接池耗尽。 约束：不能重启数据库；需要优先恢复可用性。 候选方案： A. 直接扩容数据库连接池 B. 重启应用服务 C. 切换只读流量到从库 请严格按 JSON 格式输出决策结果。""" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") out = model.generate(**inputs, max_new_tokens=1024, temperature=0.1) print(tokenizer.decode(out[0], skip_special_tokens=True))

第一次跑通大概花了半天时间，主要浪费在环境依赖冲突上。这东西卡住的时候，查日志比瞎试有用得多。

3.3 Windows 部署的几个大坑

Windows 部署确实比 Linux 麻烦，我踩过的坑列成表格：

最难查的是第二个。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(title="NeoHorse 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_model=DecisionResponse) 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 上简单压过：

4 并发以内基本无感，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 接口做了同期对比：

整体对齐到 Jev 的 86% 左右。差距最明显的在推理链完整度——Jev 给出的推理链更长、更有层次，我们的模型有时会省掉中间一步推导。但在中文业务场景上，因为我们的训练数据中中文决策样本占比高，反而略有优势。

6.3 已知短板

有三个问题我目前还没解掉。

一是多目标冲突决策弱。当约束条件超过五个，而且互相牵制的时候——比如"成本要降、时间要快、质量不能打折扣、合规不能碰、团队资源还不够"——模型容易顾此失彼，给出的结论会忽略某个约束。这个在约束数少的场景里不太出现，一旦复杂就露馅。

二是长上下文利用率一般。虽然支持 32K 上下文，但当真塞进很长的场景描述和 20 个以上候选方案时，模型倾向于关注前面的选项，后面的容易被忽略。这也是小模型的通病。

三是缺乏事后反思机制。模型没有记忆，同样的错误场景换个时间问，它还是会用同样的方式错。要让决策模型真正进化，需要外部系统把历史反馈也作为输入的一部分喂进去，但这个改造工作量不小，目前还没做。

6.4 下一步计划

接下来几个方向，按优先级排：先把评测集完整开源，让大家能复现基准；然后试试 GRPO 做强化学习对齐，看能不能把推理链完整度补上来；再就是扩展决策输出的字段，打算在现有 JSON 结构里加上"由谁决策""何时复核""成本估算区间"这些更细的字段，让决策结果更可执行。

最后说一个我个人的体会，算是给想做类似项目的人一个预警：千万别把决策模型当成万能钥匙。它适合的场景是"约束明确、选项有限、需要快速给结论"的决策。一旦你的场景里存在大量没说出口的隐性规则——比如团队政治、历史包袱、产品方向没对齐——模型再强也给不了正确答案，这时候最优先要做的不是换更大的模型，而是把隐性信息显式写进 constraints 里。NeoHorse-Jev-4B 的权重和代码我都放在公开仓库里了，熟悉这套流程的朋友可以拉下去跑一跑，不管是提 issue 还是直接贡献训练样本，都欢迎。这个方向离天花板还远，值得一起折腾。