---
title: OpForge-Qwen3.6-Specialist-Suite
canonical_url: "https://www.modelscope.cn/models/AkkoYK/OpForge-Qwen3.6-Specialist-Suite"
md_url: "https://www.modelscope.cn/models/AkkoYK/OpForge-Qwen3.6-Specialist-Suite.md"
repository: AkkoYK/OpForge-Qwen3.6-Specialist-Suite
chinese_name: "OpForge Qwen3.6 Specialist Suite"
last_updated: 2026-08-06
license: other
pipeline_tag: text-generation
tasks:
  - text-generation
base_model:
  - Qwen/Qwen3.6-35B-A3B
base_model_relation: adapter
parameters: 130.0M
tensor_type:
  - F32
library_name:
  - peft
  - lora
  - safetensors
  - pytorch
frameworks:
  - pytorch
language:
  - zh
  - en
downloads: 28
stars: 1
tags:
  - Qwen3.6
  - PEFT
  - LoRA
  - Ascend
  - NPU-operator
  - code-generation
  - agent
---

# OpForge-Qwen3.6-Specialist-Suite

> OpForge-Qwen3.6-Specialist-Suite - AkkoYK 在 ModelScope 开源的模型。面向昇腾 910B 系列算子生成与 Agent 工作流的 Qwen3.6 四模型 LoRA 套件，包含 Unified、Planner、Coder 与 Repair。

AkkoYK/OpForge-Qwen3.6-Specialist-Suite 是 ModelScope 魔搭社区上的 130.0M 参数text-generation模型，采用 other 许可，基于 Qwen/Qwen3.6-35B-A3B 构建。

- **Repository**: AkkoYK/OpForge-Qwen3.6-Specialist-Suite
- **License**: other
- **Tasks**: text-generation
- **Parameters**: 130.0M
- **Base model**: Qwen/Qwen3.6-35B-A3B
- **Tags**: Qwen3.6, PEFT, LoRA, Ascend, NPU-operator, code-generation, agent
- **Downloads**: 28
- **Stars**: 1
- **Last updated**: 2026-08-06

Source: https://www.modelscope.cn/models/AkkoYK/OpForge-Qwen3.6-Specialist-Suite

---

# OpForge Qwen3.6 Specialist Suite

面向昇腾 910B 系列算子生成与 Agent 工作流的四模型 LoRA 套件。

OpForge 将算子调优知识、高性能参考实现、Verifier 反馈和 Harness 协议蒸馏到
`Qwen/Qwen3.6-35B-A3B`。发布包包含一个综合模型和三个职责模型。四者共用同一基座，
仓库只保存 PEFT adapter，不重复分发基座权重。

## 这套模型解决什么

通用代码模型能生成 Python，却不一定理解昇腾算子机制，也很难稳定遵守严格的工程协议。
OpForge 将任务拆成知识理解、方案规划、算子生成和反馈修复四个阶段。能够确定性计算的字段
由 Harness 负责，正确性与性能由目标 NPU 上的未修改官方 runner 裁决。

```text
operator task
  -> governed knowledge / progressive disclosure
  -> semantic plan
  -> deterministic contract
  -> operator code
  -> static gate + strict verifier
  -> bounded repair when needed
  -> unmodified official runner
```

模型负责语义和代码，Harness 负责资产、权限、协议、物化和晋级。这条职责边界贯穿训练、
部署与评测。

## 模型家族

| 模型 | 冻结版本 | 主要输出 | 推荐用途 | 发布等级 |
|---|---|---|---|---|
| [Unified](models/unified/README.md) | U7 step48 | KNOWLEDGE / Workflow / PLAN / GENERATE / REPAIR | 单端点、多模式研究与后续蒸馏 | Research Preview |
| [Planner](models/planner/README.md) | V12 step30 | action / invariants / mechanism JSON | 语义规划与 contract 前置决策 | Role Model |
| [Coder](models/coder/README.md) | V16 step8 | 完整 raw Python 算子文件 | 固定任务集的低开销算子生成 | Verified Specialist |
| [Repair](models/repair/README.md) | V21 step12 | apply / escalate + bounded edits | Verifier 反馈下的局部修复 | Research Specialist |

