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}, 
}