gump2049 commited on
Commit
0bcf299
·
verified ·
1 Parent(s): 20523e7

Highlight compute-aware architecture and organize technical details

Browse files
Files changed (4) hide show
  1. README.md +15 -13
  2. README.zh-CN.md +15 -13
  3. TECHNICAL_REPORT.md +1 -1
  4. bundle-manifest.json +6 -6
README.md CHANGED
@@ -31,7 +31,9 @@ tags:
31
 
32
  We introduce **APUS-OpenJev-v1**, a family of decision models for browser agents and business workflows. Given a task, context, and candidate actions, the model returns a scored choice that an application can execute. The family provides 4B and 9B variants with a common decision interface.
33
 
34
- **Architecture.** A shared language-model backbone supports multiple compute budgets. Task definitions and candidate meanings arrive through natural language, allowing the same model to handle different decision spaces. Applications select `effort="low"` or `effort="high"` through the included runtime.
 
 
35
 
36
  **Joint post-training.** Decision learning is coordinated across computation depths. Both execution paths learn from reference decisions, while the complete path supplies a distribution-level learning signal for the shorter path. This trains useful early decisions rather than relying on an untrained intermediate representation. The [architecture guide](ARCHITECTURE.md) explains the design and its trade-offs.
37
 
@@ -103,18 +105,6 @@ Select `effort="high"` for decision quality or `effort="low"` for a smaller comp
103
 
104
  The separate **9B · effort: high · vLLM HTTP API** reference reports **25.58 / 222.36 / 275.58 ms** P50/P95/P99 on **one RTX PRO 6000 Blackwell 96GB GPU**. These are complete HTTP responses. The published standard vLLM launcher runs the full-depth model; the figure does not imply that it exposes a low-effort HTTP route. [Measurement sources](effort-tradeoff-data.json).
105
 
