本页速览 scikit-learn、PyTorch、vLLM 还是云 API？本文从数据形态、团队与部署环境出发，给出表格数据、深度学习、大模型三大场景的框架选型对比表，以及一份可勾选的决策清单。

框架与工具怎么选

一句话结论：框架选型不是选"最流行的"，而是选"最适配当前问题、团队与部署环境的"。机器学习工具生态早已过了"人人只有一套工具箱"的时代——今天的选择多到足以让人选择困难，而大多数"选错框架"的失败，根源不是工具本身不好，而是先定了答案、再倒推问题。

本文把选型拆成三个决策层：数据形态决定工具家族，团队能力决定工具复杂度的上限，部署环境决定工具的"最后一公里"。按这个顺序往下走，大部分纠结会自然消失。

一、选型总原则：先问问题，再选工具

1. 三个真正的决策维度

流行度、Github star 数、招聘需求量——这些是结果指标，不是决策依据。真正决定选型的只有三个维度：

                ┌─────────────────────────────────────┐
                │           你要解决的问题             │
                └─────────────────────────────────────┘
                          │            │            │
              ┌───────────▼─┐   ┌───────▼───────┐   ┌▼──────────┐
              │  ① 数据形态  │   │  ② 团队能力   │   │ ③ 部署环境 │
              │  表格/文本/  │   │  算法背景/     │   │ 离线/在线/  │
              │  图像/时序   │   │  工程能力/     │   │ 云/边缘/    │
              │             │   │  时间预算      │   │ 资源/合规   │
              └─────────────┘   └───────────────┘   └───────────┘
                          │            │            │
                          └─────►  工具家族  ◄──────┘

数据形态：决定用哪个"工具家族"。表格数据 → sklearn/GBDT 系；图像/语音/文本 → 深度学习框架；非结构化大规模文本 → 大模型生态。硬要用深度学习框架去碾表格数据、或用树模型去处理图像，都是与数据形态为敌。
团队能力：决定工具复杂度的上限。三个人、两周交付的团队，不应该直接上分布式训练框架；一个 20 人算法团队则完全有理由维护自建训练平台。工具是团队的函数，不是反向的。
部署环境：决定"最后一公里"。只能跑 CPU 的客户现场、必须离线推理的合规场景、峰值波动的线上服务——这些约束会直接淘汰一批"看起来很美"的框架。

2. "按流行度选"为什么是陷阱

ChatGPT 火了就人人都想上 Transformer，不是因为你解决了文本问题，而是因为新潮；GitHub 上 star 最多的框架，往往只说明它最容易写 hello world，不代表它最适合你的生产约束。历史上 TensorFlow 曾凭借先发优势占据绝对主流，而今天 PyTorch 反超成为事实标准（第三节详述）——生态地位会在三五年内翻转，而你的模型要上线三五年。把"趋势"当"标准"的人，会发现自己总在重写代码。

正确的姿势是给三个维度各打一个分，然后让工具家族浮出水面：

你面对的问题	首选工具家族	备选/混用
表格数据、结构化特征、中小规模	scikit-learn + GBDT 系（XGBoost/LightGBM/CatBoost）	AutoML 工具做基线
非结构化数据（图像/音频/文本）	PyTorch 系	TensorFlow/Keras、JAX
大模型推理与微调	Hugging Face + vLLM / 云 API	Ollama（本地单机）
特征工程、管线编排	scikit-learn Pipeline / Polars / 特征平台	直接写业务脚本

选型的最小可行动作

不要做"框架调研 PPT"。花半天时间，用待选框架各写一个最小可用原型，跑你的真实数据、在你的真实部署环境里验证，选那个"原型最快跑通、工程上最不难受"的。一次 8 小时的动手实验，胜过三周的趋势报告。

二、表格数据场景：sklearn 与 GBDT 三巨头

