当然可以啦，但是有两个问题需要你考虑：

第一个是大部分的pytorch程序都是使用CPU对DataLoader进行操作的，也就是说就算是你的GPU一直实在处于训练状态，你的CPU也不是闲著的，这个很好看，开个nvidia-smi同时再开个htop看看cpu和gpu占用率就知道了。另外你应该听说过调numworker和prefetch factor有可能能提高GPU占用率，这也是这个原因之一。 这时候你要是在CPU上再开一个推理任务，很有可能CPU就卡脖子了，GPU数据不足也被卡了，整体效率底下。

第二，这个在GPU上个train好的模型是要把数据拷贝回CPU才能进行推理的。这个拷贝的过程一般是同步的，也就是说这个期间CPU、GPU都不能干其他的活 （当然前提是你只有一个stream），如果你评价的次数比较多的话，又会被卡脖子，得不偿失。

所以现在主流的还是都上GPU直接在GPU上执行就好了，一般情况下速度很快的。

这个当然是可以的，开一个新进程初始化CPU就行

但是这样节约不了多少时间，一般评价都不会设计得太长，加之CPU推理速度远低于GPU，增加整个Pipeline的复杂度是否划算？

更好的方案依然是用所有GPU去训练，之后用所有GPU去评价，GPU一直不空也就发挥最大价值了

gpu训练时cpu也是协同使用的。比较精细的做法是可以限制使用cpu核心数，比如只用一般的核心，修改omp thread 变数。然后剩下一半用来做别的事情。这种情况下需要开两个python进程，一个训练一个验证

当然可以，训练一个进程，模型评估一个进程，前者训练生成模型，后者读取模型进行评估，可以用队列来完成两者之间的通信。

当然，也可以在一个主机上训练，在另一个主机上模型评估，使用RabbitMQ消息队列来完成两者之间的通信。

不过，用cpu来模型评估怕是…

没有很大意义，因为训练也是需要CPU参与的，CPU的空闲算力几乎没有。然后evaluate本身也是运行模型呀，在CPU上是很慢的。结果反而效率会更差。

跟你稍微不一样的地方，我是用两块GPU开了两个进程，一个进程用于训练，一个进程用于验证

整体思路：

(1).用shell脚本同时开启训练进程和验证进程

nohup python train.py --GPU=0 &>train.log

python evaluate.py --GPU=1

（2）train.py

（3）evaluate.py 用pyinotify实现实时监控是否有新模型生成，如果有就进行验证

具体可参考：

LianShuaiLong/CV_Applications?

github.com图标

难道是用了sklearn？

从代码层面完全可以实现，但是没有什么意义，仅仅针对该问题回答。

实现流程如下（默认训练代码已经完成）：

  1. 编写validation的相关代码和函数，可以保存为python脚本。
  2. 在训练过程中，动态调用命令行指令，在子进程中执行validation代码。(可以在python中使用subprocess模块)

注意事项：需要将模型保存到指定位置，然后在validation中载入保存的模型参数。整个过程与在gpu中进行validation没有什么区别，只是在validation时，使用一个子进程执行。

推荐阅读：
相关文章