大模型手册

外观

框架与工具选型

本页速览 按"模型库→训练→推理→编排→向量库→评估"六层拆解 LLM 工具链，每层给出场景驱动的选型决策表，并给出"别被框架绑架"的选型原则与三条自研判断标准。

框架与工具选型 ​

工具选型的本质是为你的场景匹配复杂度：框架解决 80% 的通用问题，代价是 20% 的灵活性；选错框架的代价不是"多装一个包"，而是整个团队被绑架进它的设计里。

本文把 LLM 工具链拆成六层，每层给出场景→推荐的决策表。看完你该得到的是一个"自己心里有数"的选型地图，而不是"谁火选谁"。开源生态全景见Llama 与开源生态。

一、分层工具地图 ​

┌─────────────────────────────────────────────┐
│ 应用层     Dify / 自研应用                     │
├─────────────────────────────────────────────┤
│ 编排层     LangChain / LlamaIndex             │
├─────────────────────────────────────────────┤
│ 评估层     lm-eval-harness / OpenCompass / RAGAS │
├─────────────────────────────────────────────┤
│ 推理层     vLLM / SGLang / TensorRT-LLM / llama.cpp │
├─────────────────────────────────────────────┤
│ 训练层     transformers / PEFT / TRL / DeepSpeed │
│            Megatron-LM / LLaMA-Factory / Axolotl  │
├─────────────────────────────────────────────┤
│ 模型与数据层  Transformers / Datasets / Tokenizers  │
└─────────────────────────────────────────────┘

选型的通用原则（下面每层都会用到）：

  1. 默认最薄：能用标准库/API 解决的，不引框架。
  2. 先跑通再抽象：第一版用最直接的方式实现，出现重复需求再引入抽象。
  3. 可替换性：核心模块（如向量库、推理引擎）封装成接口，方便换。

二、模型与数据层：几乎必选 ​

工具定位何时选
Hugging Face transformers模型加载/推理/训练的标准库几乎所有场景（事实标准）
datasets数据集加载与预处理训练/微调必经
tokenizers高性能分词自定义分词器时

transformers 的 from_pretrained 一行加载模型、统一 AutoModel/AutoTokenizer 接口，让"换模型"从改代码变成改一行参数——这是整个生态的基石。没有特殊理由，模型层不需要选型，直接用 transformers。

三、训练层：按规模与方式选 ​

工具定位适用场景不适用
transformers Trainer单卡/小规模训练小模型微调、教学大规模并行训练
PEFTLoRA/QLoRA 等参数高效微调绝大多数微调任务全参微调
TRLSFT/DPO/PPO 训练器指令微调与对齐自研训练循环
LLaMA-Factory一键式平台快速实验、多种方法切换深度定制
Axolotl配置驱动训练复现配置、批量实验需要动态逻辑
DeepSpeed分布式训练引擎（ZeRO）大模型多卡训练小模型单卡
Megatron-LMNVIDIA 大规模训练（张量并行等）百亿级+训练常规微调

选型决策表（训练）：

你要做什么？
├─ 微调 7B 以下、单卡可跑 → PEFT/TRL 或 LLaMA-Factory
├─ 微调 13B+、需要量化省显存 → QLoRA（bitsandbytes）+ PEFT
├─ 预训练/全参 70B+ 多卡 → DeepSpeed（ZeRO-3）或 Megatron-LM
└─ 对齐（RLHF/DPO）→ TRL（DPOTrainer）或自研 + trlx 等

训练工程化的三条纪律 ​

框架之外，训练环节最常被忽视的是工程纪律：

纪律做法解决什么问题
实验可复现固定随机种子 + 记录完整超参（含数据版本、框架版本）两个实验对不上结论
checkpoint 管理定期保存并按 eval 分数保留最优过拟合/事故后回滚
训练日志记录每个 step 的 loss/梯度范数/学习率定位发散、判断收敛

训练日志的价值在离线复盘：一次"微调后变笨"的排查，靠的就是训练日志里的 eval loss 拐点。

训练选型的现实建议