表格数据（结构化数据、特征表）仍然是工业界占比最大的机器学习问题——风控、营销、供应链、运维预警几乎都是表格问题。这里的选型非常成熟，争议也最小。

1. scikit-learn：生态与流程，不是精度天花板

scikit-learn 的价值不在单模型精度，而在它把"建模全流程"做成了统一 API：

python

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler, OneHotEncoder
from sklearn.compose import ColumnTransformer
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import cross_val_score

pipe = Pipeline(steps=[
    ("preprocess", ColumnTransformer([
        ("num", StandardScaler(), ["age", "income"]),
        ("cat", OneHotEncoder(), ["city", "channel"]),
    ])),
    ("model", RandomForestClassifier(n_estimators=200)),
])

scores = cross_val_score(pipe, X_train, y_train, cv=5, scoring="roc_auc")

fit / predict / transform 三件套 + Pipeline + 交叉验证 + GridSearchCV，构成了一个几乎不可能写错的评估流程。它还是整个 Python ML 生态的协议层——XGBoost、LightGBM 都提供 sklearn 兼容接口，这意味着你能把 GBDT 无缝塞进自己的 Pipeline 里做模型对比。

sklearn 的短板也很明确：原生实现偏慢、大数据上吃力（部分算法可 n_jobs 并行但仍吃内存）、没有 GPU 支持、深度模型（MLP）很弱。所以它的正确用法是流程骨架 + 基线模型 + 与 GBDT 混用。

2. GBDT 三巨头：精度、速度、易用性的三角博弈

梯度提升决策树（Gradient Boosted Decision Trees，机制详见树模型与集成学习）是表格数据的天花板。XGBoost、LightGBM、CatBoost 三者数学同源（都是提升树），工程实现差异巨大：

维度	XGBoost	LightGBM	CatBoost
提出者/年份	陈天奇等，2014	微软，2017	Yandex，2017
核心加速策略	预排序 + 近似直方图	直方图 + 叶子生长（leaf-wise）	对称树 + Ordered Boosting
训练速度	快（hist 模式下更快）	最快，内存占用最低	中（GPU 上很快）
精度表现	充分调参后极强，稳定	与 XGBoost 相近，小数据略逊	类别特征多时占优，抗过拟合
类别特征	需自行编码	原生支持（category dtype）	原生支持最佳，无需编码
缺失值处理	自动学习分裂方向	自动处理	自动处理
易用性	中（超参多）	中	最省心（默认参数就很能打）
生态广度	极广（R/Julia/Scala/Spark）	广（Python/R/C++）	较广（Python/R/Java）
代表性用户	Kaggle 早期霸主	阿里、美团等大流量场景	推荐、搜索、高基数类别场景

三个印象深刻的工程差异：

LightGBM 的 leaf-wise 生长是速度来源也是陷阱。它每次分裂选增益最大的叶子，训练更快、更能逼近最优，但树深不设限时容易过拟合（num_leaves 默认 31，需要配合 max_depth 与 min_data_in_leaf）。XGBoost 的 level-wise 逐层生长更保守，因而在小数据集上往往更稳。

CatBoost 的对称树（oblivious trees）让整棵树每层用同一特征分裂，结构简单、天然抗过拟合，且推理速度极快；加上 Ordered Boosting 缓解预测偏移，使它对"高基数类别特征 + 样本量不大"的场景几乎是碾压级选手——特征工程都省了，直接用原始类别列：

python

from catboost import CatBoostClassifier

model = CatBoostClassifier(iterations=500, learning_rate=0.05, verbose=0)
model.fit(X_train, y_train, cat_features=["city", "device_type"])  # 直接传类别列名

XGBoost 的历史地位：它是把 GBDT 变成工业标准的那一个，正则化目标、列采样、GPU 支持一应俱全，Spark 生态里 XGBoostClassifier 至今是大数据训练的主力。如果你的团队要接 Spark、要跑多语言，XGBoost 的生态半径最宽。

