本篇为KMP技术的技术及实践系列文章的第二篇。在这篇技术文章中我们会以百人移动研发团队的工程化视角，探讨Kotlin Multiplatform的核心技术及优化。
随着传输技术、显示技术与算力的持续提升，用户对于音视频体验的需求在提高，各家设备厂商也在探索和推出对应的技术与产品。打造空间感的空间视频与空间音频是其中最为关键的2项技术，bilibili视频云在这两项技术领域也进行了相关代探索与建设。
随着前端业务的日趋庞大，及时发现和解决业务中的问题、优化用户体验、实时监控业务健康度变得愈发重要。在业务层面，我们希望能够监控每次发布版本后，核心功能是否有显著提升或至少没有负面影响，核心接口是否正常运作，页面跳失率是否有明显增加。而在技术层面，我们希望能够日常监控首屏加载时间，确保页面没有因为发布版本、运营配置、活动结束、库存不足等因素而出现错误。最后，我们还希望能够帮助业务方分析用户在前端页面的常规操作，如点击、交互、跳转等，以发现提升核心功能指标的突破口。
大家好，今天我们很高兴首次发布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基础软件中通信库的实现
