引子：两盘器械，一个选择
假设你的医院要开展一台全新的微创手术。护士长递给你两盘器械：
盘A：标准化无菌手术包。所有器械按位置排好，打开就能用，厂家提供标准培训。
缺点是——如果你需要一个特殊角度的钳子，抱歉，包里没有。
盘B：定制化器械箱。你可以自己选、自己搭、自己组合。一个骨科钻头+一个神经外科的微型牵开器？可以。但你要花更多时间学习和配置。
这就是深度学习框架的世界。TensorFlow是盘A，PyTorch是盘B。
大多数医生不会直接碰代码，但当你的科室要引进一个AI项目、评估一个AI产品、或者和AI工程师合作时，了解这些框架的「脾气」会让你少走很多弯路。这一章不是教你写代码，而是告诉你——每个框架分别像什么样的手术器械，什么时候该用哪一套。
22.1 框架是什么？——AI世界的「手术器械标准化体系」
22.1.1 一层一层剥开看
深度学习框架的核心工作是把复杂的数学计算「打包」成可复用的积木。
传统的医疗器械是怎么标准化的？一把止血钳，不管在哪个医院、哪个厂家买的，医生拿起来就知道怎么用。框架在AI世界里做的就是这件事——把「定义神经网络」、「训练模型」、「加载数据」这些底层工作标准化，让开发者不用每次都从零开始写矩阵乘法。
框架提供三层能力：
| 层级 | 做什么 | 类比 |
|---|---|---|
| 底层算子 | 矩阵乘法、卷积、激活函数等数学运算手术刀、止血钳、拉钩——基础器械 | |
| 中层模块 | 预定义的网络层、优化器、损失函数标准缝合包、电凝套装——常用组合 | |
| 高层API | 几行代码定义一个完整模型 | 一次性的「整台手术器械包」 |
22.1.2 为什么框架选型很重要？
因为你一旦选了某个框架，就等于选了它的整个生态——开发工具链、部署方案、社区支持、人才供给。换框架的成本不亚于「手术做到一半换一套器械」。
22.2 TensorFlow（Google）：标准化手术包，工
业级部署王者
22.2.1 出身：Google的「系统化」基因
TensorFlow由Google Brain团队于2015年发布，一经推出就成为工业界的默认选择。它的设计哲学用三个字概括：标准化。
TensorFlow的设计思路非常「Google」——先定义好整个计算图（就像先画好整台手术的流程图），然后一次性执行。这种方式叫静态图模式：
优点：可以提前做全局优化，执行效率高，适合生产环境部署缺点：写代码不够直观，调试麻烦——出错了不好定位
22.2.2 核心武器：TF Lite——端侧推理的标配
TensorFlow Lighting（TF Lite）是TensorFlow专门为移动设备和嵌入式设备打造的轻量级推理引擎。它可以把训练好的大模型压缩、转换，然后跑在手机上、IoT设备上，甚至单片机上。
这对医疗场景意味着什么？
移动端影像分析：把皮肤镜分类模型部署到手机App上可穿戴设备AI：心电分析模型跑在智能手表里嵌入式医疗设备：便携式超声仪的图像增强模型TF Lite支持的硬件加速器包括GPU、DSP和手机NPU，这让它在医疗端侧AI场景中占据先发优势。
22.2.3 高光与拐点
TensorFlow在2017-2019年是绝对的王者。但转折点也在同一时期：PyT orch崛起了。
到2024年，TensorFlow在学术界几乎失守，但在工业部署领域仍然强势——因为TF Serving是经过大量生产环境验证的推理服务方案，大厂的线上系统不敢轻易换。与此同时，Google在2023年推出了Keras 3.0，支持在TensorFlow/JAX/PyT orch三种后端之间切换，某种意义上承认了「纯TensorFlow路线」已经不够。
22.3 PyTorch（Meta）：定制化器械箱，学术圈的
「开卷手术」
22.3.1 出身：为研究而生
PyT orch由Meta（当时的Facebook）于2016年发布。它没有试图做「面面俱到的工业平台」，而是瞄准了一个更具体的群体——AI研究者。
PyT orch的核心设计理念和TensorFlow恰好相反：动态图模式。
什么意思？你写一行代码，它就执行一行。出了bug，马上就能看到是哪一行有问题。这种模式被称为「Define-by-Run」（运行即定义）——不用提前画好整张计算图，边跑边算。
22.3.2 为什么学术界集体倒向PyTorch？
几个关键数据说明一切：
NeurIPS/ICML/ICLR（AI顶会）2023年投稿论文中，使用PyT orch的超过80%，TensorFlow不足10% Hugging Face（最大的开源模型平台）上超过90%的模型使用PyT orch几乎所有新发表的大模型（LLaMA、Mistral、Qwen、DeepSeek）都在PyT orch上训练为什么会这样？因为研究者需要快速试错。PyT orch的动态图让「试一个想法→跑代码→看结果→调参数→再试」这个循环的时间从小时级降到分钟级。
22.3.3 弱项在哪儿？
PyT orch在工业部署方面，历来不如TensorFlow成熟。一个在实验室里调好的PyT orch模型，要变成「可以在医院系统里跑起来、支持并发请求、有监控和日志的服务」——这个「最后一公里」过去需要额外的工程投入。
但2023年起PyT orch 2.0的发布、T orchServe的成熟，以及ONNX格式的桥梁作用，让这个差距在快速缩小。
22.4 JAX（Google）：下一代的「超精密仪器」
22.4.1 数学家的框架
JAX和TensorFlow「同父」——都出自Google——但定位完全不同。JAX的设计初衷不是做一个全面的深度学习框架，而是提供一个极高效的数值计算工具，尤其擅长做函数变换和自动微分。
如果说TensorFlow是面向软件工程师的，PyT orch是面向研究员的，那JAX就是面向数学家/物理学家的——它的API设计极其干净，代码行数少，但理解门槛高。
22.4.2 TPU加速：超算级别的训练
JAX最大的杀手锏是和Google TPU的深度融合。TPU（张量处理单元）是Google自研的AI训练芯片，在特定场景下比GPU更快。JAX+TPU的组合是当前训练Transformer模型的最优方案之一。
22.4.3 医生需要关心JAX吗？
暂时不需要。JAX目前主要活跃在Google内部和最前沿的算法研究圈。但如果你的医院和Google Cloud有合作，或者用到基于TPU的基础设施，了解JAX的存在就够了——它能帮你理解「为什么有些模型只能在Google的云上跑」。
22.5 PaddlePaddle（百度）：中国的「自研器械」
22.5.1 为什么要有国产框架？
2018年，中美科技竞争已经暗流涌动。百度的PaddlePaddle（飞桨）是中国第一个开源的深度学习框架，也是目前国内市场占有率最高的国产框架。
PaddlePaddle的战略定位很清晰：做一个「国人更好用」的框架。
22.5.2 PaddlePaddle的三大优势
优势 具体表现 医疗场景意义中文NLP原生优化预训练模型ERNIE对中文理解深度领先中文电子病历分析、医学文献挖掘优势 具体表现 医疗场景意义全中文生态 文档、社区、课程全是中文 医院团队学习成本大幅降低医疗场景深耕 百度智慧医疗产品线基于PaddlePaddle构建眼底筛查、肺结节检测等成熟落地案例PaddlePaddle在中国医疗AI领域有大量真实部署案例： - 百度灵医智惠的眼底影像分
析系统（已获批三类医疗器械证）：
- 肺结节CT辅助检测系统
- 大规模核酸检测AI调度
系统（疫情期间）
22.5.3 PaddlePaddle的局限
实事求是地说，PaddlePaddle在国际学术圈的存在感不如PyT orch，在国际工业界的部署也远不如TensorFlow广泛。用PaddlePaddle开发的项目，人才培养和生态资源都相对有限。但在中国医院+百度合作的场景中，它是几乎唯一的选择。
22.6 医生需要知道的三件事
22.6.1 框架选型对医院AI项目的影响
当你的科室要引入AI系统时，框架选型不是技术细节，而是决策核心：
| 场景 | 推荐框架 | 原因 |
|---|---|---|
| 采购现成AI产品可 | 不用管 | 供应商已经选好了，你关注功能和合规即 |
| 与高校/研究所合作研发PyT自建工业级AI服务（大医 | orch | 学术圈默认选择，招聘学生最方便 |
| 院）验证 | TensorFlow部署方案最成熟，TF | Serving有大量生产 |
| 与百度合作 | PaddlePaddle国产化要求+百度的医疗服务深度整合 | |
| 跑前沿大模型 | PyT orch 绝大多数开源模型基座在PyT | orch上 |
22.6.2 模型格式转换：ONNX——AI世界的「通用转接头」
你可能听说过ONNX（Open Neural Network Exchange）。它是什么？
简单说：一个连接不同框架的「通用格式」。在PyT orch里训练的模型，导出成ONNX格式后，可以直接在TensorFlow Runtime里跑。不需要重写代码，不需要重新训练。
ONNX就是AI模型的DICOM——让「飞利浦上训练的模型」能在「西门子的设备」上跑。
ONNX的存在大大降低了「选错框架」的风险成本。即使用了PyT orch开发，也可以通过ONNX导出后在TensorFlow Serving上部署。
22.6.3 给你的两点实操建议
建议一：买AI产品时，问供应商两个问题「你们的模型是用什么框架训练的？部署时用的什么推理引擎？」 这两个问题能让供应商感受到——这个甲方不是外行。如果对方支支吾吾，可能是封装了开源模型但自己都不了解技术栈。
建议二：建AI团队时，先定框架，再招人如果你们医院要自建AI能力，招聘时的第一件事不是看简历，而是定框架。定的框架直接决定了你能招到什么人、现有开源资源能用多少、以及未来和哪个云厂商绑定。
22.7 关键趋势：PyTorch「碾压」与框架趋同化
22.7.1 一张表看清四框架现状
框架 出身 核心优势 核心劣势 学术份额 工业份额TensorFlow Google(2015)
工业部署成熟、TF Lite端侧强API复杂、学术圈流失<10% ~30% PyTorch Meta(2016)
动态图灵活、学术圈主导工业部署历史包袱少>80% ~50%↑JAX Google(2018)
TPU加速、函数式编程学习曲线陡、生态窄~5% <5% PaddlePaddle百度(2016)
中文NLP强、国产化国际生态弱国内市场~15%国内市场~20%
22.7.2 框架在趋同
一个有意思的趋势是：框架之间的差异正在缩小。
TensorFlow：
- x引入了Eager Execution（动态图模式），向PyT orch靠拢PyT orch
- 0引入了T orchDynamo（计算图编译优化），向TensorFlow靠拢Keras
- 0支持JAX/TensorFlow/PyT orch三后端切换，事实上成了「框架之上的框架」
这意味着——选框架的重要性在下降，理解框架背后「解决问题的能力」在上升。 再过几年，医生真正需要担心的可能不是「用TensorFlow还是PyT orch」，而是「这个AI产品解决了什么临床问题」。
22.8 对医生的启示
启示一：不要被「技术选型」吓到
很多医生听到「框架选型」就觉得头疼：「这不是工程师的事吗？」没错，写代码确实是工程师的事。但决定用AI做什么、做到什么程度、对什么指标负责——这是医生的事。 框架是工具，选工具要服务于临床需求，而不是反过来。
启示二： PyTorch主导学术，但工业部署是另一回事
如果你的医院和高校合作做科研——大概率用PyT orch。如果你的医院要买一套成熟的、有医疗器械认证的AI系统——框架是什么根本不重要，重要的是准确率、稳定性、合规性。不要混淆「研究阶段的框架偏好」和「生产阶段的产品选择」。
启示三：招标时把「框架开源」写进合同
如果你的医院自研或委托开发AI系统，强烈建议在合同里明确：交付物必须包含模型源码和训练框架的完整技术文档，且框架本身必须是开源的。 这能防止未来被供应商「技术锁死」——哪天乙方不干了，你们还能找下一个团队接手，因为框架是开放的、模型是标准的。
22.9 本章小结
框架 一句话 最适合的场景 医生最需要知道的TensorFlow标准化手术包 工业级部署、端侧推理成熟可靠，行业默认选项PyT orch 定制化器械箱 学术研究、开源生态 学术圈主导，大模型都在上面JAX 超精密仪器 TPU训练、前沿算法 暂时不需深究，Google专属PaddlePaddle国产自研器械中文NLP、百度医疗生态 中国医院+百度合作首选ONNX 通用转接头 跨框架模型转换 AI模型世界的「DICOM标准」
22.10 延伸思考
你的科室或医院目前有AI合作项目吗？如果有，你知道它底层用的是哪个框架吗？
如果不知道，去问一下合作方——这是一个很好的「入门问题」。
如果你要启动一个AI科研项目，你倾向于用学术圈主流的PyT orch还是国产化更完善的PaddlePaddle？理由是什么？
框架趋同化意味着「选框架不再是最重要的决定」。那么在AI项目中，你觉得什么才是最重要的决定？（提示：不是技术，是临床问题定义）
本章初稿，待浩哥审阅。