3. 结论：表格场景怎么落地

python

# 一套推荐的最小流程：先 sklearn 基线，再 GBDT 进阶，最后用 AutoML 兜底
from sklearn.linear_model import LogisticRegression
from lightgbm import LGBMClassifier

baseline = LogisticRegression(max_iter=1000)          # ① 可解释基线
advanced = LGBMClassifier(n_estimators=1000,          # ② 精度主力
                          learning_rate=0.05,
                          num_leaves=64,
                          n_jobs=-1)

实战口径

样本量 < 1 万、追求可解释性：sklearn（逻辑回归/随机森林） 就够，别过度工程化；
1 万 ~ 百万级表格数据、要精度：LightGBM（默认）或 XGBoost（要 Spark/调参深挖时）；
类别特征极多、不想做特征工程：CatBoost；
不知道怎么选：三者都放进一个 sklearn Pipeline 里交叉验证一把，谁赢用谁——一天内就能出结论。调参的细节见超参数调优实践。

三、深度学习场景：PyTorch vs TensorFlow vs JAX

进入非结构化数据（图像、语音、文本、视频），就是深度学习框架的天下。今天这个赛道的格局，是过去十年"研究驱动 vs 工业驱动"博弈的结果。

1. 三家定位

维度	PyTorch	TensorFlow	JAX
提出者	Meta（原 Facebook AI）	Google	Google Research
首个开源	2017	2015（2019 起 TF2）	2018
计算图	动态图（define-by-run）	动态图（TF2 eager）+ 静态图导出	函数式 + JIT（`jax.jit`）
编程范式	命令式，贴近 Python	高层 Keras API 简单，底层复杂	纯函数式，不可变、可组合
调试难度	最低（Python 原生报错）	中（API 层多、版本割裂）	高（XLA 编译报错晦涩）
生态	事实标准：HF、Lightning、论文复现	生产部署、移动端、TPU	研究、RL、大规模科学计算
生产部署	TorchServe / ONNX / 服务化	TF Serving / TFLite 成熟	无官方成熟服务方案
上手难度	中（先学 autograd + DataLoader）	低（Keras 一行一个模型）	高（函数式思维）
主要使用者	学术界绝大多数、工业界主流	存量老系统、移动端、TPU 用户	DeepMind 系、RL/科研前沿

一个最小对比，感受三家写"线性层 + 训练"的气质的差异：

python

# PyTorch：命令式，想 print 就 print，想断点就断点
import torch
import torch.nn as nn

model = nn.Linear(10, 2)
opt = torch.optim.SGD(model.parameters(), lr=0.01)
for xb, yb in dataloader:
    loss = nn.functional.cross_entropy(model(xb), yb)
    loss.backward()
    opt.step()
    opt.zero_grad()
    print(loss.item())  # 调试就是这么自然

python

# JAX：函数式 + 显式变换，pip install jax
import jax, jax.numpy as jnp
from jax import grad, jit

def loss_fn(params, x, y):
    pred = x @ params["w"] + params["b"]
    return jnp.mean((pred - y) ** 2)

params = {"w": jnp.zeros((10, 2)), "b": jnp.zeros(2)}
grads = jit(grad(loss_fn))(params, xb, yb)   # jit 编译、grad 求导、vmap 批处理

2. 为什么 PyTorch 成了事实标准

这个问题的答案，是深度学习工程史里最值得记住的一课：

① 动态图契合研究迭代。 2017 年 PyTorch 出现时，TensorFlow 1.x 还是"先建静态图、再在 session 里执行"的难受模型——调试一个图错误要过一遍编译层。PyTorch 的"define-by-run"让代码执行顺序就是计算图构造顺序，print 能看到中间张量，pdb 能进到 loss 内部。对每天要实验十次的科研人员，这是降维打击。

