ztxz16
希望作者考虑按照我的设计思路增加对deepseek-R1-671B及类deepseek-R1-671B的Moe模型的支持
1.deepseek-R1-671B的运行流程
根据我对deepsekk-R1-671B的文档的理解，总结的运行流程 a.prompt首先通过37b的路由模型的推理分析从256个专家模型中选择8个专家模型. b.再由8个专家模型的进行二次推理最后获得推理输出. 2.运行分析 根据1中的运行流程可以得到如下情况推论： 256个专家模型在具体的某次推理中只有8个专家模型和37b的路由模型参与了推理，其他的248个专家模型不参与. 3.运行设计思路 a.将路由模型以张量并行的形式切分到GPU组中，进行并行推理 b.将所有专家模型存放到内存中. c.在推理过程中对所有的专家模型进行使用次数统计形成一个专家模型热度榜(为专家模型的加载调度做依据). d.通过专家模型热度榜，将热度榜名次靠前的专家优先从内存拷贝到显存中(拷贝的专家模型数量，从启动参数中获得，为专家推理的加速推理做铺垫). e.当路由模型选中未在显存中的冷门专家模型时，显存中热度最低的几个专家模型进行踢出（踢出专家模型个数由启动参数获得），将冷门专家模型拷贝到显存中进行推理. f.提供一个json文件格式，让用户填写，常用推理问题，以便快速生成专家模型热度榜，以快速完成专家模型的快速初始化调度（json文件路径由启动参数获得）. g.每推理一定的次数，将热度榜进行一次保存（推理次数由启动参数获得） h.为扩大兼容性，可以选择对不同的指令集进行特定兼容，从老指令集逐渐兼容到新指令集
其实这个就是lora的思路。。。小模型蒸馏
如果是我理解的lora与知识蒸馏的话，那么思路是有些相似之处的 相似：都是动态的，所谓“按需激活”，模块化且相对高效 不同：那就太多了
生成每一个token的时候都会选择不同的专家，虽然可能会有一些热门专家每次都被选择，但并不代表每次推理被选中的专家都是那几个热门专家，总会有冷门专家需要被转移到显存，同时显存中最冷门的专家被转移回内存。随着推理进行，需要频繁地经过PCIE通道对冷门专家进行显存和内存的对拷，而PCIE通道的带宽在目前为止是很窄的，PCIE4.0 x16单向只有32GB/s，远低于双通道DDR5内存，更不用说显存，那么冷门专家在内存和显存之间的转移时间就会比较长，从而极大影响生成速度。。。你这个方法我猜测速度更慢
