大模型相关知识学习整理

分割线

预训练-pre_train

数据处理

TODO

分割线

后训练-post_train

拿到 safetensors 之后要做的事

微调-fine_tune

LoRA

另一篇文章有提到: LoRA微调训练和量化

量化-quantization

另一篇文章有提到: LoRA微调训练和量化

量化节省与精度对比

https://huggingface.co/mradermacher/Qwen3.5-2B-GPT-5.1-HighIQ-INSTRUCT-i1-GGUF
https://huggingface.co/Bedovyy/dasiwaWAN22I2V14B-GGUF/tree/main/HighNoise

有时候找模型会遇到不同精度的量化版本, 以 7B 模型为例, GGUF 量化

格式典型大小精度损失推理速度提升适用场景
FP16~14GB无损基准速度训练、基准推理
q8_0 (8bit)~7.5GB<0.5%~1.3×高精度服务器推理
q6_k (6bit)~6.7GB~0.5–1%~1.5×高精度推理，接近无损
q5_k_m (5bit混合)~4.5GB~1–3%~1.8×推荐的通用量化方案
q4_k_m (4bit混合)~4.4GB~3–5%~2.0–2.2×主流移动端/轻量服务器部署
q4_0 (原始4bit)~3.8GB~8–10%~2.5×基础推理，精度下降明显
q3_k_m (3bit混合)~3.0GB~5–8%~3×移动端极限压缩
q2_k (2bit)~2.7GB>10%~3.5×极端压缩，精度损失大

量化方法和产物

标记全称/含义特点适用场景
QQuantized（量化）表示该模型是量化版本，后缀决定具体策略（如 q4_0、q4_k_m）所有量化模型的通用前缀
KK-quant（分组量化）改进的量化方法，分组存储权重，精度更好主流推荐，如 q4_k_m、q5_k_m
MMixed（混合精度）不同部分使用不同 bit 数量，兼顾精度和体积常见于 q4_k_m、q5_k_m，平衡最佳
LL-quant（低秩优化）针对部分权重做低秩近似，进一步压缩更小体积，但精度略有下降
IQInteger Quantization（整数量化）使用整数存储，推理速度更快新方案，适合 CPU/GPU 高速推理
0原始量化版本最基础的量化实现，速度快，但精度损失较大早期量化方案，适合极限压缩或测试
SSuper-block 分组策略在量化时使用更大的分组（block size），提升精度常见于 q4_k_s，比 _0 精度更好
S#Super-block + 数字（如 S2, S3）表示不同的分组大小或策略，数字越大分组更细，精度更高高精度量化，适合需要更好质量的推理

模型发布-huggingface

一般是发到 Huggingface, 部分国内模型会发到魔搭

仓库名称示例核心存储内容角色定位适用场景/工具
*-LoRAadapter_model.safetensors (几十MB)中间产物 (轻量级)二次微调、PEFT 动态加载、研究员交流
*-Fullmodel.safetensors (几个GB)标准产物 (工业级)服务器部署 (vLLM)、Transformers 库加载
*-GGUF*.gguf (不同位宽)分发产物 (消费级)本地离线运行 (Ollama, llama.cpp, LM Studio)

为了让 Hugging Face 自动识别模型之间的血缘关系（如你图中看到的 Tree 结构），你需要在每个仓库的 README.md 顶部配置 base_model 标签。

  1. LoRA 仓库 (*-LoRA)

    声明它是基于哪个原始大模型微调的。

    ---
    base_model: Qwen/Qwen3.5-4B
    library_name: peft
    tags:
      - lora
      - latex
    ---

  2. 完整版仓库 (*-Full)

    它是合并后的模型，通常依然指向原始基座模型。

    ---
    base_model: Qwen/Qwen3.5-4B
    tags:
      - merged
      - latex
    ---

  3. 量化版仓库 (*-GGUF)

    关键点：它的基座应该是你微调合并后的那个仓库。

    ---
    base_model: Weidows/Qwen3.5-4B-LaTeX
    tags:
      - gguf
      - quantization
    ---

分割线

推理部署-inference

推理框架选择

https://github.com/Mega4alik/ollm

速度太慢了, 大部分场景都不适合

https://github.com/GeeeekExplorer/nano-vllm

看起来更新速度不太快, 支持不行, pass

https://docs.vllm.ai/en/stable/

推理加速

核心思路：在资源受限的机器上，推理加速通常是 “减小模型规模”（量化/剪枝/蒸馏）与 “高效执行”（选择合适的框架/内核） 的结合。

主流推理框架对比

框架 / 方法适用场景核心优势推荐配置参数备注
vLLMLLM 大语言模型服务（如 ChatGPT）PagedAttention：通过分页管理 KV Cache，解决显存碎片化问题；支持 Speculative Decoding（推测解码）。在长上下文场景下（如 30K token）表现优越。--max-num-batched-token (控制批处理大小)，--kv-cache-dtype (设置 KV 缓存类型)[[1]][[2]]在小显存机器上，优于 HuggingFace Transformers 2-4 倍吞吐量[[3]][[4]]
OpenVINOIntel CPU / GPU / NPU (如 Xeon, Arc)深度优化：针对 Intel 硬件的异构执行、自动 batch、性能 Hint (Latency/Throughput)。ov::hint::performance_mode(ov::hint::PerformanceMode::THROUGHPUT)对于 CPU 推理（如 ResNet, BERT），往往优于 pure PyTorch/TensorRT[[5]]
TensorRTNVIDIA GPU (A100, H100, RTX)极致加速：张量核心 + FP8/INT8 加速；支持混合精度。--precision (FP8/INT8) [[6]]对于视觉模型 (YOLO, Stable Diffusion) 常见首选[[7]][[8]]
ONNX Runtime跨平台部署 (CPU, GPU, NPU, Edge)通用性：支持 CUDA、DirectML、OpenVINO EP。ExecutionProvider 选择 (如 CUDAExecutionProvider)[[9]]适合 Edge 设备（如 Jetson, Graviton）[[10]]

核心加速技术手段

技术加速原理典型收益适用场景参考
PagedAttention类似 OS 虚拟内存分页，按需分配 KV Cache，减少显存碎片。显存利用率近 100%，解决长上下文卡死问题[[17]]超长上下文 LLM (30K token 以上)vLLM 独有技术[[18]]
Speculative Decoding预先生成多个候选 token，提前并行计算，减少解码串行瓶颈。吞吐量提升 2-4x需要高 QPS 的聊天机器人vLLM 中实现[[19]]
自动 Batch动态聚合多个推理请求，提高 GPU 利用率。吞吐量提升 1.5x-3x低频请求的 API 服务OpenVINO & vLLM 支持[[20]]

常见误区

  1. “多加一个 GPU 就能跑大模型”：在显存碎片严重时，即使是 2 块卡也可能卡死，PagedAttention 是关键
  2. “只要量化就行”：直接 INT8 量化有时会导致 LLM 输出乱码，建议先使用 W4A4 (GPTQ) 或者 INT8 + W8A8 (vLLM)

分割线

借物表

[1]: LLM