Qwen3.8-27B-Buddhist（佛学辞典 SFT 微调版）

基于 Qwen3.8-27B（qwen3_5 架构，稠密 27B，48 线性注意力 + 16 全注意力，带视觉模块）的佛学辞典微调模型， 使用 佛光大辞典 与 中华佛教大百科全书 的语料做 35,841 条中文佛教 SFT 微调， 目的是让模型解释和理解佛学术语、名相、义理——服务于佛学学习与查阅场景。

架构更正说明：本模型为稠密模型（Qwen3_5ForConditionalGeneration，非 MoE）。 早期文档误标为 "MoE / 激活 3B"，与事实不符，已订正。

模型卡

已上传量化版本（加载框架）

本仓库提供的量化权重按推理框架分为两类：

1. GGUF —— llama.cpp / Ollama 加载

GGUF 由 save_pretrained_gguf(..., save_method="forced_merged_4bit") 导出， 即 "4-bit NF4 基座 + LoRA 权重" 合并后的量化结果，并非 16-bit 全量微调。

2. safetensors 量化 —— vLLM 加载

各目录的 quantization_config 不同（quant_method 各异），加载命令需对应：

qwen38-nvfp4a16/ 实测结论：已在**双 2080Ti（Turing / SM75，44GB）**上用社区 vLLM-2080Ti fork 实测可用 ——compressed-tensors 的 nvfp4 变体在该 fork 里有对应 kernel（社区 README 亦实测过 ~220 tok/s）， 与下条注记里"int4 pack-quantized 不可用"是两个变体，别混。

两份 FP8 的区别 —— 按 runtime 选，不是好坏之分

• qwen38-fp8-perchannel/：llm-compressor 标准产物（compressed-tensors 容器，weight per-channel 缩放）→ 给通用 vLLM / SM89+ 等原生支持 FP8 的环境用。
• qwen38-fp8-block-mtp/：block 128×128 缩放（weight_block_size=[128,128]、激活 dynamic）、config 为 vLLM 原生 fp8 风格，MTP 头也已量化 → 给 **2080Ti（Turing / SM75）**用：社区 vLLM-2080Ti fork 为 SM75 做了 FP8 模拟路径（Marlin fallback + 实时反量化），已在双 2080Ti 实测可用。
• 选版口诀：2080Ti 双卡 → block 128×128 版（qwen38-fp8-block-mtp/）；通用 vLLM → per-channel。Turing 没有 FP8 硬件，走的是软件模拟路径，所以 per-channel 那份在 SM75 上加载不了，才另出一份 block 版。

# 示例：起 vLLM 在线服务（路径换成实际下载位置）
vllm serve ./qwen38-gptq-w4a16 --quantization gptq_marlin \
  --served-model-name qwen3.8-27b-buddhist --max-model-len 65536

⚠️ 目标硬件门槛（重要）：在 Turing / SM75（2080Ti 等）上，compressed-tensors 容器的 int4 pack-quantized（W4A16 / W8A8）没有可用 kernel —— 症状极具欺骗性：加载正常、/health 200、HTTP 200，但输出退化为复读（内容为空 / 只重复输入词）。 本仓库曾上传过两个此类版本（当时同名的 qwen38-awq-w4a16——即 compressed-tensors 那版——以及 qwen38-int8-w8a8），在 2080Ti 上不可用，均已删除。 ⚠️ 现在表里的 qwen38-awq-w4a16/ 与那条注记无关：它是后来重新做的原生 AWQ（quant_method=awq），可直接用。 选版请认 quant_method：awq / gptq（vLLM 原生格式）在 SM75 上实测可用；目录名里写着 awq/gptq 不代表真是那个格式。

这些 safetensors 量化版面向 vLLM 在线服务场景（视觉模块 visual 已排除在量化之外，保留 fp）； llama.cpp 侧请用上面的 GGUF，两者不要混用。

3. 量化范围说明（为什么大量层保持 BF16）

先看这条，再判断"量化全不全"：本仓库的量化版是针对 2080Ti（Turing / SM75，44GB 双卡）部署做的，量化范围是刻意收敛的结果。

实测覆盖率（量化模块数 / 线性层总数 ≈ 937）：

未量化的层主要是三类（各版本 config.json 的 ignore 字段可查）：

1. 线性注意力（Gated DeltaNet / linear_attn）投影：nvfp4a16 明确忽略了 240 条、autoawq 忽略 in_proj_a / in_proj_b —— 量化工具链对线性注意力算子支持不完整，硬量化容易掉点；
2. 视觉塔 visual（约 110 个模块）：对精度敏感，且纯文本部署可用 --language-model-only 直接跳过；
3. lm_head 与各 norm / bias / embedding：量化收益小、风险大。

两个"为什么"要说清：

• ① SM75 没有 FP8 硬件能力（FP8 张量核从 Ada / SM89 才有）。所以在 2080Ti 上 FP8 权重只能走社区 fork 的模拟路径（Marlin fallback + 实时反量化），实际行为是"权重 FP8 + 计算 BF16"（weight-only），激活不参与量化 —— 这也是为什么单独做了一份 block 128×128 的 FP8（面向通用 vLLM 的 per-channel 那份在 SM75 上加载不了）。
• ② 覆盖率低 ≠ 残次品：BF16 层越多，显存占用越高、数值越稳；这套组合是"2080Ti 双卡 44GB 装得下 + 跑得出可用速度"之间的折中。想追求全量化 / 更省显存，请在 SM89+ 上用 qwen38-fp8-perchannel/，或自行重量化。

4. 适用硬件与运行时（哪些是 2080Ti 专用、哪些通用）

依据：llm-compressor / vLLM 官方 scheme 表的 minimum compute capability，以及社区 fork weicj/vLLM-2080Ti-Definitive README 中的 validated 组合表（其 FP8 与 NVFP4 条目正是在 2×2080Ti 上实测的）。

一句话记法：AWQ / GPTQ（W4A16）是通用格式，2080Ti 官方原生支持；FP8 与 NVFP4 在 2080Ti 上完全依赖社区 fork 的模拟路径（官方 vLLM 分别要求 SM8.9 与 SM10.0）——换句话，"2080Ti 专用"的恰恰是那两个官方不支持这代卡的格式。

LoRA 适配器（复现 / 继续训练）

训练参数

• 基座：Qwen3.8-27B（qwen3_5 稠密架构）
• 方法：Unsloth QLoRA，r=8, alpha=8，基座 4-bit NF4
• 数据：佛光大辞典 + 中华佛教大百科全书，35,841 条（佛教 SFT，Plan A 清洗：0 空 think 块 / 0 重复 / 0 system 污染）
• 训练：3 epoch，13,443 步，final loss 1.591（2.245 → 1.591，健康收敛）
• 硬件：RTX 3090 24GB
• 导出：GGUF（forced_merged_4bit）→ Q4_K_M / Q6_K；safetensors 量化 → AutoAWQ（awq）、GPTQ（gptqmodel，vLLM 原生格式）

推理示例（llama.cpp）

# Q4_K_M（推荐，需 ~19GB 显存）
llama-server -m qwen3.8-27b-Buddhist-16bit.Q4_K_M.gguf -c 32768 -ngl 99

# 带视觉模块
llama-server -m qwen3.8-27b-Buddhist-16bit.Q4_K_M.gguf \
  --mmproj qwen3.8-27b-Buddhist-16bit.BF16-mmproj.gguf -c 32768 -ngl 99

显存需求参考：

许可

基于 Qwen3.8-27B（Apache-2.0）微调，权重与数据均以 Apache-2.0 发布。