LLM 模型命名拆解
LLM 的模型名稱常常把參數量、量化方式、架構、訓練方式與安全對齊狀態壓縮在同一串字母數字中。這篇貼文把這些縮寫拆開，讓本機部署時可以先看懂模型在說什麼，再決定能不能跑、該怎麼跑。
常見命名片段
30B/120B：總參數量，先判斷模型權重是否有機會塞進記憶體A3B：activated parameters，MoE 每步實際啟用的參數量E2B：effective parameters，透過條件載入與 cache 讓有效常駐負載下降Q4_K_M/Q5_K_M：GGUF / llama.cpp 生態的量化格式，直接影響檔案大小與可跑硬體QAT/PTQ：訓練感知量化 vs 訓練後量化MTP：Multi-Token Prediction；若不是 native MTP，通常要靠 speculative decoding 類方法。frozen-multi-token-prediction 補了一個 production 例子：Google 把 MTP head 接到 frozen Gemini Nano backbone，用 verification 保持輸出一致，同時減少手機端延遲、能耗與 memory footprint。Instruct/Reasoning/Thinking/Code：微調目標或使用情境Uncensored/NSFW/Abliterated：解除部分安全對齊限制的版本
實務意義
- 名稱先告訴你模型是 dense 還是 MoE，以及算力與記憶體的壓力在哪裡
- 量化格式決定本機推理工具鏈能不能直接吃，尤其是 GGUF / llama.cpp 路線
Instruct之類後綴只是提示，不代表一定適合所有任務NSFW/Uncensored類標記代表對齊策略改變，部署與使用要更小心
相關頁面
- localmachine-gateway — 地端模型部署與模型服務基線
- frozen-multi-token-prediction — Google Research 的手機端 MTP 推論加速案例
- edge-ai-harness — 邊緣 AI 落地時的硬體與整合限制
- rtx-spark-edge-ai-box — 以硬體可跑性來理解模型命名與選型