#356 平台调试任务和训练任务引导优化的讨论

<!-- 为了更有效地识别与解决您的问题，请尽可能的补充如下信息 --> ### 问题描述 目前平台针对调试任务和训练任务，均是用**排队**的方式进行提示。 个人理解，调试任务更强调**实训**，更强调能及时响应，跑一些**体验类**、**调试类**、**短时类**的任务；训练任务更偏向**科学实验**、**长时类**的任务。 对于长时类的训练任务，排队是合适的。用户在训练任务前已经将代码调试好了，提交训练任务后理想状态下就可以放手不管了。因此排队适合。 而对于短时类的调试任务，更偏向实时响应，用户更期待能及时响应。此时用排队就不合适了。此时可以参考一下AISTUDIO的设计，如附件，让用户选择规格，没卡的时候置灰，有卡的时候可选，CPU保底。这可能更适合调试任务的场景。 另外， 调试任务和训练任务的引导也需要完善。我感觉，不是所有的任务都需要用训练任务来做。应当科学引导，可以在调试任务跑完的短时类的体量不大的任务，就在调试任务跑完就好了。长时类的科学实验类的任务，引导到训练任务。 其实也想强调的是，是否能更科学地让不同的资源去做更适合它做的任务，尤其是当前GPU资源紧缺的情况下，而不是用户都一股脑地去选择最优的资源（举个极端的例子，跑手写字用A10064GB内存的资源，这就是资源浪费）。