大模型基础模型推理模型微调模型优化【免费下载链接】Swift-Qwen3.8-27b项目地址https://ai.gitcode.com/hf_mirrors/ukisai/Swift-Qwen3.8-27b点击查看免费下载Swift-Qwen3.8-27B 是 UkisAI 基于 Qwen3.8-27B 训练的高效推理reasoning-efficient衍生模型通过识别并惩罚触发过度思考的推理标记 Token在保持准确率几乎不变损失 1%的前提下将思考 Token 减少 58.3%并在多项任务上获得约 x1.95 的加速。本文以本仓库 README.md 为核心骨架结合 config.json、generation_config.json、NOTICE、model.safetensors.index.json 等仓库文件系统讲解其训练思路、评测结果、量化表现并给出 UkisAI API、Transformers、vLLM、SGLang 四种可复制的部署方案与可选的 MTP 自推测解码配置。一、模型定位与训练思路Swift-Qwen3.8-27B 是 UkisAI 对 Qwen3.8-27B 的推理高效化微调产物属于派生模型finetune基于 README.md 的 YAML 元数据base_model_relation: finetune。它的核心目标是解决推理模型普遍存在的**过度思考overthinking**问题——模型在给出答案前会生成大量低价值的思考 Token拖慢响应速度、增加推理成本。其训练方法可以概括为三步见 README.md 的 Training approach 一节定位推理标记 Token分析 Qwen 推理 rollout 中触发过度思考的推理标记 Tokenreasoning-marker tokens惩罚式微调在模型推理过程中对这些 Token 的使用施加惩罚引导模型生成更短的推理轨迹迁移增强为了获得更大收益Swift 还融入了源自 BottleCap AI 的 ThinkingCap-Qwen3.6-27B 的迁移组件transfer component。从 NOTICE 的 Apache 2.0 Section 4(b) 变更声明可以确认UkisAI 的贡献是由 UkisAI 训练的 LoRA 适配器LoRA adapter合并进基座模型权重即发布的是合并后的全量权重而非独立的 adapter 文件。同时 NOTICE 明确指出除权重与generation_config.json新增了min_p与repetition_penalty两项、README 与素材文件外其余文件config.json、chat_template.jinja、tokenizer_config.json 等均未修改仍沿用 Qwen3.8-27B 的 Apache 2.0 许可。这意味者它的分词、对话模板、视觉编码等行为与基座完全一致只是推理时的思考习惯被改变。从推理效果看README 原话Swift 产生更短的推理轨迹测试中还观察到更少的过度思考错误。二、仓库权重结构与模型架构佐证在阅读评测与部署章节之前先看仓库内部结构如何印证上述设计权重总量model.safetensors.index.json 的 metadata 记录total_size为 55,562,855,904 字节约 55.6 GB权重切分为 18 个 safetensors 分片model-00001-of-00018.safetensors至model-00018-of-00018.safetensors以 BF16 精度存储架构类型config.json 声明architectures为Qwen3_5ForConditionalGeneration、model_type为qwen3_5是一个图像-文本-视频多模态条件生成模型README 元数据pipeline_tag: image-text-to-text混合注意力结构文本侧共 64 层其中 48 层为linear_attention线性注意力/Mamba 风格权重含linear_attn.A_log、linear_attn.conv1d、linear_attn.dt_bias、linear_attn.in_proj_a/b/qkv/z等16 层为full_attention标准全注意力权重含self_attn.q/k/v/o_proj二者以每 4 层一个全注意力层的节奏交替出现full_attention_interval: 4MTP 头存在mtp_num_hidden_layers: 1权重索引中可见完整的 64 层结构与 lm_head这为 README 中可选 MTP 解码提供了结构基础上下文与词表max_position_embeddings: 262144、vocab_size: 248320、hidden_size: 5120、intermediate_size: 17408与 README 中 vLLM/SGLang 推荐的--max-model-len 262144完全对应多模态配置image_token_id: 248056、video_token_id: 248057视觉塔深度 27 层、patch 16×16、temporal patch 2preprocessor_config.json 与 video_preprocessor_config.json 分别声明Qwen3VLProcessor/Qwen2VLImageProcessorFast/Qwen3VLVideoProcessor推理/思考 Tokentokenizer_config.json 中定义了think248068与/think248069Token以及reasoning_effortxhigh / medium / low三档模板指令正是 README Efficiency across and versus reasoning efforts 一节所测试的机制。也就是说Swift 并非改动架构而是在固定架构与词表之上通过 LoRA 微调改变模型对思考 Token 的使用模式。三、核心评测结果BF16 全精度基准以下所有结果均对比Qwen3.8-27B BF16 基座与同一基座 Swift 适配器README.md Evaluation scope。README 在通用推理、数学、多模态、Agent 编码四类共 9 项基准上的主要数据如下Score 列对比基座与 SwiftToken 列对比思考 Token 均值及其缩减幅度Median tokens 为思考 Token 中位数缩减幅度基准Base 分数Swift 分数Base 平均 TokenSwift 平均 Token平均缩减中位缩减通用推理GPQA-Diamond88.38%88.28%15,0148,855↓ 41.0%↓ 58.3%MMLU-Pro85.47%84.95%2,9801,603↓ 46.2%↓ 28.3%C-Eval90.00%90.62%1,492804↓ 46.1%↓ 19.3%IFBench73.53%71.80%8,0524,657↓ 42.2%↓ 50.5%数学AIME 202698.67%94.00%22,01416,143↓ 26.7%↓ 50.2%HMMT (Nov 2025)99.33%96.00%22,03215,189↓ 31.1%↓ 45.9%多模态ERQA67.45%66.30%4,1372,045↓ 50.6%↓ 54.6%Agent 编码Terminal-Bench 2.166.74%65.84%37,08627,272↓ 26.5%↓ 38.7%LiveCodeBench v676.76%81.55%11,3748,615↓ 24.3%↓ 45.8%几点值得注意的观察基于 README 数据本身大多数基准上 Swift 的分数与基座几乎持平差值多在 1 个百分点以内但思考 Token 的均值与中位数均大幅下降C-Eval 与 LiveCodeBench v6 上 Swift 分数反而更高90.00% → 90.62%76.76% → 81.55%说明削减思考并未损伤甚至可能改善部分任务的正确率GPQA-Diamond 上中位数 Token 缩减达 58.3%这也是 README 封面引用的核心数字来源数学类AIME/HMMT分数下降相对明显约 4 个百分点左右换取的是约 27%–31% 的平均思考 Token 缩减——选择时需结合任务对精度的敏感度权衡。复现实验配置Reproduce settingsREADME 提供了完整、可复现的评测环境部署或自行复现时应严格对齐服务端BF16 精度 · vLLM 0.27.1 · Qwen3 parser--reasoning-parser qwen3· 上下文长度 262,144 · 思考档位 xhigh采样参数temperature 1.0 · top_p 0.95 · top_k 20 · min_p 0 · presence_penalty 0 · repetition_penalty 1统计口径每个模型在 5 个随机种子0–4上取平均Terminal-Bench 每个任务跑 5 次试验。各基准的输出上限Output cap各不相同复现时必须按下表设置基准输出上限TokenGPQA-Diamond100,000MMLU-Pro100,000C-Eval16,384IFBench81,920AIME 2026250,000HMMT (Nov 2025)250,000ERQA100,000Terminal-Bench 2.1Agent/任务级限制LiveCodeBench v632,768值得注意的是仓库自带 generation_config.json 与上述采样参数完全一致do_sample: true、temperature: 1.0、top_p: 0.95、top_k: 20、min_p: 0、repetition_penalty: 1.0且eos_token_id为[248046, 248044]|im_end|与|endoftext|、pad_token_id: 248044。这意味着你用 Transformers 直接加载模型时默认采样行为已与官方评测对齐无需额外修改。根据 NOTICEmin_p与repetition_penalty正是 UkisAI 在基座生成配置上新增的两项。四、不同 reasoning effort 下的效率表现Qwen3.8 的reasoning_effort参数允许用户控制模型想多少。为了让 Swift 在所有档位下都有意义README 分别测试了xhigh、medium、low三档结论是思考 Token 的节省在所有档位下都成立Reasoning effort平均思考 Token 缩减Xhigh↓ 41.0%Medium↓ 22.7%Low↓ 25.8%更严格的对比例子是 GPQA-Diamond198 题、5 个种子、共 990 次配对调用Swift 在xhigh档与基座在xhigh、medium档分别对比GPQA-Diamond分数平均 Token中位 TokenBase · xhigh88.38%15,0146,642Swift · xhigh88.28%8,8552,771Base · medium84.14%4,4511,753结论README 原意Swift 保留xhigh的准确率同时只消耗约一半的 Token代价是相比基座medium档Token 用量约为其两倍。也就是说Swift 的定位是用xhigh的精度换medium级别的思考开销而不是进一步压缩到极限。这一机制在 chat_template.jinja 中有直接体现模板接受reasoning_effort可选xhigh默认/medium/low并据此注入不同的 system 指令——xhigh会要求仔细思考、验证关键假设、权衡备选方案low则要求思考保持简短聚焦、直接得出结论。Swift 的 LoRA 微调正是为了在这些指令下依然能高效产出。五、量化部署表现INT4 / W4A16README 明确说明量化部署是 Swift 的预期使用方式——更小的内存权重配合更短的推理轨迹正好适合边缘与低成本推理。以下每行都是同一量化基座 不加 Swift 适配器的对比GPQA 与 AIME 用 5 个种子IFBench 每个 prompt 采 4 个样本并用严格评分基准 / 量化方式Base 准确率Swift 准确率平均 Token 缩减中位 Token 缩减GPQA-Diamond · 混合精度 W4A16思考 Token88.69%88.38%↓ 32.1%↓ 50.2%IFBench · 混合精度 W4A16completion Token72.58%71.25%↓ 30.1%↓ 38.0%AIME 2026 · 混合精度 W4A16completion Token84.00%84.00%↓ 19.0%↓ 37.5%AIME 2026 · AWQ INT4completion Token82.67%84.00%↓ 22.8%↓ 34.8%量化环境说明README Quantized evaluation settingsGPQA 与 AIME 使用 5 个种子IFBench 每 prompt 4 个样本、严格评分输出上限 GPQA 100,000、IFBench 81,920、AIME 32,768GPQA 与 IFBench 使用保存的历史基座结果AIME 使用模板默认 effort并将截断答案计为错误——AIME 因 cap 更短属于与 BF16 表相互独立的对比。要点是量化后 Token 缩减依然保持19%–32% 平均、34.8%–50.2% 中位AIME 上 Swift 匹配甚至提升准确率并将输出 cap 失败率降低 31–33%即更少出现答案被输出上限截断的情况AWQ INT4 场景下 Swift 准确率84.00%反超量化基座82.67%。六、部署实战四种方式 可选 MTP 解码README 的 How to use 一节给出了四种使用路径下面完整展开并补充参数说明。1. GGUF 下载llama.cpp 生态官方提供了独立发布的GGUF 版本ukisai/Swift-Qwen3.8-27B-GGUF适用于兼容的 llama.cpp 系运行时。GGUF 与量化章节一脉相承是低内存部署的推荐入口。2. UkisAI 托管 API零门槛试用Swift 通过 OpenAI 兼容 API 提供服务https://ukisai.com/api/swift/v1研究用途免费、无需 API Key模型 ID 为swift。Pythonopenai 库调用from openai import OpenAI client OpenAI(base_urlhttps://ukisai.com/api/swift/v1, api_keynone) response client.chat.completions.create( modelswift, messages[{role: user, content: Explain speculative decoding in two sentences.}], ) print(response.choices[0].message.content)或直接 curlcurl https://ukisai.com/api/swift/v1/chat/completions \ -H Content-Type: application/json \ -d {model: swift, messages: [{role: user, content: Hello, Swift.}]}3. Transformers本地加载Swift 是 image-text-to-text 模型应使用AutoModelForImageTextToText而非纯文本加载类同时搭配AutoProcessorimport torch from transformers import AutoModelForImageTextToText, AutoProcessor model_id ukisai/Swift-Qwen3.8-27b processor AutoProcessor.from_pretrained(model_id) model AutoModelForImageTextToText.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto, )需要说明的适用前提权重约 55.6 GBBF16见 model.safetensors.index.json单卡显存不足时应使用device_mapauto配合多卡或改走量化/GGUF 路线由于 generation_config.json 已内嵌官方评测相同的采样参数加载后直接generate即可复现默认行为。4. vLLM 服务化部署README 给出的 vLLM 命令BF16、单卡张量并行、262,144 上下文、Qwen3 推理 parser、Qwen3 Coder 工具调用 parservllm serve ukisai/Swift-Qwen3.8-27b \ --dtype bfloat16 \ --tensor-parallel-size 1 \ --max-model-len 262144 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --port 8000参数含义与注意事项--reasoning-parser qwen3让 vLLM 正确解析think.../think推理段落并分别流式输出思考内容与最终答案与评测环境一致--enable-auto-tool-choice --tool-call-parser qwen3_coder启用自动工具调用与 Qwen3 Coder 风格的工具调用解析对应 chat_template.jinja 中的tool_call/tool_response格式--max-model-len 262144与模型max_position_embeddings一致上下文越长KV cache 显存占用越大请按显存实际情况下调或配合张量并行张量并行大小--tensor-parallel-size需按 GPU 显存调整55.6 GB BF16 权重通常需要多卡并行或量化方案。5. SGLang 服务化部署使用支持 Qwen3.8 的当前 SGLang 构建版本python -m sglang.launch_server \ --model-path ukisai/Swift-Qwen3.8-27b \ --dtype bfloat16 \ --tp-size 1 \ --context-length 262144 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --port 8000同样需要根据 GPU 显存调整--tp-size与--context-length。安装与硬件相关细节可参考基座模型的 vLLM / SGLang 官方 recipeREADME 中给出本文不再列出外部链接。6. 可选MTP 自推测解码Self-speculative Decoding发布权重包含基座模型的 MTP 头mtp_num_hidden_layers: 1见 config.json权重索引中也能看到完整的语言模型层因此可以免额外训练直接启用自推测解码进一步压低首 Token 延迟与吞吐瓶颈。在服务命令上追加对应参数# vLLM --speculative-config {method:mtp,num_speculative_tokens:3} # SGLang --speculative-algorithm EAGLE --speculative-num-steps 3 \ --speculative-eagle-topk 1 --speculative-num-draft-tokens 4MTP 与 Swift 的思考 Token 削减是正交的优化前者通过草稿-验证加速解码过程后者通过减少需要解码的 Token 数量二者叠加对推理吞吐的改善更明显。七、许可证与访问说明Swift-Qwen3.8-27B 是 Qwen3.8-27BCopyright 2026 Alibaba CloudApache License 2.0对应本仓库 LICENSE-APACHE-2.0的派生作品。UkisAI 的贡献——微调后的权重——依据Swift Open License v1.0LICENSE授权NOTICE 详细列出了被修改的内容LoRA 微调合并后的权重、generation_config.json的min_p/repetition_penalty、README 与素材文件其余文件保持 Apache 2.0。许可边界README 原文要点个人、研究、教育、评估与商业用途对年总收入含关联方不超过 100 万美元的个人和组织免费超过该门槛的商业使用需要单独的Swift Enterprise License联系 UkisAI 获取条款Swift Open License 不限制你在 Apache 2.0 下对 Qwen3.8-27B 本身的权利——基座模型的使用权独立于 Swift 适配层。学术引用可参考仓库 README.md 提供的 BibTeX 条目UkisAI, 2026,swift-qwen3.8-27b。八、总结与选型建议Swift-Qwen3.8-27B 的技术脉络清晰不改架构、不换词表仅靠 LoRA 微调改变模型对思考 Token 的使用习惯从而在同一推理框架下换取 26%–58% 的思考 Token 缩减与最高近 2 倍的吞吐提升。基于上文事实给出以下选型参考追求吞吐与成本优先使用官方托管 API免费或量化W4A16 / AWQ INT4 / GGUF版本量化下 AIME 等任务还能减少输出 cap 截断失败追求精度且资源充足使用 BF16 全精度部署vLLM / SGLang / Transformers对齐 generation_config.json 的采样参数即可复现官方行为数学密集型任务注意 AIME / HMMT 在 BF16 下约有 4 个百分点下降若精度优先可结合reasoning_effort提高思考档位或回退基座极限吞吐在 vLLM / SGLang 服务上叠加 MTP 自推测解码与 Swift 的 Token 削减正交叠加。进一步深入本仓库阅读 README.md 获取全部基准细节config.json 查看混合注意力与 MTP 结构generation_config.json 核对默认采样参数NOTICE 确认派生变更范围chat_template.jinja 了解 reasoning_effort 与工具调用模板的实际生效逻辑。赞分享大模型基础模型推理模型微调模型优化【免费下载链接】Swift-Qwen3.8-27b项目地址https://ai.gitcode.com/hf_mirrors/ukisai/Swift-Qwen3.8-27b点击查看免费下载相关推荐Swift-Qwen3.8-27B完整指南一个LoRA微调如何让大模型思考Token减少58%、推理提速近2倍Swift Qwen3.8 27B完整指南一个LoRA微调如何让大模型思考Token减少58%、推理提速近2倍 Swift Qwen3.8 27B 是 Uki大模型基础模型推理模型微调模型优化Swift-Qwen3.8-27B训练原理深度解析识别推理标记TokenLoRA惩罚驯服大模型冗余思考Swift Qwen3.8 27B训练原理深度解析识别推理标记TokenLoRA惩罚驯服大模型冗余思考 Swift Qwen3.8 27B 是 UkisA大模型基础模型推理模型微调模型优化Swift-Qwen3.8-27B量化部署指南INT4/AWQ低显存方案下如何保住58%的Token节省Swift Qwen3.8 27B量化部署指南INT4/AWQ低显存方案下如何保住58%的Token节省 想在消费级显卡上跑 27B 级推理大模型本文是一份大模型基础模型推理模型微调模型优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Swift-Qwen3.8-27B 高效推理微调模型解析与部署实战：减少 58% 思考 Token 的 LoRA 微调方案
大模型基础模型推理模型微调模型优化【免费下载链接】Swift-Qwen3.8-27b项目地址https://ai.gitcode.com/hf_mirrors/ukisai/Swift-Qwen3.8-27b点击查看免费下载Swift-Qwen3.8-27B 是 UkisAI 基于 Qwen3.8-27B 训练的高效推理reasoning-efficient衍生模型通过识别并惩罚触发过度思考的推理标记 Token在保持准确率几乎不变损失 1%的前提下将思考 Token 减少 58.3%并在多项任务上获得约 x1.95 的加速。本文以本仓库 README.md 为核心骨架结合 config.json、generation_config.json、NOTICE、model.safetensors.index.json 等仓库文件系统讲解其训练思路、评测结果、量化表现并给出 UkisAI API、Transformers、vLLM、SGLang 四种可复制的部署方案与可选的 MTP 自推测解码配置。一、模型定位与训练思路Swift-Qwen3.8-27B 是 UkisAI 对 Qwen3.8-27B 的推理高效化微调产物属于派生模型finetune基于 README.md 的 YAML 元数据base_model_relation: finetune。它的核心目标是解决推理模型普遍存在的**过度思考overthinking**问题——模型在给出答案前会生成大量低价值的思考 Token拖慢响应速度、增加推理成本。其训练方法可以概括为三步见 README.md 的 Training approach 一节定位推理标记 Token分析 Qwen 推理 rollout 中触发过度思考的推理标记 Tokenreasoning-marker tokens惩罚式微调在模型推理过程中对这些 Token 的使用施加惩罚引导模型生成更短的推理轨迹迁移增强为了获得更大收益Swift 还融入了源自 BottleCap AI 的 ThinkingCap-Qwen3.6-27B 的迁移组件transfer component。从 NOTICE 的 Apache 2.0 Section 4(b) 变更声明可以确认UkisAI 的贡献是由 UkisAI 训练的 LoRA 适配器LoRA adapter合并进基座模型权重即发布的是合并后的全量权重而非独立的 adapter 文件。同时 NOTICE 明确指出除权重与generation_config.json新增了min_p与repetition_penalty两项、README 与素材文件外其余文件config.json、chat_template.jinja、tokenizer_config.json 等均未修改仍沿用 Qwen3.8-27B 的 Apache 2.0 许可。这意味者它的分词、对话模板、视觉编码等行为与基座完全一致只是推理时的思考习惯被改变。从推理效果看README 原话Swift 产生更短的推理轨迹测试中还观察到更少的过度思考错误。二、仓库权重结构与模型架构佐证在阅读评测与部署章节之前先看仓库内部结构如何印证上述设计权重总量model.safetensors.index.json 的 metadata 记录total_size为 55,562,855,904 字节约 55.6 GB权重切分为 18 个 safetensors 分片model-00001-of-00018.safetensors至model-00018-of-00018.safetensors以 BF16 精度存储架构类型config.json 声明architectures为Qwen3_5ForConditionalGeneration、model_type为qwen3_5是一个图像-文本-视频多模态条件生成模型README 元数据pipeline_tag: image-text-to-text混合注意力结构文本侧共 64 层其中 48 层为linear_attention线性注意力/Mamba 风格权重含linear_attn.A_log、linear_attn.conv1d、linear_attn.dt_bias、linear_attn.in_proj_a/b/qkv/z等16 层为full_attention标准全注意力权重含self_attn.q/k/v/o_proj二者以每 4 层一个全注意力层的节奏交替出现full_attention_interval: 4MTP 头存在mtp_num_hidden_layers: 1权重索引中可见完整的 64 层结构与 lm_head这为 README 中可选 MTP 解码提供了结构基础上下文与词表max_position_embeddings: 262144、vocab_size: 248320、hidden_size: 5120、intermediate_size: 17408与 README 中 vLLM/SGLang 推荐的--max-model-len 262144完全对应多模态配置image_token_id: 248056、video_token_id: 248057视觉塔深度 27 层、patch 16×16、temporal patch 2preprocessor_config.json 与 video_preprocessor_config.json 分别声明Qwen3VLProcessor/Qwen2VLImageProcessorFast/Qwen3VLVideoProcessor推理/思考 Tokentokenizer_config.json 中定义了think248068与/think248069Token以及reasoning_effortxhigh / medium / low三档模板指令正是 README Efficiency across and versus reasoning efforts 一节所测试的机制。也就是说Swift 并非改动架构而是在固定架构与词表之上通过 LoRA 微调改变模型对思考 Token 的使用模式。三、核心评测结果BF16 全精度基准以下所有结果均对比Qwen3.8-27B BF16 基座与同一基座 Swift 适配器README.md Evaluation scope。README 在通用推理、数学、多模态、Agent 编码四类共 9 项基准上的主要数据如下Score 列对比基座与 SwiftToken 列对比思考 Token 均值及其缩减幅度Median tokens 为思考 Token 中位数缩减幅度基准Base 分数Swift 分数Base 平均 TokenSwift 平均 Token平均缩减中位缩减通用推理GPQA-Diamond88.38%88.28%15,0148,855↓ 41.0%↓ 58.3%MMLU-Pro85.47%84.95%2,9801,603↓ 46.2%↓ 28.3%C-Eval90.00%90.62%1,492804↓ 46.1%↓ 19.3%IFBench73.53%71.80%8,0524,657↓ 42.2%↓ 50.5%数学AIME 202698.67%94.00%22,01416,143↓ 26.7%↓ 50.2%HMMT (Nov 2025)99.33%96.00%22,03215,189↓ 31.1%↓ 45.9%多模态ERQA67.45%66.30%4,1372,045↓ 50.6%↓ 54.6%Agent 编码Terminal-Bench 2.166.74%65.84%37,08627,272↓ 26.5%↓ 38.7%LiveCodeBench v676.76%81.55%11,3748,615↓ 24.3%↓ 45.8%几点值得注意的观察基于 README 数据本身大多数基准上 Swift 的分数与基座几乎持平差值多在 1 个百分点以内但思考 Token 的均值与中位数均大幅下降C-Eval 与 LiveCodeBench v6 上 Swift 分数反而更高90.00% → 90.62%76.76% → 81.55%说明削减思考并未损伤甚至可能改善部分任务的正确率GPQA-Diamond 上中位数 Token 缩减达 58.3%这也是 README 封面引用的核心数字来源数学类AIME/HMMT分数下降相对明显约 4 个百分点左右换取的是约 27%–31% 的平均思考 Token 缩减——选择时需结合任务对精度的敏感度权衡。复现实验配置Reproduce settingsREADME 提供了完整、可复现的评测环境部署或自行复现时应严格对齐服务端BF16 精度 · vLLM 0.27.1 · Qwen3 parser--reasoning-parser qwen3· 上下文长度 262,144 · 思考档位 xhigh采样参数temperature 1.0 · top_p 0.95 · top_k 20 · min_p 0 · presence_penalty 0 · repetition_penalty 1统计口径每个模型在 5 个随机种子0–4上取平均Terminal-Bench 每个任务跑 5 次试验。各基准的输出上限Output cap各不相同复现时必须按下表设置基准输出上限TokenGPQA-Diamond100,000MMLU-Pro100,000C-Eval16,384IFBench81,920AIME 2026250,000HMMT (Nov 2025)250,000ERQA100,000Terminal-Bench 2.1Agent/任务级限制LiveCodeBench v632,768值得注意的是仓库自带 generation_config.json 与上述采样参数完全一致do_sample: true、temperature: 1.0、top_p: 0.95、top_k: 20、min_p: 0、repetition_penalty: 1.0且eos_token_id为[248046, 248044]|im_end|与|endoftext|、pad_token_id: 248044。这意味着你用 Transformers 直接加载模型时默认采样行为已与官方评测对齐无需额外修改。根据 NOTICEmin_p与repetition_penalty正是 UkisAI 在基座生成配置上新增的两项。四、不同 reasoning effort 下的效率表现Qwen3.8 的reasoning_effort参数允许用户控制模型想多少。为了让 Swift 在所有档位下都有意义README 分别测试了xhigh、medium、low三档结论是思考 Token 的节省在所有档位下都成立Reasoning effort平均思考 Token 缩减Xhigh↓ 41.0%Medium↓ 22.7%Low↓ 25.8%更严格的对比例子是 GPQA-Diamond198 题、5 个种子、共 990 次配对调用Swift 在xhigh档与基座在xhigh、medium档分别对比GPQA-Diamond分数平均 Token中位 TokenBase · xhigh88.38%15,0146,642Swift · xhigh88.28%8,8552,771Base · medium84.14%4,4511,753结论README 原意Swift 保留xhigh的准确率同时只消耗约一半的 Token代价是相比基座medium档Token 用量约为其两倍。也就是说Swift 的定位是用xhigh的精度换medium级别的思考开销而不是进一步压缩到极限。这一机制在 chat_template.jinja 中有直接体现模板接受reasoning_effort可选xhigh默认/medium/low并据此注入不同的 system 指令——xhigh会要求仔细思考、验证关键假设、权衡备选方案low则要求思考保持简短聚焦、直接得出结论。Swift 的 LoRA 微调正是为了在这些指令下依然能高效产出。五、量化部署表现INT4 / W4A16README 明确说明量化部署是 Swift 的预期使用方式——更小的内存权重配合更短的推理轨迹正好适合边缘与低成本推理。以下每行都是同一量化基座 不加 Swift 适配器的对比GPQA 与 AIME 用 5 个种子IFBench 每个 prompt 采 4 个样本并用严格评分基准 / 量化方式Base 准确率Swift 准确率平均 Token 缩减中位 Token 缩减GPQA-Diamond · 混合精度 W4A16思考 Token88.69%88.38%↓ 32.1%↓ 50.2%IFBench · 混合精度 W4A16completion Token72.58%71.25%↓ 30.1%↓ 38.0%AIME 2026 · 混合精度 W4A16completion Token84.00%84.00%↓ 19.0%↓ 37.5%AIME 2026 · AWQ INT4completion Token82.67%84.00%↓ 22.8%↓ 34.8%量化环境说明README Quantized evaluation settingsGPQA 与 AIME 使用 5 个种子IFBench 每 prompt 4 个样本、严格评分输出上限 GPQA 100,000、IFBench 81,920、AIME 32,768GPQA 与 IFBench 使用保存的历史基座结果AIME 使用模板默认 effort并将截断答案计为错误——AIME 因 cap 更短属于与 BF16 表相互独立的对比。要点是量化后 Token 缩减依然保持19%–32% 平均、34.8%–50.2% 中位AIME 上 Swift 匹配甚至提升准确率并将输出 cap 失败率降低 31–33%即更少出现答案被输出上限截断的情况AWQ INT4 场景下 Swift 准确率84.00%反超量化基座82.67%。六、部署实战四种方式 可选 MTP 解码README 的 How to use 一节给出了四种使用路径下面完整展开并补充参数说明。1. GGUF 下载llama.cpp 生态官方提供了独立发布的GGUF 版本ukisai/Swift-Qwen3.8-27B-GGUF适用于兼容的 llama.cpp 系运行时。GGUF 与量化章节一脉相承是低内存部署的推荐入口。2. UkisAI 托管 API零门槛试用Swift 通过 OpenAI 兼容 API 提供服务https://ukisai.com/api/swift/v1研究用途免费、无需 API Key模型 ID 为swift。Pythonopenai 库调用from openai import OpenAI client OpenAI(base_urlhttps://ukisai.com/api/swift/v1, api_keynone) response client.chat.completions.create( modelswift, messages[{role: user, content: Explain speculative decoding in two sentences.}], ) print(response.choices[0].message.content)或直接 curlcurl https://ukisai.com/api/swift/v1/chat/completions \ -H Content-Type: application/json \ -d {model: swift, messages: [{role: user, content: Hello, Swift.}]}3. Transformers本地加载Swift 是 image-text-to-text 模型应使用AutoModelForImageTextToText而非纯文本加载类同时搭配AutoProcessorimport torch from transformers import AutoModelForImageTextToText, AutoProcessor model_id ukisai/Swift-Qwen3.8-27b processor AutoProcessor.from_pretrained(model_id) model AutoModelForImageTextToText.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto, )需要说明的适用前提权重约 55.6 GBBF16见 model.safetensors.index.json单卡显存不足时应使用device_mapauto配合多卡或改走量化/GGUF 路线由于 generation_config.json 已内嵌官方评测相同的采样参数加载后直接generate即可复现默认行为。4. vLLM 服务化部署README 给出的 vLLM 命令BF16、单卡张量并行、262,144 上下文、Qwen3 推理 parser、Qwen3 Coder 工具调用 parservllm serve ukisai/Swift-Qwen3.8-27b \ --dtype bfloat16 \ --tensor-parallel-size 1 \ --max-model-len 262144 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --port 8000参数含义与注意事项--reasoning-parser qwen3让 vLLM 正确解析think.../think推理段落并分别流式输出思考内容与最终答案与评测环境一致--enable-auto-tool-choice --tool-call-parser qwen3_coder启用自动工具调用与 Qwen3 Coder 风格的工具调用解析对应 chat_template.jinja 中的tool_call/tool_response格式--max-model-len 262144与模型max_position_embeddings一致上下文越长KV cache 显存占用越大请按显存实际情况下调或配合张量并行张量并行大小--tensor-parallel-size需按 GPU 显存调整55.6 GB BF16 权重通常需要多卡并行或量化方案。5. SGLang 服务化部署使用支持 Qwen3.8 的当前 SGLang 构建版本python -m sglang.launch_server \ --model-path ukisai/Swift-Qwen3.8-27b \ --dtype bfloat16 \ --tp-size 1 \ --context-length 262144 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --port 8000同样需要根据 GPU 显存调整--tp-size与--context-length。安装与硬件相关细节可参考基座模型的 vLLM / SGLang 官方 recipeREADME 中给出本文不再列出外部链接。6. 可选MTP 自推测解码Self-speculative Decoding发布权重包含基座模型的 MTP 头mtp_num_hidden_layers: 1见 config.json权重索引中也能看到完整的语言模型层因此可以免额外训练直接启用自推测解码进一步压低首 Token 延迟与吞吐瓶颈。在服务命令上追加对应参数# vLLM --speculative-config {method:mtp,num_speculative_tokens:3} # SGLang --speculative-algorithm EAGLE --speculative-num-steps 3 \ --speculative-eagle-topk 1 --speculative-num-draft-tokens 4MTP 与 Swift 的思考 Token 削减是正交的优化前者通过草稿-验证加速解码过程后者通过减少需要解码的 Token 数量二者叠加对推理吞吐的改善更明显。七、许可证与访问说明Swift-Qwen3.8-27B 是 Qwen3.8-27BCopyright 2026 Alibaba CloudApache License 2.0对应本仓库 LICENSE-APACHE-2.0的派生作品。UkisAI 的贡献——微调后的权重——依据Swift Open License v1.0LICENSE授权NOTICE 详细列出了被修改的内容LoRA 微调合并后的权重、generation_config.json的min_p/repetition_penalty、README 与素材文件其余文件保持 Apache 2.0。许可边界README 原文要点个人、研究、教育、评估与商业用途对年总收入含关联方不超过 100 万美元的个人和组织免费超过该门槛的商业使用需要单独的Swift Enterprise License联系 UkisAI 获取条款Swift Open License 不限制你在 Apache 2.0 下对 Qwen3.8-27B 本身的权利——基座模型的使用权独立于 Swift 适配层。学术引用可参考仓库 README.md 提供的 BibTeX 条目UkisAI, 2026,swift-qwen3.8-27b。八、总结与选型建议Swift-Qwen3.8-27B 的技术脉络清晰不改架构、不换词表仅靠 LoRA 微调改变模型对思考 Token 的使用习惯从而在同一推理框架下换取 26%–58% 的思考 Token 缩减与最高近 2 倍的吞吐提升。基于上文事实给出以下选型参考追求吞吐与成本优先使用官方托管 API免费或量化W4A16 / AWQ INT4 / GGUF版本量化下 AIME 等任务还能减少输出 cap 截断失败追求精度且资源充足使用 BF16 全精度部署vLLM / SGLang / Transformers对齐 generation_config.json 的采样参数即可复现官方行为数学密集型任务注意 AIME / HMMT 在 BF16 下约有 4 个百分点下降若精度优先可结合reasoning_effort提高思考档位或回退基座极限吞吐在 vLLM / SGLang 服务上叠加 MTP 自推测解码与 Swift 的 Token 削减正交叠加。进一步深入本仓库阅读 README.md 获取全部基准细节config.json 查看混合注意力与 MTP 结构generation_config.json 核对默认采样参数NOTICE 确认派生变更范围chat_template.jinja 了解 reasoning_effort 与工具调用模板的实际生效逻辑。赞分享大模型基础模型推理模型微调模型优化【免费下载链接】Swift-Qwen3.8-27b项目地址https://ai.gitcode.com/hf_mirrors/ukisai/Swift-Qwen3.8-27b点击查看免费下载相关推荐Swift-Qwen3.8-27B完整指南一个LoRA微调如何让大模型思考Token减少58%、推理提速近2倍Swift Qwen3.8 27B完整指南一个LoRA微调如何让大模型思考Token减少58%、推理提速近2倍 Swift Qwen3.8 27B 是 Uki大模型基础模型推理模型微调模型优化Swift-Qwen3.8-27B训练原理深度解析识别推理标记TokenLoRA惩罚驯服大模型冗余思考Swift Qwen3.8 27B训练原理深度解析识别推理标记TokenLoRA惩罚驯服大模型冗余思考 Swift Qwen3.8 27B 是 UkisA大模型基础模型推理模型微调模型优化Swift-Qwen3.8-27B量化部署指南INT4/AWQ低显存方案下如何保住58%的Token节省Swift Qwen3.8 27B量化部署指南INT4/AWQ低显存方案下如何保住58%的Token节省 想在消费级显卡上跑 27B 级推理大模型本文是一份大模型基础模型推理模型微调模型优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考