推荐部署拓扑是 Planner、Coder、确定性 Harness 与 strict verifier 的组合。Unified 提供统一
端点，适合研究路由、多任务协同和后续蒸馏；三个职责模型则保留可独立复验的专业能力。

## 模型系谱

本仓库是一个 PEFT adapter 套件。模型卡通过 `base_model` 和
`base_model_relation: adapter` 显式关联上游基座，仓库级训练血缘如下：

```text
Qwen/Qwen3.6-35B-A3B
├── Expert V0–V21
│   ├── V12 step30  -> Planner
│   ├── V16 step8   -> Coder
│   └── V21 step12  -> Repair
└── Unified U1–U7
    └── U7 step48   -> Unified
```

这是训练血缘而不是权重合并关系：四个发布物均为独立 LoRA adapter，共享同一基座；
仓库不包含 Qwen 基座权重。每个 adapter 的角色、冻结版本和 checkpoint 记录在对应的
`models/*/README.md`、`adapter_config.json` 与 [训练历史](training/HISTORY.md) 中。

## 端到端结果

在 Ascend 910B3 条件下，我们使用同一时期的 OpForge AKG Agent、相同算子集合和未修改
官方 runner，对 DeepSeek 路线与 V16 Coder 无 Skill 路线进行了端到端记录：

| 指标 | DeepSeek + progressive Skill | OpForge V16 no-Skill | 对照结果 |
|---|---:|---:|---:|
| 未修改 official runner | 原始产物 9/13；有界恢复后 13/13 | 13/13 | V16 直接完成 |
| 加权总分 | 1065.89 | 1183.92 | +118.03 |
| 平均 Speedup | 1.0299x | 1.6411x | +0.6112x |
| 输入 token | 2,248,258 | 16,802 | -99.3% |
| 输出 token | 473,878 | 2,114 | -99.6% |
| non-cache token | 3,192,529 | 18,916 | -99.4% |
| Skill 调用 | 134 | 0 | -134 |
| 工具调用 | 1,623 | 0 | -1,623 |
| Harness error | 19 | 0 | -19 |
| Agent/API 主流程耗时 | 16,463 s | 1,040.4 s | -93.7% |

V16 路线由 9 个模型生成的 Python case 和 4 个 Harness 确定性 sidecar 组成：前者全部
PASS@1，后者全部 PASS@0。V16 共调用模型 9 次，没有加载 Skill，也没有创建子任务。

### 实验版本说明

上述结果及 DeepSeek 对照均采集于 OpForge AKG Agent 的早期版本。该版本早于后续加入的
持续会话治理、确定性物化、权限预检、渐进式 Skill 披露和打包恢复等工程优化，因此绝对
分数与耗时应视为保守的历史快照，可能略低于当前 Agent 的完整能力。

两条路线在同一时期、同一冻结工作流和同一设备条件下完成，仍能清楚反映微调模型的效果：
V16 将 non-cache token 从 3,192,529 降至 18,916，Agent/API 主流程耗时从 16,463 秒降至
1,040.4 秒，Skill、工具和 Harness error 均降为 0；总分由 1065.89 提升至 1183.92。
这说明 adapter 能将已验证的知识与协议压缩到少量、稳定的模型调用中。

V16 的 9 个 Python 输出与训练参考实现逐字节一致，验证的是固定任务集上的知识内化、
一次生成稳定性与流程压缩。4 个 sidecar 由 Harness 确定性生成，不计入模型代码生成能力。
带最多两轮 verifier-feedback repair 的 V18b 路线取得 13/13 PASS、1195.60 分和 1.6537x
平均 Speedup。详细口径见 [评测与证据](evaluation/README.md)。

## 快速开始

### 1. 下载

