Deep-Learning

起因 # 最近在做 CS336（Language Modeling from Scratch）的 Transformer 实现，代码里反复出现这种写法：

起因 # 我们的线上推理系统中存在大量模型——MLP、GNN、MoE，以及它们的各种组合。这个 workload 有几个重要特点：

起因：一个来自运维同事的问题 # 前阵子运维同事找到我，大意是：

起因：GPU 没吃满，但不是算力问题 # 最近组里有同学训练模型时，最直接的感受是：GPU utilization 上不去，step time 里总有一段在等数据。

起因 # 以前在商汤做 CV 的时候，有一段时间在做目标检测模型的 INT8 量化。目标很直接：降低 inference latency，减少 model memory 和 bandwidth，同时利用 INT8 hardware throughput。

起因 # 上一篇讨论模型显存时，我直接用了一张表：

起因 # 上一篇讨论了模型调度中的 Performance Constraint：一个模型放到 GPU 上以后，到底跑多快？

起因 # 最近在做 CS336（Language Modeling from Scratch）的 resource accounting 作业，里面要求逐个列出 Transformer forward pass 中所有的 matmul，然后按 \(2MKN\) 计算 FLOPs。

起因 # 最近在学 Stanford CS336（Language Modeling from Scratch），做 tokenizer 作业时，第一次在测试代码里见到了 pytest.mark.xfail。

起因 # 机缘使然，最近在工作中接触到了 MoE（Mixture of Experts）。

背景 # 公司内部的基于torch的toolbox发现某个版本之后,结果发生了偏移. 通过一系列排查,发现当导入cupy和torch的顺序不同时，计算结果会有所差异。 也就是说,如下两段代码会导致模型训练等环节的计算得到不同的结果.

记录在 Bazel 工程中引入 ONNX Runtime 预编译包时的动态库、头文件与依赖配置。

背景 # 2022年惊讶的发现，当时竟然没有写关于softmax的笔记，因此来补充一下。

迫于生计，从今天开始学习推荐系统相关的内容，今天先来读一篇推荐系统领域的综述 Toward the next generation of recommender systems: a survey of the state-of-the-art and possible extensions

前言 # 偶然发现了 torch2trt 的模型转换方案，思路是直接将pytorch op映射到TensorRT的python api. 在pytorch进行每个op　forward的时候，tensorrt也相应往network上添加op. 这里会先涉及torch2trt的使用，后面会补充这个转换工具的代码学习

写在前面 # 主要是需要在jetson nano做模型转换，来记录下踩的坑 目前有两条路径，一条是我们现有的转换路径，也就是pytorch->onnx(->caffe)->trt的路径 在这条路径上踩了比较多的坑，最终暂时放弃，最直接的原因是cudnn8.0升级接口发生改动，编译caffe遇到较多问题 这里其实仍然采用了两条平行的路径，一条是直接在nano上构建环境，另外一种是基于docker(包括构建交叉编译环境用于加快编译速度)

caffe做部署是YYDS! blob layer net 激活函数 卷积 reshape slice loss function reduce eltwise argmax

背景 # 似乎没什么背景,继续看caffe代码

背景 # 这个layer和reduce layer有一些相似,就干脆一起看了. 作用是输入至少两个blob,然后对每个blob中的元素所一些运算,最后得到一个blob.

背景 # 其实没什么背景,继续啃caffe代码而已2333