大家好，今天我们很高兴首次发布Index系列模型中的轻量版本：Index-1.9B系列 本次开源的Index-1.9B 系列包含以下模型： Index-1.9B base : 基座模型，具有 19亿 非词嵌入参数量，在2.8T 中英文为主的语料上预训练，多个评测基准上与同级别模型比处于领先. Index-1.9B pure : 基座模型的对照组，与base具有相同的参数和训练策略，不同之处在于我们严格过滤了该版本语料中所有指令相关的数据，以此来验证指令对benchmark的影响（详见2.3章节）. Index-1.9B chat : 基于index-1.9B base通过SFT和DPO对齐后的对话模型，我们发现由于预训练中引入了较多定向清洗对话类语料，聊天的趣味性明显更强 Index-1.9B character : 在SFT和DPO的基础上引入了RAG来实现fewshots角色扮演定制 目前，我们已在GitHub（https://github.com/bilibili/Index-1.9B），HuggingFace（https://huggingface.co/I
B站作为一个拥有浓厚人文属性的平台社区，聚集了诸如《雍正王朝》、《三国演义》等经典影视剧集，同时也吸引了大量用户欣赏、品鉴这些人文经典 。但美中不足的是，由于拍摄年代久远、拍摄设备落后、数据多次压缩传输等原因，大量剧集存在各种各样的画质问题，严重影响了用户的观看体验。 在观看了站内大量经典剧集后，我们总结了三点观看时的主观感受，并将解释这些主观感受背后蕴藏的画质问题及成因。
如果你是一名前端开发，同时又对AI开发很感兴趣，那么恭喜你，机会来了。 如果不是也没关系，同样能帮大家了解AI应用的开发思路。 本文将带大家从面向AI开发的基础知识开始，再到RAG，Agent，流程编排，深入了解如何在企业内部落地AI项目。
随着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。
