深度学习算法岗平时需要自己写cuda吗？

工业界里面numba用的多吗，还是说工业界主要还是直接写cuda？

再不济就是利用动态图的性质由numpy、py_func等实现然后手动定义反向梯度函数。

这里相对更重要的反而是算法工程师定义反传的能力。虽然不是什么特别难的工作，但不少算法岗的同学可能也没仔细思考过最基础的矩阵乘法怎么定义grad，或者不清楚tensorflow或者pytorch的autograd机制而导致无从下手。

然后提到CUDA最大的关心点必然是性能。无论是速度还是显存都有可能通过CUDA开发来过得极大的提升，一般体现在访存效率、数据结构设计、算子融合等技巧上。事实上从个人经验来说，有时候自己实现的算子库跑模型很容易比native的tensorflow快两到三倍，如果是一些特殊情况，十几甚至极限情况上百倍也有可能。并且合理的设计比起生硬的用原生算子能够大大减少显存开销，这对于训练和推理都是有极大益处的。

但是，CUDA开发有些不小的成本，特别是对于算法研究，灵活性非常重要。可能要短时间里尝试很多种不同的自定义算子，这时候堆机器能解决的话一般先不急着进行深层次的优化，而且在整个网络结构确定下来之前，很难进行最终的优化。除非有特别高频使用的算子，优化前后的差距非常明显(比如对整体的影响5倍左右，无论是显存还是速度)才可以考虑进行个别算子的优化。万一一通CUDA操作下来，模型效果提升不明显，最终的时间/人力成本不一定划算。我更倾向于尽量先验证算法再进行优化。

此外，涉及到这么深层次的研究，并且CUDA优化非常必要的情况，一般公司都会有专门的HPC组或者团队接手了，或者可能就该思考为什么通用的算子不能满足需求。

再说下CUDA开发的成本。C/CPP本身的编写和调试难度就不提了，CUDA C基本就是小半个新语言，Debug逻辑也是全新的。如果为了极限性能进行魔改然后遇到一些非法的显存访问更是头疼，不过现在各类nv的可视化调试工具出来了应该体验会好很多。一些初入坑的同学可能会觉得把算子换成cudnn api就好了，但其实很多时候性能瓶颈是来自于访存效率，这往往意味着需要写新的kernal来融合算子，亲自掌控显存/缓存的管理。工作量特别是调试上会比想象的大很多。如果只是简单换下cudnn，很可能反而增大了潜在的数据拷贝开销导致性能变差。这里面的各方面经验需要长时间的积累，要不就交给专业的团队做，要不就自己长时间保持这方面的学习实践。基本上不会作为一个算法工程师的必备素质。

但是如果拥有这样的视野对于算法工程师来说是非常好的，即使没有用到，平时也能在设计模型时保持从性能和效率的角度思考问题，而不是局限于模型效果。工业界对于成本是非常看重的。

比如，现在要优化模型推理性能，剪枝，蒸馏，量化一大通操作下来，模型纯推理时间由30ms降到15ms，性能翻倍，感觉不错，但是一看数据预处理，耗时10ms，模型后处理耗时15ms，算下来处理数据花的时间比我模型推理花的时间还要长。这时候，cuda大神就可以上场了，我们把预处理和后处理搬到cuda上，一测，预处理，后处理共5ms就搞定了。这时候，报告一写，模型推理时间55ms降低到20ms，领导看后一顿夸，心里美滋滋，升职加薪不是梦。

再比如，最近模型指标一直上不去，看着三年前的老模型，一脸嫌弃，感觉是时候拥抱新模型了。然后各种顶会，博客看下来，找到了个三个月前刚发表的新论文，华丽的辞藻，sota的指标让你按捺不住，想赶快把它用在自己的工程中，结果github上没找到开源代码。这时候，cuda大神又可以上场了，熬几个通宵，把论文中跳动的字符转换成cuda实现的美丽算子，然后模型一训，数据一测，指标提了3个点，老板看后又一顿夸，心里又美滋滋，升职加薪又不是梦。

cuda的作用很多，水也很深，一般做cv方向手撸cuda的机会还真不多，但是真的用上的时候，大概率是用来解决重大问题的时候。多了解了解，用的6确实可以算是自己很大的加分项。

我只能说，前世界上95%的算法和码农岗位都不需要你能够GPU编程，刷好题比这些都重要。

当然了，前一阵G社回来反挖失败那就是另一回事了。

评论圈有人说既然选了G社，就应该知道需要刷题，这属于准备不善。确实，我同事后来也是这么说的，当时根本就没有准备刷题，因为本身也没准备去做码农，抱着试试看的心理去了。

至于这类数据结构和算法轮子，大家千万不要认为用不到刷的题属于无用功。其实即便是用pytorch写炼丹算法还是要注意这些的。比如什么情况会造成新分配内存啊，何时内存会被copy啊，等等。轮子的基础越深，最后的车的舒适度，性能也越好，这是肯定的。

为了提升效率，需要在gpu上跑数据的，算法也是自己写的，通常效率估计比不上专门写框架的人，但是至少比在CPU上快好多倍。