1. Windows 别想了。本体用 TensorFlow / PyTorch 可能会有各种奇怪的问题，因为你这真的是小众平台很少有搞学术这么做的，碰到问题不好解决。而 WSL/WSL2/虚拟机都是不可能用 CUDA 的，无解。
2. Linux 下用 Docker 启动 CUDA + TensorFlow 是可能的。我在实验室这么干了好几年了，不然我们实验室那么多人用服务器，每个人环境都不同，我得管死。

1. Python 解释器层面的一些锁。这个其实想要优化总能优化的。
2. 保护 C 扩展模块，这方面是挺蛋疼的。

Python 生态半壁江山是 C 扩展库撑起来的，丢掉这部分江山等于自废武功。为了支持无锁而去掉 GIL 等于丢掉所有这些库，做网络应用的是爽了，但是 Python 就分裂了。

说的更明确一些：哪怕 C 扩展库对自己的逻辑进行了加锁，但是由于要访问 Python 对象，进一步使用 Python 解释器的东西，它防止不了外面的代码同时访问相同的对象，然后就崩溃了。。。

所以面对 C 扩展库，GIL 喊了这么长时间都搞不掉。
…… 所以其实 Python 成也“胶水”败也“胶水”。C 扩展库能这么容易访问 Python 底层的东西是个优势，可以迅速做一些系统层面的 API 调用、融合 C/C++ 做科学计算（ PyTorch，NumPy，或者 GPU 计算），或者在暴露 C/C++ 写的核心算法为 HTTP API 。但是同样的，这个优势也让 Python 在普通的多线程网络服务器上寸步难行。

我的看法是，Python 干好科学计算这方面的事情就行了。还有就是干好工具型胶水语言该做的事情，在性能无关的领域放光（比如运维）。科学计算本来就计算密集型，本来就要独占核心一直跑，根本不会有线程上下文切换。网络服务交给专业的，比如 Go，Java，C++ 什么的。多好。。。