Upload untitled.md

untitled.md

@@ -0,0 +1,320 @@
+
+
+1、关于企业专属大模型人力协调。
+昨晚经过海青和应答进一步确认，结论为非DashScope部分，与430专属大模型界面相关前后端全部由行解研提供人力支持。
+今天上午11点，7位小二（前端*2，测试*2，后端*3）全部确认，来自行解研3部（绍隆团队）。已经完成空印和对方对接。下午开始具体的工作对接，目前运行良好。
+
+
+王超对于python代码性能分析优化和调试都有着比较深厚的积累，并且开发了nitro编译优化等比较硬核的工具，并在针对性的计算密集任务上获取了比较好的效果。但是之前在NLP工程团队，对于业务工程方面的工作没有比较好的align，实际落地产出的工作有限。在这个实际业务产出有限的前提下，全年的绩效为3.5-。这样的绩效某种程度上，与同学能力和业务需求有所不匹配相关，同学本身在python领域的技术能力比较solid，也被大团队所认可，接下来调整到aquila/proxima团队做核心技术工作，期望能有更好的技术产出。
+
+这个背景下，在尊重FY23 3.5-绩效决定的前提下，对于王超将来对团队的贡献依然有所期待，所以依然给予一定的调薪分配。
+
+【O-组织】围绕达摩院AI板块业务目标，从技术发展趋势和产品策略出发，基于定义的目标，形成项目组，并能设计出在组织、人才、文化配套方案。从而围绕“生产力-技术创新突破”，“生产效率-技术孵化周期”，各技术团队能通力合作，基础研究+领域应用组织调度系统和方法建设，提升组织效率和效能。
+
+KR1：围绕业务目标：发布多模态大模型应用（Bazinga，实现大模型服务国内第一梯队），基于人才盘点、e表等重要环节人才信息，确定淘汰、核心人员名单，并在FY24财年中闭环review和跟进。
+KR2：软的部分-润滑剂。大模型的技术变革带来组织和人员调整，沟通方案需要有设计，在满足技术业务需求的情况下，充分考虑个人的发展诉求。做到精英之间同频共振，互相尊重、激发，加快团队转型效率与节奏。
+KR3：OKR保障：提升OKR质量，从工作习惯的适应到工作方式的转变。板块重点项目、各实验室内部（周会、月会、月报等围绕OKR进行）确保业务从目标、策略到执行层层要和，促进生产关系协同。运用线上化的工具，作为组织高效运转的抓手，推动目标共识、过程管理、结果评价，实现目标与机制的闭环。
+KR4：围绕板块重点方向，算法（基础研究）、算法（应用落地）、工程、产品建立沟通机制（战役/项目组等），提升决策效率。做到目标通、关键人才信息通，提升核心团队运行效率，沉淀达摩院特色技术精英共振机制。
+
+● ■ 针对分布式git升级做了一轮摸底，测试发现当前git访问瓶颈在于公网带宽，在带宽充足时新方案提升到3倍。同时目前用户反馈的notebook git速度慢问题定位为跨Region访问git仓库，git多地域分发能力技术方案调研中。 ■ Inference API、模型一键部署等相关需求技术方案调研中，Notebook 支持云资源付费链路开发中。
+
+
+O1:通过“模型+系统平台+云”联合生态的构建，实现云+智能的全栈能力输出，支持达摩院与云AI对外整体技术影响力的形成。树立承载“模型即服务（MaaS）”理念的行业标杆。
+
+KR1: 完成DashScope的产品化。以大模型的实际场景为切入点，在统一的技术底座上，为各种模型提供云原生的高效的推理，微调，训练，和数据回流等能力，提供多种模态能力AI的被集成接口，以及核心AI资产在云生态上的自闭环。实现达摩院当前大部分头部API往DashScope平台的迁移和聚合，并通过DashScope上的全链路优化，为迁移的API提供更加高效的推理训练，以及包括版本管理在内的完整MLOps功能。
+
+KR2: 完善多种模态的模型在ModelScope library以及modelscope站点demo/创空间/工具箱等全方位生态接入方式，完善站点本身能力以及与云生态的互动，为模型贡献者，与模型使用者持续提供便利。紧跟领域最新模型研究进展，确保先进模型的高效及时接入，并选择性建设LLM效果评测等高需求工具。关注模型部署，体验，和应用搭建的全链路体验。依托云PaaS平台，完善推理，(分布式)训练与部署能力。通过对各领域模型体系结构梳理，形成ModelScope library技术特点。探索在新兴或现有领域中，具备特色的，能与Transformers，Diffusers等对标的技术组件。继续增强ModelScope在国内模型社区领先地位的同时，对标国际竞品。坚持建设精品模型社区的理念，依托达摩院以及其他机构高质模型的先发优势的同时，探索平台特有功能点，并将相关工作整理为论文发表，形成一流模型社区的国际影响力。
+KR3: 实现ModelScope和DashScope两个横向平台互联互动，落实ModelScope为DashScope的引流作用，以及DashScope为ModelScope模型生态提供生产化，促进相辅相成的模型数据生态的形成。注重沉淀两个系统上通用的技术能力同时，深入探索不同场景上的针对性改进与优化。有意识地促进两个平台间技术的复用与融合，以及功能点的互补。建设和输出业界一流的AI生态+基础设施。
+
+
+
+O2：实现核心工程组件的通用化和服务化能力，为各个实验室提供系统化支持的同时，实现基于云原生底座的对外服务能力透传。
+KR1:将HIE/Aquila等技术组件，打造为支持各模态模型推理加速的通用底座。通过在DashScope项目上的打磨，将
+HIE算子优化实现，AllSpark体系的建设，Aquila推理框架等方面，通过一个体系化、系统自适应化的方式去对外输出，支持各类模型的（自适应）推理优化的能力。这包括针对各类场景（LLM，文生图，语音等等）的具体优化，以及在这个基础上，系统化地与PAI-Blade等优化框架对接，支持自动化的量化能力，和与PAI-EAS协同探索多机多卡推理能力等方面的工作。同时探索Aquila与HIE对外独立服务化的方案。
+
+KR2:梳理数据获取->清理/转换/标注->管理全链路，完善AI数据处理算子生态，提供多语言数据支持等能力，对标业界一流算法模型研发，尤其是各领域大模型所需的高质量数据支持能力。推动各数据组件的云化服务输出，通过轻量化部署等技术手段，实现公有，私有，混合等云部署状态上技术水位的拉起。通过API，开放数据打标等能力，并打通ModelScope生态，在数据平台上提供基于模型的智能标注能力。
+
+KR3:推进Proxima服务基于K8s架构的云原生化，统一当前单机Search Engine与多机Distributed Engine的工程架构，实现可扩展的Poxima服务化；同时持续进行Proxima core的性能优化，完善异构硬件上的支持。
+基于服务化的Proxima，统一支撑达摩院各实验室与业务线的非结构化/多模态检索需求，实现整体服务的对外输出能力，支持AI多模态搜搜索产品的建设。结合ModelScope平台以及其他技术组件，打通embedding入库的通路并建立成熟外围生态。
+
+
+KR4: 拉齐工程平台与各工程组件的测试评测体系，搭建体系化的工程卓越性流水线和体系化的MLOps/LLMOps系统。针对大模型领域新兴的测试评测需求，构建对应工具与平台。持续沉淀前端技术组件，高效支持平台和各产品线在前端需求。
+
+
+
+
+O3: 为达摩院各个算法实验提供持续工程支持
+KR1: 持续优化云上建模开发平台，并拓展国际化市场；完善多语言的SDK支持。在重点行业，重点领域继续持续投入，打造电力，绿色行业等行业的标杆项目。
+KR2: 为各个实验室的算法业务创新提供有效工程支持。在搭建高效的底层工程平台和通用工程组件的基础上，通过工程能力有机组合的方式，降低各条业务线创新的工程投入成本。
+KR3: 为现有的各个业务场景提供持续支持，同时推进多个自学习平台的整合，API服务的融合等工作，提升整体工程效率，包括机器使用效率，优化推理性能，提高开发人效。
+
+
+O4: 打造支撑业界一流AI研究和业务创新所需的一流AI工程团队
+KR1:在关键领域上引入业界一流人才，补强团队技术能力。帮助新人树立在工程团队实现技术先进性的心智，形成团队荣誉感。
+KR2:基于团队目标，明确分工，清晰要求，探索AI工程领域同学培养体系，促进有意愿、有潜力的技术同学成长。
+KR3:依托Tech-Talk等形式，加强团队内以及跨团队的技术分享，关注业界技术进展和细节。
+
+
+    ○ FY24规划初步方向-质量建设
+    ■ 各支撑的业务线会匹配在座各位老板的规划，做对应的质量建设落地
+    ■ Aquila 、HIE 、Proxima 等工程底座能力的测试介入，和开发共建质量能力
+    ■ Mone 对接的测试能力接入，由于大模型的优先级提升，该部分内容最近没和卫霍讨论。下周会详细讨论；
+    ■ 大模型评测体系建设：客观、主观 ……  
+    ○ FY24规划初步方向-前端建设
+    ■ PD 各业务线需求落地 -- 组件化沉淀
+    ■ AEM 统计相关，对维护项目统计相关数据，推动关停并转；
+    ■ iTag 
+
+
+
+这块分成三层：业务层（比如数字人或其他对话系统），框架平台层（dashscope），和模型层。
+
+    ○ FY24规划初步方向-质量建设
+    ■ 各支撑的业务线会匹配在座各位老板的规划，做对应的质量建设落地
+    ■ Aquila 、HIE 、Proxima 等工程底座能力的测试介入，和开发共建质量能力
+    ■ Mone 对接的测试��力接入，由于大模型的优先级提升，该部分内容最近没和卫霍讨论。下周会详细讨论；
+    ■ 大模型评测体系建设：客观、主观 ……  
+    ○ FY24规划初步方向-前端建设
+    ■ PD 各业务线需求落地 -- 组件化沉淀
+    ■ AEM 统计相关，对维护项目统计相关数据，推动关停并转；
+    ■ iTag 
+    ○ FY24规划-横向：外包资源合池的推进
+	
+
+
+
+
+openai相当于
+
+yingda
+
+7/7-10
+8/19
+
+仕良对环评主要针对对是周躜作为语音实验室工程参与OpenMind前期的工作。在一定阶段，OpenMind 1.0整体上确实陷入了合作不畅，发展滞后的问题。需要在顶层明确方向。在FY23财年，周躜是承担了BU横向的ModelScope后端服务，并在后期OpenMinD 2.0项目中（即DashScope），承担了整体推理服务架构的工作，并于近期负责了整体平台工程。3.75超出期望的技术亮点，主要基于其在横向平台工程的贡献，并在这个过程中充分leverage其在语音工程架构中技术的复用，从更宽的角度去看问题。
+
+最近绩效盘点得差不多了，下星期大家有空的时候思考一下，FY24想要做的方向。我们周四的周会上可以先做一轮初步的讨论。
+
+同步一下状态：
+1. 确定了M6 13B模型只需要维持attention softmax的FP32精度，其他部分可以继续使用量化优化。目前已在AllSpark上跑通模型整体使用FP16+单独适配FP32 attention softmax。对比Megatron实现，以及单卡FP32实现，交叉验证通过。
+2. 多卡适配M6模型初步完成，已经能在2卡A10上加载13B模型（使用上述FP16精度，开启batch=8），不再需要A100机器。
+3. 和数字人团队联调，当前https://pre-bazinga.aliyun-inc.com/#/ 已经按照上述方式部署了M6 13B模型，包括多轮对话在内的场景测试符合预期。其中top_p参数配置尚未完全对齐，但整体不影响使用。
+
+Ongoing：
+1.之前NLP 13B模型的overnight压测已经在100台机器上完成，整体稳定。周末工程同学加班适配M6模型，争取周一能在同等规模上完成压测。
+2.M6 13B模型的进一步优化进行中（FP32 softmax+A16W8混合精度），希望能单卡A10能host。
+3.top_p参数适配（非高优先级）。
+
+
+所以目前我判断的部署优先级 （高到低）： 
+1.  使用A16W8在单卡A10上部署 13B， 大约下午2点左右可以ready进行测试。 
+2.  开发多卡支持， 增加相关通讯， 使用FP16 两卡A10部署 13B， 这部分开发量比A16W8慢， 可能要晚上才能搞定。 
+3. 单卡A10部署 2.7B FP32， 作为目前不需要任何开发的方案， 作为最终保底--
+
+
+目前本地测试单卡的fp32，fp16是和megaton inference的Fp16，fp32都比较过id输出，都是一致的
+
+在2卡A10上跑通。
+
+
+attention softmax 变成FP16以后对结果影响很大， 然后只换这个OP到FP32以后， 就和FP32结果一样了。 
+
+然后检查了下AllSpark的实现， 这部分原来就是FP32实现的（即使在FP16下）
+
+
+
+DashScope核心基本功能按计划3月3日完成上线，支持用户通过PythonSDK简单几行代码，端到端实现文本生成，基本对齐OpenAI的SDK对应体验。后端基于单机多卡搭建服务多并发stress test通过，并开始多机部署以及弹性化伸缩能力的开发。
+
+
+需要同时为业务负责，和为工程负责。
+厚薄。都可以厚
+做决定，人和人的关系
+
+模型列表：
+GPT3-1：文本生成模型
+GPT3-2：文本生成模型
+Diffusion-1:文生图模型
+Paraformer-1:语音识别
+Paraformer-2:语音识别
+
+自评业绩评语（可调整）
+1）推动达摩院横向工程底座的搭建。ModelScope落地，协同达摩院各实验室一起打造对外技术品牌和影响力。ModelScope魔搭在中国AI社区，开始形成具备影响力的技术品牌，并覆盖了较宽频谱的AI开发者。DashScope整体MVP完成全链路功能打通，在通用底座的基础上，初步打通LLM模型的API推理全链路（GPT流式+Batch）。
+2）碎片化的工程组件研发有所改观。若干基于特定场景支持的开发项目，孵化后有成为通用组件的潜力，包括HIE-AllSpark, SEAL，MOne等。数据获取，标注，管理整个链路所需的平台工具开始成型。
+3）与云产品（PaaS）的系统化的联动有所增强。
+
+
+通过ModelScope和DashScope等横向项目，打造达摩院底层的工程基座。ModelScope的建设和落地，成为MaaS"模型即服务"理念的第一个承载项目，协同达摩院各实验室一起打造对外技术品牌和影响力。ModelScope魔搭在中国AI社区，开始形成具备影响力的技术品牌，并覆盖了较宽频谱的AI开发者。明确了通过DashScope构建统一的AI云上API服务技术方向，已经完成MVP初步验证，并将马上承载大模型对外大规模服务的任务。DashScope通过与云生态游更紧密的合作，进一步拓展了MaaS理念的范畴，同时开始和ModelScope形成健康的互联互动。
+
+在这些横向项目的基础上，达摩院工程积累的垂直工程组件，包括在模型推理框架，推理加速，数据获取，标注，管理等方面的积累，从之前基于特定场景支持的开发项目，转变为往通用化组件的演化，工程团队长线发展方向与路线，以及和各个实验室配合与分工合作模式开始明朗。Proxima团队明确了核心引擎通过统一Proxima服务，以及作为SQL引擎检索插件，两种方式输出：并当前重点投入统一Proxima服务的开发。
+
+关键产出1:建设ModelScope平台，形成包括开源Library，独立站点，后端服务等在内的整套相对完整平台生态。
+
+关键产出2:初步形成从数据获取，清理，使用，管理的全链路工具化能力。
+
+关键产出3:Aquila推理框架以及HIE推理优化能力在支持多个实验室模型推理的过程中，组件能力本身有了更好的锤炼，为支持DashScope项目（包括LLM的推理）做了比较好的技术积累。当前成为DashScope平台系统化的组件支撑横向平台的开发与发展。
+
+关键产出4:前端+质量保障：较好支撑了各条业务线和平台线的前端需求以及质量保障。并在迭代平台型产品的研发过程中，完善系统化的质量保障体系，以及实现前端技术的组件式复用。
+
+
+2.最小规模finetune训练用到的资源量及吞吐：
+
+3.最小规模continue training 用到的资源量及吞吐
+
+
+
+
+
+梳理平台性横向底座 + 具体工程组件 + 实验室业务工程需求之间的关系，明确分层，相辅相成
+
+
+数据平台：初步形成从数据获取，清理，使用，管理的全链路工具化能力
+iTAG – 通过API开放被集成能力，并在此基础上支持自定义打标。在细化标注领域(e.g., 图片分割, 表格等)持续沉淀能力。
+Virgo – 平台数据管理能力初步形成，服务所有增量数据。集成数据获取能力，并通过构建AI数据处理算子体系，来提供数据增值能力。
+Proxima: Core引擎持续迭代并支持集团搜索等核心业务，梳理Proxima核心引擎输出出口，明确后续将以Proxima服务，以及各SQL引擎检索插件两种方式输出。
+HIE: AllSpark在量化算子等方面的持续投入，为降低LLM推理资源消耗做好技术储备。国产化适配为倚天等自研硬件上的模型推理提供了支撑。HIE在ONNX上的通用兼容工作推进中，显存置换工作进一步完善，为输出到EAS平台做好准备。
+Aquila: 完成整体重构和组件能力拆分，并与PAI-MediaFlow实现能力共享。基础框架性能与各模态算子性能持续优化，支撑了大部分达摩院推理业务。借助DashScope项目，继续完善流式能力支持，并成为统一推理组件。
+前端+质量保障：较好支撑各条业务线和平台线的前端需求以及质量保障。并在迭代平台型产品的研发过程中，完善系统化的质量保障体系，以及实现前端技术的组件式复用。
+
+
+
+目前的现状：
+
+1 模型效果：钟煌的13B效果具备可内测能力；
+2 工程可扩展性：工程可扩展QPS在标准GPT-3上初步验证；
+3 算力准备：机器资源（A10，V100，3090组成）可以支持本周这周末1000 QPS；
+
+
+遇到的问题：
+1、钟煌的13B模型有一些定制化，目前在要在多卡上跑起来，还需要一些针对性的工程优化（颖达负责解决，协调开发中）- 应答需要给出解决该问题的DDL
+2、德丽的模型目前也需要A100，现在正在做工程优化，支持切片，应该后续可以支持4卡A10（目前不需要3.10支持）- 应答需要给出解决时间的排期计划，不要影响411发布。
+结论：A100是很大的风险。
+
+潜在风险
+1、使用多卡后，效率较低，需要使用更多的机器。（目测可以支持1000QPS）- 应答需要提前预警，协调资源。
+
+
+
+class rwlock{
+private:
+    mutex w_mu;
+    mutex r_mu;
+    int reader = 0;
+public:
+	rwlock(){
+    	init(w_mu);
+        init(r_mu);
+    }
+    
+    void write_lock(){
+    	lock(w_mu)
+    }
+    
+    void write_unlock(){
+    	unlock(w_mu)
+    }
+    
+ 
+    void read_lock(){
+    	lock(r_mu);
+        if(reader == 0)
+        	lock(w_mu);
+        
+        reader++;
+        
+        unlock(r_mu);
+    }
+        
+    void read_unlock(){
+        
+        lock(r_mu);
+        reader--;
+        if(reader == 0){
+        	unlock(w_ru);
+        }
+    
+        unlock(r_wu);
+        
+    }
+    
+rw_lock rw = new rw_lock();  
+vector<int> a;
+int main(){
+
+    thread th1 = new thread();
+    thread th2 = new thread();
+    th1.join();
+    th2.join();
+    
+th1:    
+    rw.write_lock()
+    
+    a.push_back(1);
+
+	rw.write_unlock();
+
+th2:
+	rw.write_lock()
+    
+    a.push_back(2);
+
+	rw.write_unlock();
+
+} 
+    
+    
+    
+    
+
+}
+
+
+
+1、管控台设计，UED资源协调完成，本周五评审。portal页面设计资源需要重新协调，预计下周产出portal页面设计初稿。
+2、MVP版本对应的模型card、模型服务详情页、统计报表页面等产品设计规范进行中
+
+➔ 阿里云产品商业化流程：
+1、商业化评审材料准备：上周已经有一个初版，差成本和ROI投入及定价部分，本周补充完整。
+2、商业化评审流程和加速计划：预计本周五约产管具体勾兑。
+3、产品code对工程研发的影响：目前研发调试阶段使用临时code能满足需求。需要在3/17前拿到新的产品code。
+
+本周我们需要实现提供一个13B模型支持集团内部使用的服务。要求支持1000 QPS。需要的action items：
+1. 判定使用A10 2卡还是A10 4卡机型。理论计算A10 4卡+batch=80应该优于当前的2卡+batch=16的配置需要尽早测试A10 4卡。
+2. 购买A10 4卡机器，计划使用64张卡来支持。 FP16作为兜底方案，同时A16W8集成测试和精度测试高优推进。
+3. 大规模服务的支持，确保64张卡规模上的稳定。高优先级保障固定规模服务的稳定可用性，完善测试涵盖内容，确保错误兜底。实现基础的【系统】限流能力。同时推进服务弹性自动伸缩能力的开发。
+4. API-Key页面获取方式。本周需要起码有一个简单的页面支持用户自主获取（集团内部使用）API-Key。
+5. 开始支持dashscope backend对接多个资源池（对应不同模型，比如2个GPT+1个文生图）。
+6. SDK完善接口设计（和服务端对齐默认参数提供方式等等）和流式实现（默认http单向流式，ws方式作为可选供用户显式指定使用）。
+7. 已知的稳定性问题（例如显存/内存缓慢泄漏等）完成修复。
+
+
+
+
+周躜，谦言，沐磷，青神，路研，继烛，道仙，征明，无厚，南空，寒冬，苏奈，莱东，愚初，良莀，启翎，南空
+
+
+
+
+这是我整理的 TL;DR
+
+1) 便宜：API 价格是$0.002 / 1K tokens，和之前curie（gpt-3 6.7B）的价格持平，是davinci（gpt-3 175B，$0.020 / 1K tokens）的十分之一。
+2）Early users ：API已经早开放给Snapt， Instacart， Quizlet等公司使用了一段时间，比收集了很多feedback
+3）API使用的gpt-3.5-turbo模型将持续更新，不像之前的其他模型，只是一个snapshot，同时提供一个snapsoht版本：gpt-3.5-turbo-0301
+4）Dedicated instances：支持独占机器（集群）的API调用，官方建议一天使用超过4.5亿token的买dedicated instance更加划算
+5）Data submitted through the API is no longer used for service improvements (including model training) unless the organization opts in：API不再收集用户数据，看来OpenAI认为已经有足够多的数据来源了
+6）Please hold us accountable for improved uptime over the upcoming months：马上要支持SLA（之前无）
+
+
+按照当前目标的13B和50B的模型结构估算，预期要求的卡数如下。
+注1: 按照峰值10000计算，非QPS。这是在给定并发下，服务不会被拒绝所需的【最少】卡数。
+注2: INT8精度尚未完全开发验证完毕。
+
+13B模型, 4卡A10 host一个模型。Max Token = 1024.
+FP16精度(最大batch = 80)，支持峰值10000需要卡数: 512
+INT8精度(最大batch = 96)，支持峰值10000需要卡数: 428
+
+50B模型， 8卡A10 host一个模型。Max Token=1024
+FP16精度（最大Batch=36）支持峰值10000需要卡数：2224
+INT8精度（最大Batch=62）支持峰值10000需要卡数：1296 
+
+50B模型， 4卡A10 host一个模型。Max Token=1024
+INT8精度（最大Batch=62) 支持峰值10000需要卡数：2108