能用 PEFT/TRL 解决的问题不要引入 DeepSpeed。 分布式训练的复杂度（节点通信、梯度同步、混合精度）是数量级上升的。先问自己：单卡 + QLoRA 是否已经够用？完整流程见微调实战：LoRA 全流程。

四、推理层：吞吐与延迟的工程战场 ​

推理引擎直接决定部署成本与用户体验。指标口径（TTFT/TPOT/吞吐）见部署与服务化。

引擎特点适用场景
vLLMPagedAttention、continuous batching、OpenAI 兼容 API生产默认首选
SGLangRadixAttention、结构化输出优化高并发、复杂 prompting、工具调用
TensorRT-LLMNVIDIA 深度优化、TensorRT 编译NVIDIA 集群、极致吞吐
llama.cpp（GGUF）CPU/小内存可跑、纯本地本地/边缘、个人使用、离线
Ollama包一层 llama.cpp，一键运行本地体验、教学演示
transformers 原生推理简单但低效（无 batching 优化）原型、教学

选型决策表（推理）：

场景推荐原因
生产 API 服务（GPU）vLLM 或 SGLangcontinuous batching 吞吐高、API 兼容
需要函数调用/JSON 强约束SGLang / vLLM（structured output）原生支持约束解码
本地电脑/无独显llama.cpp / Ollama（GGUF 量化）低资源可跑
NVIDIA 大规模集群TensorRT-LLM极致性能（但构建复杂）
教学/原型transformers 或 Ollama简单直观

推理引擎的取舍：没有银弹 ​

需求vLLMSGLangTensorRT-LLMllama.cpp
开箱即用（OpenAI 兼容 API）★★★★★★★★★（需另包服务）
高并发吞吐★★★★★★★★★★
结构化输出/工具调用★★★★★★★★
低资源（CPU/小内存）★★★★★★
社区活跃度/升级速度★★★★★★★★★★

选型结论：默认 vLLM；高并发 + 复杂 prompt 场景试 SGLang；NVIDIA 集群且追求极致吞吐再考虑 TensorRT-LLM；个人/边缘场景用 llama.cpp。不要同时上两套引擎——推理层是运维成本最高的地方，保持单一引擎是巨大的简化。

不要在生产用 transformers 裸推理

它没有 continuous batching 与 KV cache 优化，同样吞吐的显存/GPU 需求是 vLLM 的数倍。"先在 transformers 里试通了模型" 与 "上线服务" 之间，必须过一道推理引擎的转换。

五、应用编排层：LangChain / LlamaIndex / Dify ​

工具定位优势劣势
LangChain通用编排框架（链、Agent、工具）生态大、组件全抽象层厚、升级频繁
LlamaIndex数据接入与 RAG 深度优化RAG 组件最成熟偏数据、Agent 弱些
Dify低代码应用平台（可视化）非开发者也快、含 RAG/工作流深度定制受限
自研自己写调用逻辑完全可控、无版本绑架从零实现、维护成本

选型决策表（编排）：

你的团队与技术形态？
├─ 纯后端工程团队、要长期维护 → 自研轻量封装（最稳）
├─ 快速验证 RAG/多 Agent 原型 → LlamaIndex 或 LangChain
├─ 业务/产品人员搭应用 → Dify
└─ 已被某框架代码绑架 → 评估"最小重写路径"，不要继续堆

Agent 与工作流：编排层的下一个阶段 ​

当需求从"单轮问答"升级到"多工具、多步骤"时，编排层的重心从 RAG 转向 Agent 与工作流。工具调用机制见基于 LLM 的 Agent。本层的选型要点：

方案形态适合
LangGraph图状工作流（LangChain 官方）需要精细控制状态的复杂流程
AutoGen / CrewAI多 Agent 协作多角色分工实验
自研事件循环自己管理"调用 LLM → 调工具 → 回填"循环生产长期维护、完全可控
平台（Dify/Coze 等）可视化编排非工程团队快速上线

Agent 是复杂度放大器