106
- ### Candidate-aware output projection
107
-
108
- Compute depth and output width address two different costs. The native low-effort path combines an earlier exit with **candidate-row projection**: it selects the language output weights for the request's candidate labels before computing their scores. This retains the shared language output space while avoiding scores for unrelated vocabulary entries in that path.
109
-
110
- | Execution path | Output-head computation |
111
- | --- | --- |
112
- | Native `effort="low"` | Candidate rows first; full-head fallback for unsupported output heads |
113
- | Native `effort="high"` | Full vocabulary, then candidate selection |
114
- | Current vLLM decision / Chat service | Full vocabulary; decision gateway extracts candidate scores afterward |
115
-
116
- The optimization reduces output-head work, not the context-processing backbone. Current vLLM latency results do not include candidate-only output-head execution. See the [Technical Report](TECHNICAL_REPORT.md#6-performance-where-the-savings-can-come-from) for the mechanism and execution boundaries.
117
-
118
  ## 3. Evaluation Set
119
 
120
  ![Frozen80 composition: five task families with 16 questions each, 80 questions and 79 parent groups in total.](assets/dataset-subsets.svg)
@@ -139,6 +129,18 @@ A request carries the task, supporting context, and 2–16 candidate description
139
 
140
  A legal output can still be the wrong decision. Candidate probabilities are not calibrated confidence, and business thresholds require validation. See the [runtime contract](9B-3000/RUNTIME.md) for the supported request format.
141
 
 
 
 
 
 
 
 
 
 
 
 
 
142
  ## 5. Minimal Inference
143
 
144
  The repository is a model-family bundle. Choose a subdirectory containing complete BF16 weights and the reference runtime:
 
31
 
32
  We introduce **APUS-OpenJev-v1**, a family of decision models for browser agents and business workflows. Given a task, context, and candidate actions, the model returns a scored choice that an application can execute. The family provides 4B and 9B variants with a common decision interface.
33
 
34
+ **Language-native decisions.** Task definitions and candidate meanings arrive through natural language, allowing one shared model to handle changing decision spaces without a separate business-category classifier.
35
+
36
+ **Compute matched to the decision.** The architecture combines selectable execution depth with [candidate-aware output projection](#candidate-aware-output-projection). Applications choose `effort="low"` or `effort="high"`; the native low path pairs an earlier trained exit with a readout that computes scores only for the supplied candidate labels on supported output heads. This reduces both executed depth and unnecessary output-head work while retaining the model's shared language output space.
37
 
38
  **Joint post-training.** Decision learning is coordinated across computation depths. Both execution paths learn from reference decisions, while the complete path supplies a distribution-level learning signal for the shorter path. This trains useful early decisions rather than relying on an untrained intermediate representation. The [architecture guide](ARCHITECTURE.md) explains the design and its trade-offs.
39
 
 
105
 
106
  The separate **9B · effort: high · vLLM HTTP API** reference reports **25.58 / 222.36 / 275.58 ms** P50/P95/P99 on **one RTX PRO 6000 Blackwell 96GB GPU**. These are complete HTTP responses. The published standard vLLM launcher runs the full-depth model; the figure does not imply that it exposes a low-effort HTTP route. [Measurement sources](effort-tradeoff-data.json).
107
 
 
 
 
 
 
 
 
 
 
 
 
 
108
  ## 3. Evaluation Set
109
 
110
  ![Frozen80 composition: five task families with 16 questions each, 80 questions and 79 parent groups in total.](assets/dataset-subsets.svg)
 
129
 
130
  A legal output can still be the wrong decision. Candidate probabilities are not calibrated confidence, and business thresholds require validation. See the [runtime contract](9B-3000/RUNTIME.md) for the supported request format.
131
 
132
+ ### Candidate-aware output projection
133
+
134
+ Compute depth and output width address two different costs. The native low-effort path combines an earlier exit with **candidate-row projection**: it selects the language output weights for the request's candidate labels before computing their scores. This retains the shared language output space while avoiding scores for unrelated vocabulary entries in that path.
135
+
136
+ | Execution path | Output-head computation |
137
+ | --- | --- |
138
+ | Native `effort="low"` | Candidate rows first; full-head fallback for unsupported output heads |
139
+ | Native `effort="high"` | Full vocabulary, then candidate selection |
140
+ | Current vLLM decision / Chat service | Full vocabulary; decision gateway extracts candidate scores afterward |
141
+
142
+ The optimization reduces output-head work, not the context-processing backbone. Current vLLM latency results do not include candidate-only output-head execution. See the [Technical Report](TECHNICAL_REPORT.md#6-performance-where-the-savings-can-come-from) for the mechanism and execution boundaries.
143
+
144
  ## 5. Minimal Inference
145
 
146
  The repository is a model-family bundle. Choose a subdirectory containing complete BF16 weights and the reference runtime:
README.zh-CN.md CHANGED
@@ -33,7 +33,9 @@ tags:
33
 
34
  **APUS-OpenJev-v1** 是一个决策模型系列,面向浏览器智能体和业务工作流。输入任务、上下文和候选动作后,模型返回带有评分的选择,供应用执行。该系列提供4B和9B版本,采用统一的决策接口。
35
 
36
- **架构。** 同一个语言模型骨干支持多种计算预算。任务定义和候选项的含义通过自然语言输入,使同一模型能够处理不同的决策空间。应用通过附带的runtime选择`effort="low"`或`effort="high"`。
 
 
37
 
38
  **联合后训练。** 不同计算深度下的决策学习共同进行。两条执行路径都从参考答案中学习,完整路径还通过候选概率分布为较短路径提供学习信号。这样,较早的决策出口经过任务训练,而不是直接依赖未经训练的中间表示。[架构指南](ARCHITECTURE.md)进一步介绍了这一设计及其取舍。
39
 
@@ -103,18 +105,6 @@ tags:
103
 
104
  独立的 **9B · effort: high · vLLM HTTP API**参考:P50/P95/P99为 **25.58 / 222.36 / 275.58 ms**,硬件为 **单张RTX PRO 6000 Blackwell 96GB GPU**,计时包含完整HTTP响应。标准vLLM启动脚本运行完整深度模型;本图不表示脚本已经提供low-effort HTTP路由。[测量来源](effort-tradeoff-data.json)。
105
 
106
- ### 候选感知输出投影
107
-
108
- 计算深度和输出宽度分别影响两部分成本。原生 low 路径在较浅出口读取特征,并先取出本次候选标签对应的语言输出权重,再计算分数。它沿用模型的语言输出空间,省去该路径中无关词表项的输出头计算。
109
-
110
- | 执行路径 | 输出头计算 |
111
- | --- | --- |
112
- | 原生 `effort="low"` | 先取候选权重行再投影;不支持的输出头回退完整计算 |
113
- | 原生 `effort="high"` | 计算全词表,再选择候选 |
114
- | 当前 vLLM 决策/Chat 服务 | 计算全词表;决策网关随后提取候选分数 |
115
-
116
- 这一优化减少的是输出头工作,不省略上下文骨干计算;当前 vLLM 延迟结果尚不包含候选专用输出头的收益。机制和执行范围见[技术报告](TECHNICAL_REPORT.md#6-performance-where-the-savings-can-come-from)。
117
-
118
  ## 3. 评测集
119
 
120
  ![Frozen80数据构成:五类任务各16题,共80题、79个父组。](assets/dataset-subsets.svg)
@@ -139,6 +129,18 @@ tags:
139
 
140
  合法输出仍可能是错误决策。候选概率不是经过校准的置信度,业务阈值需要验证。支持的请求格式见[runtime接口约定](9B-3000/RUNTIME.md)。
141
 
 
 
 
 
 
 
 
 
 
 
 
 
142
  ## 5. 最小推理示例
143
 
144
  本仓库集中保存一个模型系列。请选择包含完整BF16权重和参考runtime的具体子目录:
 
33
 
34
  **APUS-OpenJev-v1** 是一个决策模型系列,面向浏览器智能体和业务工作流。输入任务、上下文和候选动作后,模型返回带有评分的选择,供应用执行。该系列提供4B和9B版本,采用统一的决策接口。
35
 
36
+ **语言原生决策。** 任务定义和候选项含义通过自然语言输入,使同一模型能够处理变化的决策空间,无需为每类业务另建固定分类头。
37
+
38
+ **按决策需求分配计算。** 架构结合可选执行深度与[候选感知输出投影](#候选感知输出投影)。应用选择`effort="low"`或`effort="high"`;原生 low 路径将经过训练的较浅出口与候选专用读出结合,在支持的输出头上只计算当前候选标签的分数。既减少执行层数,也减少无关词表项的输出计算,同时沿用模型共享的语言输出空间。
39
 
40
  **联合后训练。** 不同计算深度下的决策学习共同进行。两条执行路径都从参考答案中学习,完整路径还通过候选概率分布为较短路径提供学习信号。这样,较早的决策出口经过任务训练,而不是直接依赖未经训练的中间表示。[架构指南](ARCHITECTURE.md)进一步介绍了这一设计及其取舍。
41
 
 
105
 
106
  独立的 **9B · effort: high · vLLM HTTP API**参考:P50/P95/P99为 **25.58 / 222.36 / 275.58 ms**,硬件为 **单张RTX PRO 6000 Blackwell 96GB GPU**,计时包含完整HTTP响应。标准vLLM启动脚本运行完整深度模型;本图不表示脚本已经提供low-effort HTTP路由。[测量来源](effort-tradeoff-data.json)。
107
 
 
 
 
 
 
 
 
 
 
 
 
 
108
  ## 3. 评测集
109
 
110
  ![Frozen80数据构成:五类任务各16题,共80题、79个父组。](assets/dataset-subsets.svg)
 
129
 
130
  合法输出仍可能是错误决策。候选概率不是经过校准的置信度,业务阈值需要验证。支持的请求格式见[runtime接口约定](9B-3000/RUNTIME.md)。
131
 
132
+ ### 候选感知输出投影
133
+
134
+ 计算深度和输出宽度分别影响两部分成本。原生 low 路径在较浅出口读取特征,并先取出本次候选标签对应的语言输出权重,再计算分数。它沿用模型的语言输出空间,省去该路径中无关词表项的输出头计算。
135
+
136
+ | 执行路径 | 输出头计算 |
137
+ | --- | --- |
138
+ | 原生 `effort="low"` | 先取候选权重行再投影;不支持的输出头回退完整计算 |
139
+ | 原生 `effort="high"` | 计算全词表,再选择候选 |
140
+ | 当前 vLLM 决策/Chat 服务 | 计算全词表;决策网关随后提取候选分数 |
141
+
142
+ 这一优化减少的是输出头工作,不省略上下文骨干计算;当前 vLLM 延迟结果尚不包含候选专用输出头的收益。机制和执行范围见[技术报告](TECHNICAL_REPORT.md#6-performance-where-the-savings-can-come-from)。
143
+
144
  ## 5. 最小推理示例
145
 
146
  本仓库集中保存一个模型系列。请选择包含完整BF16权重和参考runtime的具体子目录:
TECHNICAL_REPORT.md CHANGED
@@ -15,7 +15,7 @@ Many useful language-model interactions end in a decision: choosing a browser ac
15
 
16
  - **Evidence-informed decisions.** Tasks, policies, and candidate actions are expressed in natural language, so a shared model can address changing business rules and action spaces. The 9B model achieves 85.00% accuracy on the development comparison panel, alongside 82.50% for the Jev API. Section 7 presents the shared evaluation setting and results.
17
  - **Less work between understanding and action.** Candidate scoring produces a bounded decision without decoding a complete structured document. This targets the repeated selection steps found in browser agents, business routing, and workflow handoffs.
18
- - **Compute that fits the workflow.** Jointly trained low and high effort modes let applications choose the execution budget appropriate to each decision point. This creates a practical basis for balancing decision quality with latency and resource cost.
19
  - **Deployment under application control.** Downloadable 4B and 9B weights and an accompanying runtime support local decision execution, giving teams control over infrastructure, data handling, and integration into existing systems.
20
 
21
  For browser agents, the target is choosing the next action from page evidence and a goal. For high-frequency business services, it is applying a supplied rule or routing a request to an appropriate next step. For workflow handoffs, it is returning a decision that host code can map into a structured action. These scenarios share the same language-conditioned decision interface; their production value can be evaluated through both decision correctness and completed workflow outcomes.
 
15
 
16
  - **Evidence-informed decisions.** Tasks, policies, and candidate actions are expressed in natural language, so a shared model can address changing business rules and action spaces. The 9B model achieves 85.00% accuracy on the development comparison panel, alongside 82.50% for the Jev API. Section 7 presents the shared evaluation setting and results.
17
  - **Less work between understanding and action.** Candidate scoring produces a bounded decision without decoding a complete structured document. This targets the repeated selection steps found in browser agents, business routing, and workflow handoffs.
18
+ - **Compute that fits the workflow.** Jointly trained low and high effort modes let applications choose the execution budget appropriate to each decision point. This creates a practical basis for balancing decision quality with latency and resource cost. In the native low path, candidate-aware projection further limits output-head work to the supplied labels on supported heads, pairing depth control with output-width control while retaining a shared language output space.
19
  - **Deployment under application control.** Downloadable 4B and 9B weights and an accompanying runtime support local decision execution, giving teams control over infrastructure, data handling, and integration into existing systems.
20
 
21
  For browser agents, the target is choosing the next action from page evidence and a goal. For high-frequency business services, it is applying a supplied rule or routing a request to an appropriate next step. For workflow handoffs, it is returning a decision that host code can map into a structured action. These scenarios share the same language-conditioned decision interface; their production value can be evaluated through both decision correctness and completed workflow outcomes.
bundle-manifest.json CHANGED
@@ -583,18 +583,18 @@
583
  },
584
  {
585
  "path": "README.md",
586
- "bytes": 18393,
587
- "sha256": "ad1629cedd10272364c4dedc62c4f3fa543ac7a16bb8aa61954110621f9835b3"
588
  },
589
  {
590
  "path": "README.zh-CN.md",
591
- "bytes": 13687,
592
- "sha256": "5c43d47581f91354b480a77b8a3e3f0e63e9b10664d4853ad7ea56f44634aeaf"
593
  },
594
  {
595
  "path": "TECHNICAL_REPORT.md",
596
- "bytes": 28076,
597
- "sha256": "6c983b294524575620767522cf28477ad0cc1e9d25925a6eb11c953cea13c42d"
598
  },
599
  {
600
  "path": "TECHNICAL_REPORT.pdf",
 
583
  },
584
  {
585
  "path": "README.md",
586
+ "bytes": 18803,
587
+ "sha256": "47b45662d3356a3324062b84cb6bd381621865241744cbe9ff0c0928fb8f948d"
588
  },
589
  {
590
  "path": "README.zh-CN.md",
591
+ "bytes": 14045,
592
+ "sha256": "0a733d01ed54e3f9dca9210c5384d46a62128a746d5c78b20474f0c7d76e7bfb"
593
  },
594
  {
595
  "path": "TECHNICAL_REPORT.md",
596
+ "bytes": 28298,
597
+ "sha256": "eb51a79fc255f9e75833dff880a3a36792ded4535f1e6ba2173da5d5f11e5f62"
598
  },
599
  {
600
  "path": "TECHNICAL_REPORT.pdf",