請問用pytorch訓練過程，是否可以實現GPU一直處於訓練狀態，模型評價交給CPU？
當然可以啦，但是有兩個問題需要你考慮：
第一個是大部分的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？
從代碼層面完全可以實現，但是沒有什麼意義，僅僅針對該問題回答。
實現流程如下（默認訓練代碼已經完成）：
- 編寫validation的相關代碼和函數，可以保存為python腳本。
- 在訓練過程中，動態調用命令行指令，在子進程中執行validation代碼。(可以在python中使用subprocess模塊)
注意事項：需要將模型保存到指定位置，然後在validation中載入保存的模型參數。整個過程與在gpu中進行validation沒有什麼區別，只是在validation時，使用一個子進程執行。
推薦閱讀：