Agent 循环（多步推理 + 工具调用）的失败面比单轮 RAG 大得多：工具调用格式错、循环失控、成本失控。先问自己：必须用 Agent 吗？ 很多"Agent 需求"用"工作流 + 工具函数"即可解决，复杂度低一个量级。

"别被框架绑架"——最贵的隐性成本

框架的两个隐性成本：版本漂移（API 频繁变更，锁定后升级难）与抽象泄漏（出问题时你必须读框架源码才能排查）。判断标准：你为框架付出的调试时间，是否超过了框架为你省下的开发时间？ 越接近应用核心的代码，越值得自研。

六、向量库层：见 RAG 实战 ​

选型维度的完整决策见 RAG 实战 第三节。速览：

向量库形态场景
FAISS库原型、离线、单机
pgvectorPG 插件已有 PG、需要事务一致性
Qdrant / Milvus独立服务生产级、亿级向量、混合检索
Chroma嵌入式本地教学、轻量

七、评估层：评测工具 ​

工具定位特点
lm-evaluation-harness通用基准评测（MMLU/GSM8K 等）社区标准、任务全
OpenCompass中文友好、多模型对比报告可视化好
RAGASRAG 专项评测忠实度/相关性/答案相关
自建流水线业务 golden set不可替代，见评估实战

评测工具不是评估体系

lm-eval 只是"跑基准的脚本"，真正的评估体系 = 你的 golden set + judge + 回归门禁 + 线上反馈。工具负责执行，体系负责解释。参见评估实战。

八、总选型速查表 ​

层你的场景推荐（首选项）
模型库任何transformers
微调单卡、7B 以下PEFT/TRL 或 LLaMA-Factory
分布式训练70B+、多卡DeepSpeed / Megatron-LM
生产推理GPU 服务vLLM
本地推理个人/边缘llama.cpp / Ollama
应用编排快速原型LangChain / LlamaIndex
应用编排长期维护自研轻量封装
向量库原型FAISS
向量库生产Qdrant / Milvus / pgvector
评测通用基准lm-eval-harness / OpenCompass
评测业务回归自建 golden set 流水线

一次选型的完整推演（示例） ​

一个团队从零搭一个中文问答系统，选型推演如下：

决策点场景结论
模型中文、预算有限开源 7B（Qwen 系）
微调先试提示暂不微调，PEFT 备选
推理生产 API 服务vLLM
编排团队是后端工程师自研轻量封装
向量库数据量小、已有 PGpgvector
评测需要建立体系自建 golden set + lm-eval 回归

选型是"一系列权衡的组合"——任何单点的"最好"都可能被其他环节抵消（比如选了 vLLM，但编排层被某框架锁死，整体依然难受）。

九、实验管理与可观测性 ​

工具链的"最后一层"是实验管理与观测：没有它，前八层的产出都无法沉淀。

工具定位选型要点
Weights & Biases训练实验追踪训练曲线、超参对比、团队共享
MLflow实验 + 模型注册 + 部署追踪模型版本管理、与工程链路集成
日志/追踪（OpenTelemetry 等）线上请求追踪请求级延迟、token 用量、错误归因

选型结论：训练实验用 W&B 或 MLflow 其一；线上服务接入标准日志与追踪。实验管理不是"可选优化"，而是团队协作与回归排查的基础设施——所有数字（评估实战）都需要被记录才能被信任。

十、原则总结：选型三问 ​

每次选型前，问自己三个问题：

  1. 我真的需要这个框架吗？ 用标准库或十行代码能解决，就别引。
  2. 它解决的是我的问题，还是它自己的问题？ 框架解决的问题域与你越重合，越值得用。
  3. 三年后我能离开它吗？ 越难离开（锁死），越要评估自研或封装。

框架是负债，能力是资产

工具会过时（LangChain 的 API 一年变三次，vLLM 每季度加新特性），但你对"检索→生成""批处理→吞吐"这些原理的理解不会过时。选型时优先选"教你原理"的工具，而不是"替你思考"的工具。这个视角也适用于更完整的资源清单精选资源清单。

延伸阅读 ​

参考资料 ​