② 论文复现生态滚雪球。 顶级会议论文官方代码从 2018 年起大规模转向 PyTorch；Hugging Face 的 Transformers 选择 PyTorch 作为首选后端，等于把整个 NLP 领域搬了过来。复现别人的模型"pip install 即跑"成了 PyTorch 的生态护城河，而这个护城河反过来又逼着新论文继续用 PyTorch——自增强循环一旦形成，后来的技术再好也难以撼动。

③ 工业界反哺完成闭环。 2020 年前后"PyTorch 只能研究、不能生产"的质疑，随着 torch.compile（编译加速）、TorchServe、torch.onnx.export、TensorRT 集成、以及各大厂自研推理引擎（如 vLLM 内部就用 PyTorch 生态）逐一瓦解。PyTorch 2.x 之后的性能已与静态图方案无本质差距，而"研究代码直接进生产"的巨大便利，让工业界也倒向了 PyTorch。

别因此踩踏 TensorFlow

PyTorch 的主流地位不意味着 TensorFlow 没有存在价值：存量系统、移动端/嵌入式（TFLite）、TPU 上云、以及大量线上已运行的 Keras 服务，短期内都不会迁移。如果你的团队要维护的是这些系统，继续用 TensorFlow 完全合理——技术选型服从存量资产与团队存量技能，不服从社区情绪。JAX 则在强化学习、物理模拟、大规模科学计算等前沿方向持续发光，做这类研究的团队值得投入学习。

3. 什么时候需要换框架的"信号"

你的训练要跑在 TPU 上 → 认真考虑 JAX（原生最优）或 TensorFlow；
你的模型要进 iOS/Android/嵌入式 → 认真考虑 TensorFlow Lite（或 PyTorch 的 ExecuTorch，还在成熟中）；
你要大规模分布式训练 100B+ 参数模型 → JAX/DeepSpeed 系（PyTorch 也支持，但 JAX 在 HPC 领域更顺）；
以上都没有 → PyTorch 是默认答案，直接开始，详见深度学习基础与CNN 案例。

四、大模型场景：Hugging Face、vLLM、Ollama 与云 API

2023 年之后，选型问题新增了一个重量级场景：大语言模型（LLM）。这里不是"框架"之争，而是"自托管 vs 云 API"的架构决策，配套工具链也已经定型。

1. 工具链地图

工具	定位	典型用法	适合人群
Hugging Face Transformers	模型库 + 统一微调/推理 API	`pipeline()` 一行跑模型；`Trainer` 微调	几乎所有要用开源模型的人
Hugging Face Hub	模型权重托管与下载	拉取 Llama、Qwen、DeepSeek 等权重	所有人
vLLM	高吞吐 LLM 推理引擎（PagedAttention）	把开源模型部署成 OpenAI 兼容服务	自托管服务的生产环境
Ollama	本地一键跑模型	`ollama run qwen2.5:7b`，开箱即用	个人/原型/离线单机
云 API	商业模型即服务	OpenAI、Anthropic、Google Gemini、DeepSeek、Qwen 等	快速上线、无 GPU 团队

2. 三个工具，三种姿势

Hugging Face Transformers 是开源模型世界的"统一 API"。它做的事和 sklearn 之于传统 ML 异曲同工：把成千上万个架构（BERT、Llama、Qwen、Mistral……）收敛到同一套接口下：

python

from transformers import pipeline

# 一行推理：自动下载模型、加载 tokenizer、跑生成
summarizer = pipeline("summarization", model="facebook/bart-large-cnn")
print(summarizer("你的长文本……", max_length=100)[0]["summary_text"])

训练侧用 Trainer 封装了训练循环、梯度累积、混合精度、checkpoint，微调一个开源模型（如对领域数据做 SFT，机制见大语言模型）通常是几百行代码以内的事。只要走"开源模型路线"，Hugging Face 就是默认入口，没有之一。

