近30天源站下载量
30.4万
参数
35B
上下文
未说明
架构 / 任务
image-text-to-text
许可证
apache-2.0
MODEL POSITIONING
这个模型解决什么问题？
模型能力方面，Qwopus-3.6-35B-A3B-Coder 由 Jackrong 基于 Qwopus3.6-35B-A3B-v1 与 unsloth/Qwen3.6-35B-A3B 微调，主打思考关闭模式下的代理式编码工作流，强调工具调用稳定性、token 效率与多轮状态保持，并附带视觉多模态投影文件以支持图文输入。量化仓库方面，本仓库仅提供 GGUF 格式文件，覆盖 Q3_K_M 到 Q8_0 共 6 个量化等级以及一个 mmproj 视觉投影文件。运行工具方面，仓库已声明兼容 Ollama、llama.cpp 与 LM Studio，模型卡未说明官方推荐的推理服务框架与最低上下文窗口。
更适合谁
- 本地自托管编码代理的开发者与研究者
- 需要多轮工具调用的 AI 编码工作流搭建者
- 高显存工作站或多卡机器用户
- 希望关闭长思考以节省 token 与延迟的实验用户
典型使用场景
- Codex、OpenHands、Claude Code、OpenCode 风格的代理式编码循环
- 仓库级调试、多文件补丁生成与自动测试修复
- DevOps 脚本编写与代码审查辅助
- 大上下文代码库导航与 RTS 等可视化项目生成
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
思考关闭执行
关闭显式长思考时仍能稳定完成多步代理任务
Token 高效
减少例行编码步骤的冗余推理，降低延迟与成本
工具调用稳定
适配多轮工具调用、错误重试与状态保持
MoE 架构
35B 总参数、约 3B 激活参数，适合本地高吞吐
视觉多模态
附带 mmproj 投影文件，支持图文输入
按当前权重估算的硬件准备
- 现有 GGUF 文件中，最低显存估算约 17.5 GB
- 为上下文缓存、系统进程和并发请求预留额外内存，不要只按模型文件大小配置设备。
量化版本怎么选
- 16GB 左右显存可先用 Q3_K_M 试运行
- 24GB 显存推荐 Q4_K_M 平衡质量与体积
- 32GB 以上显存可选 Q5_K_M 或 Q6_K
- 使用视觉多模态需额外加载 mmproj-F32.gguf
GGUF VARIANTS
量化版本与硬件要求
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 17.5GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 20GB。
阅读 24GB 显存选型指南 →可以怎样运行
- 通过 Ollama 加载 GGUF 运行
- 通过 llama.cpp 直接加载 GGUF
- 通过 LM Studio 加载 GGUF
- 配合 Codex、OpenHands、OpenCode 等代理框架使用
采用前要知道的限制
- 社区实验性模型，模型卡未声明完成全面安全评估
- 工具调用质量依赖提示格式、schema 与外部代理框架
- 定位为编码专用模型，非通用领域最优选择
- 模型卡未说明官方推荐推理服务与上下文窗口上限