AM Thinking V1 GGUF

🚀 AM-Thinking-v1 GGUF模型

AM-Thinking-v1 GGUF模型是专注于提升推理能力的32B密集语言模型，在推理基准测试中表现出色，可与更大的模型相媲美，且基于开源组件构建，具有广泛的应用场景。

🚀 快速开始

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "a-m-team/AM-Thinking-v1"

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto"
)

prompt = "How can I find inner peace?"
messages = [
    {"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

generated_ids = model.generate(
    **model_inputs,
    max_new_tokens=49152
)
output_ids = generated_ids[0][len(model_inputs.input_ids[0]):].tolist() 

response = tokenizer.decode(output_ids, skip_special_tokens=True)
think_content = response.split("<think>")[1].split("</think>")[0]
answer_content = response.split("<answer>")[1].split("</answer>")[0]

print (f"user prompt: {prompt}")
print (f"model thinking: {think_content}")
print (f"model answer: {answer_content}")

⚠️ 重要提示

我们已将系统提示包含在分词器配置中，因为在SFT和RL阶段都使用了该提示。为确保输出质量一致，建议在实际使用时包含相同的系统提示；否则，模型的响应可能会受到显著影响。

适用于紧凑型设备的量化版本

AM-Thinking-v1 模型有一系列量化版本。可在 AM-Thinking-v1-gguf 找到适用于 llama.cpp 和 Ollama 的版本。

✨ 主要特性

超低比特量化与IQ-DynamicGate (1 - 2比特)

我们最新的量化方法为超低比特模型（1 - 2比特）引入了精度自适应量化，经基准测试证明，在 Llama-3-8B 上有显著改进。该方法采用特定层策略，在保持极高内存效率的同时保留准确性。

基准测试环境

所有测试均在 Llama-3-8B-Instruct 上进行，使用：

• 标准困惑度评估流程
• 2048 令牌上下文窗口
• 所有量化方式使用相同的提示集

方法

• 动态精度分配：
  • 前/后 25% 的层 → IQ4_XS（选定层）
  • 中间 50% → IQ2_XXS/IQ3_S（提高效率）
• 关键组件保护：
  • 嵌入层/输出层使用 Q5_K
  • 与标准 1 - 2 比特量化相比，误差传播降低 38%

量化性能比较（Llama-3-8B）

量化方式	标准困惑度	DynamicGate困惑度	困惑度变化	标准大小	DG大小	大小变化	标准速度	DG速度
IQ2_XXS	11.30	9.84	-12.9%	2.5G	2.6G	+0.1G	234s	246s
IQ2_XS	11.72	11.63	-0.8%	2.7G	2.8G	+0.1G	242s	246s
IQ2_S	14.31	9.02	-36.9%	2.7G	2.9G	+0.2G	238s	244s
IQ1_M	27.46	15.41	-43.9%	2.2G	2.5G	+0.3G	206s	212s
IQ1_S	53.07	32.00	-39.7%	2.1G	2.4G	+0.3G	184s	209s

关键信息：

• PPL = 困惑度（越低越好）
• Δ PPL = 从标准量化到DynamicGate量化的百分比变化
• 速度 = 推理时间（CPU avx2，2048 令牌上下文）
• 大小差异反映了混合量化的开销

主要改进：

• 🔥 IQ1_M 的困惑度大幅降低 43.9%（从 27.46 降至 15.41）
• 🚀 IQ2_S 的困惑度降低 36.9%，同时仅增加 0.2GB
• ⚡ IQ1_S 尽管是 1 比特量化，但仍保持 39.7% 的更高准确性

权衡：

• 所有变体的大小都有适度增加（0.1 - 0.3GB）
• 推理速度相当（差异 < 5%）

使用这些模型的场景

📌 将模型装入GPU显存

✔ 内存受限的部署

✔ 可以容忍 1 - 2 比特误差的CPU和边缘设备

✔ 超低比特量化研究

选择合适的模型格式

选择正确的模型格式取决于您的硬件能力和内存限制。

BF16（脑浮点16） – 如果支持BF16加速则使用

• 一种16位浮点格式，专为更快的计算而设计，同时保留良好的精度。
• 提供与FP32 相似的动态范围，但内存使用更低。
• 如果您的硬件支持 BF16加速（请检查设备规格），建议使用。
• 与FP32相比，适用于高性能推理且内存占用减少的场景。

📌 使用BF16的情况： ✔ 您的硬件具有原生 BF16支持（例如，较新的GPU、TPU）。 ✔ 您希望在节省内存的同时获得更高的精度。 ✔ 您计划将模型重新量化为其他格式。

📌 避免使用BF16的情况： ❌ 您的硬件不支持 BF16（可能会回退到FP32并运行较慢）。 ❌ 您需要与缺乏BF16优化的旧设备兼容。

F16（浮点16） – 比BF16更广泛支持

• 一种16位浮点格式，具有高精度，但动态范围小于BF16。
• 适用于大多数支持 FP16加速 的设备（包括许多GPU和一些CPU）。
• 数值精度略低于BF16，但通常足以进行推理。

📌 使用F16的情况： ✔ 您的硬件支持 FP16 但不支持BF16。 ✔ 您需要在速度、内存使用和准确性之间取得平衡。 ✔ 您在GPU或其他针对FP16计算优化的设备上运行。

📌 避免使用F16的情况： ❌ 您的设备缺乏原生FP16支持（可能会比预期运行更慢）。 ❌ 您有内存限制。

量化模型（Q4_K、Q6_K、Q8等） – 用于CPU和低显存推理

量化可在尽可能保持准确性的同时减小模型大小和内存使用。

• 低比特模型（Q4_K） → 最适合最小化内存使用，可能精度较低。
• 高比特模型（Q6_K、Q8_0） → 准确性更好，需要更多内存。

📌 使用量化模型的情况： ✔ 您在CPU上运行推理，需要优化的模型。 ✔ 您的设备显存较低，无法加载全精度模型。 ✔ 您希望在保持合理准确性的同时减少内存占用。

📌 避免使用量化模型的情况： ❌ 您需要最高准确性（全精度模型更适合）。 ❌ 您的硬件有足够的显存用于更高精度的格式（BF16/F16）。

极低比特量化（IQ3_XS、IQ3_S、IQ3_M、Q4_K、Q4_0）

这些模型针对极致内存效率进行了优化，非常适合低功耗设备或内存是关键限制因素的大规模部署。

• IQ3_XS：超低比特量化（3比特），具有极致内存效率。
  • 使用场景：最适合超低内存设备，即使Q4_K也太大的情况。
  • 权衡：与高比特量化相比，准确性较低。
• IQ3_S：小块大小，实现最大内存效率。
  • 使用场景：最适合低内存设备，当IQ3_XS过于激进时。
• IQ3_M：中等块大小，比 IQ3_S 准确性更好。
  • 使用场景：适用于低内存设备，当IQ3_S限制过多时。
• Q4_K：4比特量化，具有逐块优化以提高准确性。
  • 使用场景：最适合低内存设备，当Q6_K太大时。
• Q4_0：纯4比特量化，针对 ARM设备 进行了优化。
  • 使用场景：最适合基于ARM的设备或低内存环境。

模型格式选择总结表

模型格式	精度	内存使用	设备要求	最佳使用场景
BF16	最高	高	支持BF16的GPU/CPU	减少内存的高速推理
F16	高	高	支持FP16的设备	BF16不可用时的GPU推理
Q4_K	中低	低	CPU或低显存设备	内存受限环境的最佳选择
Q6_K	中等	适中	内存较多的CPU	量化模型中准确性较好的选择
Q8_0	高	适中	有足够显存的CPU或GPU	量化模型中准确性最高的选择
IQ3_XS	非常低	非常低	超低内存设备	极致内存效率和低准确性
Q4_0	低	低	ARM或低内存设备	llama.cpp可针对ARM设备进行优化

📦 安装指南

文档未提及安装步骤，故跳过此部分。

💻 使用示例

基础用法

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "a-m-team/AM-Thinking-v1"

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto"
)

prompt = "How can I find inner peace?"
messages = [
    {"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

generated_ids = model.generate(
    **model_inputs,
    max_new_tokens=49152
)
output_ids = generated_ids[0][len(model_inputs.input_ids[0]):].tolist() 

response = tokenizer.decode(output_ids, skip_special_tokens=True)
think_content = response.split("<think>")[1].split("</think>")[0]
answer_content = response.split("<answer>")[1].split("</answer>")[0]

print (f"user prompt: {prompt}")
print (f"model thinking: {think_content}")
print (f"model answer: {answer_content}")

高级用法

文档未提及高级用法相关代码，故跳过此部分。

📚 详细文档

模型生成细节

该模型使用 llama.cpp 在提交版本 92ecdcc0 时生成。

包含的文件及详情

AM-Thinking-v1-bf16.gguf

• 模型权重以 BF16 格式保存。
• 如果您想将模型重新量化为不同格式，请使用此文件。
• 如果您的设备支持 BF16加速，此文件为最佳选择。

AM-Thinking-v1-f16.gguf

• 模型权重以 F16 格式存储。
• 如果您的设备支持 FP16，尤其是在不支持BF16的情况下，请使用此文件。

AM-Thinking-v1-bf16-q8_0.gguf

• 输出和嵌入层保持为 BF16。
• 所有其他层量化为 Q8_0。
• 如果您的设备支持 BF16 且需要量化版本，请使用此文件。

AM-Thinking-v1-f16-q8_0.gguf

• 输出和嵌入层保持为 F16。
• 所有其他层量化为 Q8_0。

AM-Thinking-v1-q4_k.gguf

• 输出和嵌入层量化为 Q8_0。
• 所有其他层量化为 Q4_K。
• 适用于内存有限的CPU推理。

AM-Thinking-v1-q4_k_s.gguf

• 最小的 Q4_K 变体，以牺牲准确性为代价减少内存使用。
• 最适合极低内存设置。

AM-Thinking-v1-q6_k.gguf

• 输出和嵌入层量化为 Q8_0。
• 所有其他层量化为 Q6_K。

AM-Thinking-v1-q8_0.gguf

• 完全 Q8 量化的模型，以获得更好的准确性。
• 需要更多内存，但提供更高的精度。

AM-Thinking-v1-iq3_xs.gguf

• IQ3_XS 量化，针对极致内存效率进行了优化。
• 最适合超低内存设备。

AM-Thinking-v1-iq3_m.gguf

• IQ3_M 量化，提供中等块大小以提高准确性。
• 适用于低内存设备。

AM-Thinking-v1-q4_0.gguf

• 纯 Q4_0 量化，针对 ARM设备 进行了优化。
• 最适合低内存环境。
• 若追求更高准确性，建议使用IQ4_NL。

测试模型

❤ 如果您觉得这些模型有用，请点击“点赞”！
帮助我测试我的由AI驱动的网络监控助手，进行量子就绪安全检查：
👉 免费网络监控器

💬 测试方法： 选择一种 AI助手类型：

• TurboLLM（GPT-4o-mini）
• HugLLM（Hugginface开源模型）
• TestLLM（仅支持CPU的实验性模型）

测试内容

我正在突破用于AI网络监控的小型开源模型的极限，具体包括：

• 针对实时网络服务进行函数调用
• 模型可以多小，同时仍能处理：
  • 自动 Nmap扫描
  • 量子就绪检查
  • 网络监控任务

🟡 TestLLM – 当前的实验性模型（llama.cpp在2个CPU线程上运行）：

• ✅ 零配置设置
• ⏳ 30秒加载时间（推理速度慢，但无API成本）
• 🔧 寻求帮助！ 如果您对边缘设备AI感兴趣，让我们合作吧！

其他助手

🟢 TurboLLM – 使用 gpt-4o-mini 进行：

• 创建自定义命令处理器，在免费网络监控代理上运行 .net 代码
• 实时网络诊断和监控
• 安全审计
• 渗透测试（Nmap/Metasploit）
• 🔑 通过登录或下载集成了AI助手的免费网络监控代理获取更多令牌

🔵 HugLLM – 最新的开源模型：

• 🌐 在Hugging Face推理API上运行

示例命令测试

1. "Give me info on my websites SSL certificate"
2. "Check if my server is using quantum safe encyption for communication"
3. "Run a comprehensive security audit on my server"
4. '"Create a cmd processor to .. (what ever you want)" 注意，您需要安装免费网络监控代理才能运行 .net 代码。这是一个非常灵活和强大的功能，请谨慎使用！

AM‑Thinking‑v1：在32B规模上推进推理前沿

• 2025-05-10 · a-m‑team

🤗 Hugging Face   |    📑 论文    |    📑 博客   

介绍

我们发布了 AM-Thinking‑v1，这是一个专注于提升推理能力的32B密集语言模型。基于Qwen 2.5‑32B‑Base构建，AM-Thinking‑v1在推理基准测试中表现出色，可与更大的混合专家（MoE）模型如 DeepSeek‑R1、Qwen3‑235B‑A22B、Seed1.5-Thinking 以及更大的密集模型如 Nemotron-Ultra-253B-v1 相媲美。

为什么需要另一个32B推理模型

大型混合专家（MoE）模型如 DeepSeek‑R1 或 Qwen3‑235B‑A22B 在排行榜上占据主导地位，但它们需要高端GPU集群。许多团队只需要适合单张显卡的最佳密集模型。AM‑Thinking‑v1 填补了这一空白，并且完全基于开源组件：

• 在AIME’24/’25和LiveCodeBench上优于DeepSeek‑R1，尽管参数数量仅为 Qwen3‑235B‑A22B 的 1/7，但性能接近。
• 基于公开可用的 Qwen 2.5‑32B‑Base 构建，以及RL训练查询。
• 表明通过精心设计的后训练管道（SFT + 双阶段RL），可以从32B密集模型中挤出旗舰级的推理能力。
• 可在单张A100 - 80GB上部署，具有确定性延迟，无MoE路由开销。

使用场景

代码生成

PROMPT :
write a python script for a bouncing red ball within a triangle, make sure to handle collision detection properly. make the triangle slowly rotate. implement it in python. make sure ball stays within the triangle

逻辑推理

写作

🔧 技术细节

后训练管道

为了实现强大的推理能力，AM‑Thinking‑v1经过了精心设计的后训练管道。以下是将基础模型转化为高性能推理器的关键阶段：

步骤1 – 冷启动SFT 我们从开源的 Qwen 2.5‑32B‑Base 开始，在数学、代码和开放域聊天的混合训练数据集上进行广泛的有监督微调。这使模型具备“先思考后回答”的行为模式，并赋予其初始的推理能力。

步骤2 – 通过率感知的数据筛选 在进行任何强化学习之前，对SFT模型在每个面向数学和代码的训练查询上进行评估。为每个项目记录通过率；仅保留 0 < 通过率 < 1 的项目。实际上，我们丢弃了模型已经掌握和完全失败的问题，将学习集中在真正有信息价值的案例上。

步骤3 – 强化学习 我们采用两阶段GRPO方案：阶段1仅在数学和代码查询上进行训练。收敛后，阶段2开始，移除模型在阶段1中100%正确回答的所有查询，并调整关键超参数，如最大生成长度和学习率。

⚠️ 局限性

虽然AM‑Thinking‑v1在纯语言推理和开放域聊天方面表现出色，但尚未针对结构化函数调用或工具使用工作流程进行训练，这限制了其在必须对外部系统采取行动的代理式应用中的实用性。 提高模型遵循复杂指令的能力也是我们未来工作的一个重要方向。 此外，我们的安全对齐仍处于早期阶段，因此需要更严格的红队测试以减少潜在危害。

📄 许可证

本项目采用 apache-2.0 许可证。

📚 引用

a-m-team是贝壳（Ke.com）的内部团队，致力于探索AGI技术。 如果您觉得我们的工作有帮助，请随意引用。

@misc{ji2025amthinkingv1advancingfrontierreasoning,
      title={AM-Thinking-v1: Advancing the Frontier of Reasoning at 32B Scale}, 
      author={Yunjie Ji and Xiaoyu Tian and Sitong Zhao and Haotian Wang and Shuaiting Chen and Yiping Peng and Han Zhao and Xiangang Li},
      year={2025},
      eprint={2505.08311},
      archivePrefix={arXiv},
      primaryClass={cs.CL},
      url={https://arxiv.org/abs/2505.08311}, 
}