vLLM 解决的是"模型能跑"和"模型跑得动"之间的鸿沟。它用 PagedAttention 优化 KV cache 显存、支持连续批处理，单卡吞吐可比朴素实现高数倍，且自带 OpenAI 兼容接口——这意味着业务代码可以先对 OpenAI 写，再无缝切换到自托管服务：

python

# vllm 部署后，客户端与调用云 API 完全同构
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "你好"}],
)

Ollama 是本地体验的入口：下载、ollama run、完事。它把"跑一个大模型"的复杂度降到"跑一个 Docker 容器"的量级，支持 macOS 上的 Metal 加速和 CPU 推理，是个人学习、离线演示、原型验证的绝佳工具，但它不做高并发、不做多机调度——生产上规模时要换 vLLM 或云服务。

3. 自托管 vs 云 API：一个真实的架构决策

这是大模型选型里最重要的一张决策表：

判断维度	倾向用云 API	倾向自托管
数据敏感度	数据可出境、无合规约束	数据不出域、隐私/合规红线（医疗、金融、内部文档）
调用量	小流量、波动大、验证期	稳定大流量（TCO 平衡点之后自托管更便宜）
能力要求	要最新最强模型	开源模型能力已够用
延迟要求	可接受几十毫秒到秒级	极低延迟、离线可用
团队能力	无 GPU、无部署人力	有 GPU 与工程团队
成本结构	零固定成本、按量付费	一次性硬件投入 + 运维

一个常用判断框架：先 API 后自托管。产品验证期用云 API 最快最省钱；当流量稳定、模型能力需求固化、且 TCO 算下来自托管两年回本时，再迁移到 vLLM 自托管。这个"云起、自托管终"的路线，避免了过早买 GPU 和过早锁供应商两头踩坑。

云 API 的三个隐性成本

① 成本失控：长上下文、Agent 多轮调用会快速烧钱，一定要做 token 用量监控；② 供应商锁定：prompt 工程和微调资产绑在 API 上，迁移成本高；③ 数据合规：传上去的每一段文本都离开你的边界，法务/安全团队必须先过审。选择自托管时，别忘了开源模型同样需要对齐与安全评估，不是"开源就安全"。

五、自动化与高层工具：AutoML / PyCaret / H2O，何时值得用

选型清单里还有一类"替你选型"的工具。AutoML 的理念是：让工具自动完成"特征工程 → 模型选择 → 超参搜索 → 集成"，把建模这一环的脑力成本压到最低。

1. 主要选项

工具	出身	特点	最适合的场景
PyCaret	开源低代码	用几行代码跑完整建模流程 + 自动比较 20+ 模型	分析师、快速验证、教学
H2O AutoML	H2O.ai（Java 内核）	老牌企业级，自动做 Stacked Ensemble，支持 R/Python	企业中规模表格建模
AutoGluon	AWS 开源	表格数据上的自动集成之王，多轮 stacking 精度极强	表格数据追求上限精度
FLAML	微软开源	轻量、可嵌入现有代码，成本感知的搜索	在已有 pipeline 里自动调参

一个 PyCaret 的"三行跑完整建模"示例，感受高层工具的手感：

python

from pycaret.classification import setup, compare_models, finalize_model

setup(data, target="churn", session_id=42)   # ① 自动做数据清洗/切分
best = compare_models()                       # ② 自动对比几十个模型 + 调参
final_model = finalize_model(best)            # ③ 在全量数据上重训

2. 何时值得用，何时不该用

值得用：

基线阶段：AutoML 花一小时产出的结果，通常能干掉新手手动调参一周的效果——先让它告诉你"这个问题理论上能到多少分"，再决定要不要人工深入；
团队没有专职算法工程师：业务分析师用 PyCaret/AutoGluon 就能交付八十分模型；
表格数据的精度冲刺：AutoGluon 的层叠集成（stacking）在很多 Kaggle 表格赛里能逼近甚至超过人工 Tuning 的上限。

不该用：