```python
from modelscope import snapshot_download

repo_dir = snapshot_download(
    "AkkoYK/OpForge-Qwen3.6-Specialist-Suite",
    revision="master",
)
print(repo_dir)
```

### 2. 使用 Coder adapter

训练与验收环境固定使用 `ms-swift==4.4.2`：

```bash
swift infer \
  --model Qwen/Qwen3.6-35B-A3B \
  --adapters /path/to/repo/models/coder \
  --template qwen3_5 \
  --model_type qwen3_5_moe \
  --torch_dtype bfloat16 \
  --attn_impl sdpa \
  --max_length 8192 \
  --max_new_tokens 4096 \
  --temperature 0
```

Coder 的输出契约是一个完整 Python 文件，不包含 Markdown 围栏、解释文字或多候选列表。
输入 contract、输出清洗、静态门和 NPU 执行由 OpForge Harness 管理。

### 3. 部署为 OpenAI 兼容 API

当前发布物是 NF4 QLoRA adapter。与训练和验收口径最一致的部署方式是单 adapter、
`transformers` 后端和 bitsandbytes 4-bit 基座：

```bash
CUDA_VISIBLE_DEVICES=0 \
swift deploy \
  --model Qwen/Qwen3.6-35B-A3B \
  --adapters /path/to/repo/models/coder \
  --infer_backend transformers \
  --load_args false \
  --served_model_name opforge-coder \
  --template qwen3_5 \
  --model_type qwen3_5_moe \
  --torch_dtype bfloat16 \
  --quant_method bnb \
  --quant_bits 4 \
  --bnb_4bit_compute_dtype bfloat16 \
  --bnb_4bit_quant_type nf4 \
  --bnb_4bit_use_double_quant true \
  --experts_impl eager \
  --attn_impl sdpa \
  --enable_thinking false \
  --add_non_thinking_prefix true \
  --max_length 8192 \
  --max_new_tokens 4096 \
  --temperature 0 \
  --port 8000
```

### 4. 按硬件选择部署方案

| 显卡配置 | 推荐方案 | Adapter 拓扑 | 说明 |
|---|---|---|---|
| 16GB 及以下消费卡 | 远程 API，或选用更小基座重新蒸馏 | 不在本机驻留 35B 基座 | 当前 adapter 不能脱离 35B 基座单独运行；不建议用磁盘 offload 充当日常服务 |
| 单张 24GB 消费卡（RTX 3090/4090） | Transformers + NF4，必要时受控 CPU offload | 每次加载一个角色 | **实验性可用**；并发 1，从 4K 输入、2K 输出开始，完整 Coder 输出需逐步放宽并实测峰值 |
| 单张 32GB 消费卡（RTX 5090 等） | Transformers + NF4 | 每次加载一个角色 | **消费级推荐入口**；并发 1，可从 6K–8K 输入、4K 输出开始验证 |
| 双 24GB / 双 32GB 消费卡 | Transformers/Accelerate `device_map=auto` 模型分片 | 单角色、单进程 | 用于解决容量，不等于吞吐翻倍；先用 `swift infer` 或直接 Transformers 验证，不把它写成 ms-swift 多卡服务承诺 |
| 单张 48–64GB 专业卡 | Transformers + NF4 | 每次加载一个角色 | 适合低 QPS API 与完整 8K/4K 复验，显存余量明显优于消费卡 |
| 单张 80–96GB 专业卡/数据中心卡 | Transformers + NF4 | 一个角色一个进程 | **稳定服务默认推荐**；与冻结评测路径一致，可为更长上下文或并发保留余量 |
| 多张专业卡，追求吞吐 | 先制作并验证独立的非 QLoRA/合并量化服务产物，再用 vLLM/SGLang | 独立 endpoint 或经验证的 multi-LoRA | 当前 QLoRA adapter 不应直接承诺 vLLM 加速；Transformers 模型分片也不是吞吐方案 |
| 四角色并行服务 | Coder 独立低延迟 endpoint；Planner/Repair/Unified 按流量隔离 | 四 endpoint，或经兼容性验证后共享基座 | 不线性合并四个 LoRA；按 `models/*` 的输出契约路由 |

