随着B站大数据业务的高速发展，各类业务资源需求也随之快速增长。与此同时，大数据集群有效的资源利用率低于预期，究其原因主要有以下两点， 业务出于性能、稳定性考量会向平台申请过量的系统资源，导致平台不会调度更多任务上来运行。 对于高低优任务资源隔离能力不足导致有竞争时，高优任务受影响甚至被误杀。 为了解决业务资源过量，大数据团队在hadoop架构中加入了自研超配组件Amiya。Amiya依据用户申请的资源量一般大于用户真实使用的资源量的基本推论，根据当前机器的实际负载情况，向调度组件虚报一定的资源量，使得更多的任务能够被调度到服务器上。同时，在大部分任务申请量接近其真实使用量时，Amiya需要及时驱逐一定量的任务以保证服务器整体稳定运行，关于Amiya细节信息可参考B站大数据集群混部实践（上）- 资源超配篇。
B站作为国内领先的内容分享平台，其核心功能之一便是支持UP主们创作并分享各类视频内容。UP主稿件系统作为B站内容生产的关键环节，承担着从内容创作到发布的全过程管理。为了满足不同创作者的需求，B站提供了多种投稿渠道，包括移动端的粉大加号、必剪APP，以及Web端和PC端的上传方式，确保创作者可以随时随地上传自己的作品。同时，B站的内容来源多样化，既有用户生成内容（UGC），也有专业生成内容（PGC），以及商业合作稿件等。这些内容通过分区品类、话题和标签等多维度进行分类，以满足不同用户的兴趣和需求。这就要求B站必须具备一套高效、稳定的稿件生产系统，以确保内容的顺利上传、处理和分发。 随着业务的快速发展，技术团队面临着组织变革、业务需求快速迭代以及系统劣化的挑战。在此过程中，技术债务逐渐累积。技术债务主要源于为了迅速适应市场变化而采取的临时解决方案，或者是已经过时的历史技术架构，这些问题若不及时解决，将会导致系统维护难度加大、系统复杂性提升和性能下降，进而影响用户体验和业务的持续发展。
在现代的移动应用程序中，长连接是一种不可或缺的能力，包括但不限于推送、实时通信、信令控制等常见场景。在猫耳FM的直播业务中，我们同样使用了 WebSocket 长连接作为我们实时通信的基础。 在我们推进用户体验优化的工作中，其中用户成功进入直播间的时间是我们优化的一个重点指标，其包含了房间信息接口的调用、长连接的建立、播放器拉流的首帧等。本文主要介绍我们在 WebSocket 长连接跨端统一和体验优化的思路和方案。 这里我们先简单介绍下 WebSocket，以及为什么我们选择了 WebSocket 而不是其他的协议作为我们持续迭代的方向。
上篇文章 万字长文解析：大模型需要怎样的硬件算力 深入探讨了大型语言模型（LLMs）在硬件资源方面的需求和面临的挑战，详尽地阐述了如何进行大模型的硬件选型，以及在实际工作中如何根据模型的特定需求来优化硬件资源配置。继此话题之后，本篇文章将重点介绍支撑大模型运作的核心组件——集合通信库，介绍其在大模型架构中的关键作用和实现机制，以及B站是如何应用和改进它的。 随着模型规模的不断增长，单块显卡已经无法满足模型对于显存的需求，分布式训练逐渐成为主流，其中通信库负责了拓扑感知、集合通信原语实现、数据传输等工作，扮演着至关重要的角色。在分布式训练集群逐步普及和规模化的过程中，各个厂商，尤其是云和GPU硬件制造商，对于整个集群的性能和效率不断提出更高的要求，也因此涌现了一批xCCLs(x Collective Communication Libraries)，例如HCCL、ACCL、oneCCL和TCCL等，从侧面也反映了通信库的重要性。 鉴于通信库的原理和实现都异曲同工，本文只针对开源的NCCL通信库来进行讲解，结合B站大模型训练的落地实践经验，拆分解析AI基础软件中通信库的实现
本文将分享 OPPO 多模态预训练模型在端云场景的落地实践。文章将聚焦于如何在手机端实现云场景大模型的部署，在资源不充分的情况下以更低的成本完成训练和推理的落地。 具体内容分成三个主题： 1. 端侧图文检索技术研究 2. 文图生成&理解态模型的应用优化 3. 文图生成模型的端侧轻量化
H5页面给人的感觉通常是开发成本低、迭代速度快但使用体验不佳。其中最容易被用户感知的体验问题就是首屏速度，由于H5页面的所有资源都需要实时从网络上下载，提升这些资源的加载速度就可以明显提升首屏速度。我们通常将提前下发资源到App，并在打开H5页面时使用预载资源加速访问的技术称为“离线包”。 B站的离线包技术方案与大部分互联网公司实现的方案在底层逻辑上是一致的，都实现了基础的资源下发和拦截匹配机制。但在此基础上我们也有一些创新，例如页面快照技术、AB实验能力，同时也做了很多优化，包括用扫码调试降低调试成本、版本快速收敛、预约定时错峰发布等。目前我们的离线包技术已经接入183个项目，覆盖12个业务线，在公司内被广泛使用。
在这个部分，我们将对几种主要的跨平台语言进行比较，主要从执行效率、引入testcase前后app体积变化、运行内存峰值和运行内存的overhead这几个方面进行考察。 对比的平台在iOS、AndroidOS、HarmonyOS这三个平台上进行测试，由于不同平台的硬件设备无法做到一致，所以我们会在各平台选一款设备作为测试标准。 对比的语言在目前bilibili实际生产环境中使用到的语言，分别为Kotlin、JavaScript、Dart、C++、Swift。
榜单遍布B站直播相关业务的各个角落，直播打赏、直播间互动、付费玩法、互动玩法、活动、主播PK、语聊房、人气主播排名、高价值用户排名、增值集卡、up主充电等等，在这众多的业务场景中，我们能看到各种各样的榜单。 榜单的存在，可以激发主播提升表演水平、提高表演质量的积极性，从而吸引更多的观众。观众也可以通过榜单展现的排名，了解其他人对主播的互动打赏情况，激励他更加积极地参与互动或打赏，从而获得认同感和存在感。通过榜单，主播又能获得更高的收益和更多的曝光流量。总之，榜单是一道连接平台、主播、观众的重要桥梁，对提升整个直播的良好氛围有着极大的作用。另外，用户上榜的规则是多样化的，确保消费打赏行为不会过度商业化，在引导观众理性消费和平台健康发展方面也起着积极的作用。
对于一个前端工程师而言，每天都在面对的较多的需求场景就是调用后端的接口，但是因为众所周知的原因，前端目前已经有无数种调用接口的方式，例如：之前有基于 XHR、Axios、Fetch 进行封装的工具，大家都试图在统一接口的调用方式，但是他们看起来最后都需要再进行改造。于是，我们试图在 B 站开发一套能够综合上述工具之长处，并结合 B 站事实需要的工具， 推出一个具有统一错误处理、减少代码冗余、抹平风格差异、降低文档负担、优化代码提示等功能的统一请求库。