问题定义不清：AutoML 只能优化你给的指标，如果连"预测什么、衡量什么"都没定，工具只会放大错误；
数据质量差：脏数据、目标泄漏、样本偏差——AutoML 不会帮你发现，只会"优雅地"吃掉它们；
需要解释性与可控性：AutoML 产出的 Stacked Ensemble 是黑箱套黑箱，风控/医疗场景要解释时反而更难收场；
把 AutoML 当信仰：它解决的是"算法选择"这一小环，管不了特征获取、数据管线、上线监控——这些才是项目 80% 的工作量。

定位 AutoML

AutoML 不是"取代数据科学家"，而是压缩"算法试错"这一环节。成熟团队的用法是：AutoML 快速产出基线 → 人工在基线上做特征工程与领域建模 → 必要时人工接管调参。把它当成"速度极快的第二位同事"而不是"老板"。

六、实验管理：MLflow 与 W&B

选型清单里最容易事后后悔没早做的一环，是实验管理。没做实验管理的典型症状：模型文件叫 model_final_v2_really_final.pt，指标记在聊天记录里，复现一个结果要翻半天历史。

1. 两个主流方案

维度	MLflow	Weights & Biases (W&B)
形态	开源、可私有化部署	商业 SaaS（有免费层），也支持私有化
核心能力	Tracking（指标/参数/工件）+ Models Registry + Projects	Experiment tracking + 可视化 + Sweep 超参搜索 + 团队协作
部署成本	自己搭（SQLite/Postgres + 存储）	零运维，注册即用
强项	工程化：模型注册、版本管理、与服务化/CI 对接	研究体验：交互式曲线、可分享看板、Sweep 自动化搜索
适合	生产团队、要私有化、要进 MLOps 流水线	研究团队、重可视化与协作

一个最小 MLflow 用法——它改变的是"写实验的方式"：

python

import mlflow

with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.01)
    mlflow.log_param("num_leaves", 64)
    mlflow.log_metric("val_auc", 0.921)
    mlflow.log_metric("val_logloss", 0.31)
    mlflow.log_artifact("model.pkl")          # 工件自动归档，不再有 v2_final

mlflow ui 一条命令起一个本地看板，所有实验的参数、指标、模型文件都在时间线上可追溯。从"第一版正经实验"就用它，比跑完 50 个实验后再补要便宜一个数量级。

2. 实验管理的三个层次

个人级：MLflow Tracking 或 W&B 免费版，把"参数 + 指标 + 工件"沉淀下来；
团队级：模型注册中心（MLflow Models / W&B Registry），统一"哪个模型是生产候选"，配合代码评审与回归对比；
组织级：接入完整的 MLOps 流水线——训练、评估、上线、监控、回滚闭环。这一层的内容见MLOps 与模型生命周期，它是"实验管理"的自然延伸。

别过度设计

如果你的项目还在"探索阶段、模型未定型"，一个 MLflow 本地服务 + 团队共享看板就足够。不要第一周就上 K8s 调度 + 特征平台 + 全链路监控——实验管理工具和别的一样，规模到了再升级，过早基建是另一种浪费。

七、笔记本 vs 脚本 vs 项目工程：什么时候从 notebook 毕业

最后一种"工具"，是代码的组织形态。很多团队的框架没选错，死在了"代码永远停在 notebook 里"。

1. 三种形态的定位

维度	Jupyter Notebook	Python 脚本	项目工程（包/流水线）
定位	探索、可视化、讲故事	复现、批处理、单次任务	可维护、可测试、可上线的系统
状态管理	隐式全局状态，cell 顺序敏感	文件级，重跑即复现	显式输入/输出，可参数化
可测试性	几乎不可测	中等	单元测试 + 集成测试
版本控制	极差（ipynb diff 是灾难）	好	好
适合阶段	问题探索、EQA 分析、写文档	数据管线、训练脚本	生产服务、复杂产品
不适合	生产、长流程、协作多人改	交互分析	快速验证