35B-A3B 的 “3B activated” 降低的是每 token 计算量，不会让完整 35B 权重免于装入内存。
因此显存规划应按总权重、KV cache、量化后端和并发共同计算，不能按 3B dense 模型估算。

四模型路由、OOM 调整顺序、OpenAI API 示例以及加速路径的兼容性门见
[部署指南](docs/DEPLOYMENT.md)。

## 数据

本次结构化发布包含四个冻结 checkpoint 对应的 train/val 数据：

- `datasets/unified`：Skill 知识、Workflow/Harness、PLAN、GENERATE、REPAIR 联合蒸馏；
- `datasets/planner`：action、invariants、mechanism；
- `datasets/coder`：contract-conditioned raw Python；
- `datasets/repair`：Verifier 反馈绑定的 apply/escalate 与局部 edit。

冻结 selection、challenge 和 official-runner 目标不混入训练目录。数据来源、字段、去重与
边界见 [数据卡](datasets/README.md)。

## 训练方法

| 项目 | 配置 |
|---|---|
| Base | Qwen/Qwen3.6-35B-A3B |
| Quantization | bitsandbytes NF4, double quant |
| Precision | bfloat16 compute |
| LoRA | rank 32, alpha 64, dropout 0 |
| Target modules | attention projections、Qwen3.5 MoE input/output projections |
| Framework | ms-swift 4.4.2 + PEFT |
| Thinking supervision | 关闭；只监督可审计 final answer |
| Training device | NVIDIA RTX PRO 6000 96GB |

V0-V21 建立角色专家与真实 NPU 闭环，U1-U7 验证单 adapter 对知识、协议、生成和修复的
统一承载能力。完整演进见 [训练历史](training/HISTORY.md)。

## 仓库结构

```text
.
├── models/
│   ├── unified/          # U7 step48，综合 adapter
│   ├── planner/          # V12 step30，语义规划 adapter
│   ├── coder/            # V16 step8，算子生成 adapter
│   └── repair/           # V21 step12，有界修复 adapter
├── datasets/             # 四条训练线的 governed train/val
├── training/             # 版本史与训练配置
├── evaluation/           # 证据等级、真实 NPU 与静态评测
├── docs/                 # 架构、部署、接口与设计边界
├── evidence/             # 小型审计与选择结果
├── MANIFEST.json
└── SHA256SUMS
```

`master` 只保留面向使用者的结构化成果。V0-V21 的完整研发归档保存在
`archive-v0-v21-20260801` tag，可按需追溯，不占用主分支根目录。

## 适用范围与使用边界

- 目标是昇腾 910B 系列共有的算子机制和 Agent/Harness 契约；
- 适用于算子方案规划、代码生成和 verifier-feedback repair；生成物应通过静态门、strict
  verifier 与未修改 official runner 后再进入交付流程；
- 当前官方流程证据来自 Ascend 910B2C/910B3；
- 换用 CANN、torch_npu、驱动或 910B 子型号后，应重新执行 strict verifier、同轮参考
  实现对照和未修改 official runner；
- 性能数字只在记录的硬件与 runner 配置下成立；本仓库是专业 adapter 套件，不单独替代
  Qwen 基座权重或目标 NPU 验证环境。

## 演进方向

后续工作将加入 910B4 执行轨迹和更多未见算子族，扩大 case-isolated challenge，继续把
确定性协议下沉到 Harness，并以真实 Verifier 反馈训练可迁移的 repair policy。

## 许可证与引用

基座权重不包含在本仓库中，使用者需遵守 Qwen 上游模型许可证。OpForge 原创代码与文档
采用 Apache-2.0；训练数据和 adapter 的来源与使用边界见
[LICENSE_AND_USE.md](LICENSE_AND_USE.md)。引用格式见 [CITATION.cff](CITATION.cff)。