2. 从 notebook 毕业的四个信号

notebook 超过 500–1000 行，或者"必须按 cell 顺序执行否则报错"——你已经写了一个没有测试的、不可维护的脚本，只是伪装成笔记本；
代码要进生产：要接监控、要定时跑、要给别人维护——notebook 里藏着隐式状态，任何一步 df 被上一步悄悄改过，都是定时炸弹；
需要单元测试与代码评审：模型代码的正确性（数据切分泄漏、特征对齐、归一化参数一致性）只能靠测试保证；
多人协作：git 里合并 ipynb 是痛苦的；用脚本 + 配置化（config 文件/命令行参数）替代。

3. 一条务实的迁移路径

notebook（探索）
   │ 把「确定下来的逻辑」抽成函数
   ▼
utils.py / train.py（脚本，带 --config 参数，可重跑）
   │ 加数据/模型抽象，加测试
   ▼
src/ 包结构 + 流水线编排（pipeline 脚本或 MLflow 项目）
   │ 对接部署与监控
   ▼
生产系统（服务化 / 批处理平台 / MLOps 流水线）

现实建议

不要求 all-in 工程化。探索阶段留在 notebook 里完全正确——它是最高效的分析工具。关键是"毕业"的时机：当某段代码第二次要被复用、或要跑进生产时，第一时间抽成函数进脚本。每次从 notebook 复制粘贴到生产代码，都是在给未来的自己制造债务。完整的项目搭建流程见从零构建一个 ML 项目。

八、决策清单：一份可勾选的选型流程

把全文收敛成一张可以照着勾的决策清单。从"最贵的问题"问到"最便宜的工具"，每一条都对应上文的一节：

第 1 步：先冻结问题（前置）

[ ] 我已经明确"预测什么、为谁预测、成功指标是什么"
[ ] 我确认了数据可获取、数据质量已初步审查（无目标泄漏、无重大缺失）
[ ] 我清楚约束条件：数据能否出境、延迟要求、可用算力

第 2 步：按数据形态定工具家族

[ ] 表格/结构化数据 → 选 [scikit-learn 基线] + [GBDT：LightGBM/XGBoost/CatBoost]
[ ] 图像/音频/文本/非结构化 → 选 [PyTorch]（除非有 TPU/移动端/存量 TensorFlow 强约束）
[ ] 大语言模型任务 → 走第 4 步

第 3 步：按团队与部署约束精调

[ ] 团队以业务分析师为主、时间紧 → 引入 AutoML（PyCaret/AutoGluon）打基线
[ ] 只能 CPU / 客户现场离线 → 确认 GBDT 与 sklearn 为主，避免重型深度学习
[ ] 要上 Spark / 多语言 → XGBoost 生态优先
[ ] 需要可解释性（风控/医疗）→ 线性模型 + 树模型为主，慎用 AutoML 黑箱集成

第 4 步：大模型专项决策

[ ] 数据敏感/合规红线 → 自托管（vLLM + 开源模型）
[ ] 快速验证/小流量/要最新能力 → 云 API
[ ] 本地单机/离线演示 → Ollama
[ ] 走开源模型 → 默认 Hugging Face 入口
[ ] 流量稳定且自托管 TCO 占优 → 从 API 迁移到 vLLM

第 5 步：工程基建一次到位

[ ] 从第一版实验就接上实验管理（MLflow 或 W&B）
[ ] 代码按"notebook 探索 → 脚本固化 → 工程化"节奏演进，不拖债
[ ] 确认部署路径（Serving/批处理/边缘）与选型兼容，不"框架能跑"但"上不了线"
[ ] 最后：花一天用候选框架各跑一个真实数据的最小原型，用结果拍板

勾完这条线，你的选型理由就既可以说给技术团队，也可以说给业务方——选型最重要的是"有据可依"，而不是"当时大家都在用"。

参考资料

scikit-learn 官方文档 —— fit/predict/transform 统一 API 与 Pipeline 生态
XGBoost 官方文档 —— GBDT 工业化的开创者
LightGBM 官方文档 —— 直方图加速与 leaf-wise 生长
CatBoost 官方文档 —— 原生类别特征与对称树
PyTorch 官方文档 —— 动态图与事实标准生态
TensorFlow 官方文档 —— Keras 高层 API 与生产部署体系
JAX 官方文档 —— 函数式自动微分与 XLA 编译
Hugging Face Transformers 文档 —— 开源模型统一 API 与 Model Hub
vLLM 官方文档 —— PagedAttention 高吞吐推理与 OpenAI 兼容接口
Ollama 官网 —— 本地一键运行开源模型
PyCaret 官方文档 —— 低代码 AutoML
H2O AutoML 文档 —— 企业级自动建模与 Stacked Ensemble
AutoGluon 官方文档 —— 表格数据自动集成之王
MLflow 官方文档 —— 开源实验管理与模型注册
Weights & Biases 文档 —— 实验可视化、Sweep 与团队协作

框架与工具怎么选

框架与工具怎么选 ​

一、选型总原则：先问问题，再选工具 ​

1. 三个真正的决策维度 ​

2. "按流行度选"为什么是陷阱 ​

二、表格数据场景：sklearn 与 GBDT 三巨头 ​

1. scikit-learn：生态与流程，不是精度天花板 ​

2. GBDT 三巨头：精度、速度、易用性的三角博弈 ​

3. 结论：表格场景怎么落地 ​

三、深度学习场景：PyTorch vs TensorFlow vs JAX ​

1. 三家定位 ​

2. 为什么 PyTorch 成了事实标准 ​

3. 什么时候需要换框架的"信号" ​

四、大模型场景：Hugging Face、vLLM、Ollama 与云 API ​

1. 工具链地图 ​

2. 三个工具，三种姿势 ​

3. 自托管 vs 云 API：一个真实的架构决策 ​

五、自动化与高层工具：AutoML / PyCaret / H2O，何时值得用 ​

1. 主要选项 ​

2. 何时值得用，何时不该用 ​

六、实验管理：MLflow 与 W&B ​

1. 两个主流方案 ​

2. 实验管理的三个层次 ​

七、笔记本 vs 脚本 vs 项目工程：什么时候从 notebook 毕业 ​

1. 三种形态的定位 ​

2. 从 notebook 毕业的四个信号 ​

3. 一条务实的迁移路径 ​

八、决策清单：一份可勾选的选型流程 ​

延伸阅读 ​

参考资料 ​

框架与工具怎么选

一、选型总原则：先问问题，再选工具

1. 三个真正的决策维度

2. "按流行度选"为什么是陷阱

二、表格数据场景：sklearn 与 GBDT 三巨头

1. scikit-learn：生态与流程，不是精度天花板

2. GBDT 三巨头：精度、速度、易用性的三角博弈

3. 结论：表格场景怎么落地

三、深度学习场景：PyTorch vs TensorFlow vs JAX

1. 三家定位

2. 为什么 PyTorch 成了事实标准

3. 什么时候需要换框架的"信号"

四、大模型场景：Hugging Face、vLLM、Ollama 与云 API

1. 工具链地图

2. 三个工具，三种姿势

3. 自托管 vs 云 API：一个真实的架构决策

五、自动化与高层工具：AutoML / PyCaret / H2O，何时值得用

1. 主要选项

2. 何时值得用，何时不该用

六、实验管理：MLflow 与 W&B

1. 两个主流方案

2. 实验管理的三个层次

七、笔记本 vs 脚本 vs 项目工程：什么时候从 notebook 毕业

1. 三种形态的定位

2. 从 notebook 毕业的四个信号

3. 一条务实的迁移路径

八、决策清单：一份可勾选的选型流程

延伸阅读

参考资料