LLM（大语言模型）因其强大的语言理解能力赢得了众多用户的青睐，但LLM庞大规模的参数导致其部署条件苛刻；在网络受限，计算资源有限的场景下无法使用大语言模型的能力；低算力，本地化部署的问题亟待解决。ChatGLM-6B在60亿参数的情况下做到了优秀的中英文对话效果，且能够支持在消费级显卡本地部署；因此在HuggingFace Trends上很快登顶。6B的参数量虽然能够做到本地部署，但是目前的实现依赖库较多，如Pytorch, transfomer；对于端侧部署来说要求仍然较高。因此我们尝试将该模型转换为MNN模型，极大降低了部署时的依赖项，能够更方便的在各类端侧设备上部署与测试；同时我们对MNN模型进行了低bit量化，并实现了反量化与计算融合的计算kernel，大大降低了内存需求。实测PC端小显存显卡能够成流畅运行浮点模型，在Android手机上能够流畅运行量化模型。
Hello folks，我是 Luga，今天我们来聊一下云原生生态核心技术——基于 eBPF 全链路自动化可观测性。当我们真正融入到云原生生态场景中时，我们将会深切地体会到：“全链路可观测性”的价值所在～ 在过去，要以安全、非侵入的方式从整个系统收集遥测数据通常较为困难，我们需要许多产品、应用程序级代理和复杂的配置操作。然而，随着基于 eBPF 的项目数量不断增加，现代基础设施为中心的云原生社区对其产生了极大的兴趣，使得 eBPF 在 2022 年和 2023 年经历了巨大的增长。 这种增长促使一些最优秀的软件工程公司聚集在一起成立了 eBPF 基金会，以致力于引导和维护 eBPF 标准和愿景的技术。因此，eBPF 正在迅速成为现代软件基础设施领域中日益普遍的技术，其中可观测性领域是其主要用例之一。
近年来，无论是 Serverless 还是 WebAssembly，都越来越受到开发者的广泛关注，作为字节跳动内部的函数计算平台，ByteFaaS 在 WebAssembly 方向上也有着不少的探索和实践。我们利用 WebAssembly 技术构建出了极致轻量化的函数运行时，并辅以全新设计的精简架构，打造出了云边一体的 Serverless 解决方案，拓展了 FaaS 的边界和应用场景，为业务带去了更多的可能。 本文将先带领大家认识 ByteFaaS 平台，分别介绍经典 FaaS 和 FaaS Worker（轻量级函数）方向。随后通过 WebAssembly 运行时、精简架构、开发者支持三个方面，详细介绍 FaaS Worker 的设计与实现。最后在文章结尾，会对 WebAssembly 函数能够为用户所带来的收益进行大致总结。
在 WebAssembly 社区蓬勃发展的当下，或出于对 JavaScript 等动态语言面对计算密集型任务时改善性能的愿望（如 Ammo.js），或源自将桌面表现出色的软件搬上 Web 环境的想法（如 AutoCAD），或希望在服务端利用沙箱来尽可能保证安全（如 Shopify-Serverless），越来越多的开发者选择 WebAssembly 技术。 而对于一项技术而言，围绕这项技术的开发工具矩阵是否完备，是否足够强大和易用，以及给开发者们带来的体验好坏，则是决定开发者们在尝试之后能否成为拥趸的关键因素。通常来说，一段代码的生命周期，包括编写、测试、交付与部署、上线生效、问题定位与修复等环节。在问题出现之后，对代码的源码调试（Source Code Debugging）往往是定位问题最高效的手段。提供高效的调试工具，帮助开发者迅速解决问题，是助推 WebAssembly 技术社区发展壮大的一个重要手段。 在本文中，我们将主要围绕 WebAssembly 的源码调试，阐述若干相关的问题。
课程的 WebAssembly 工作原理一章已经详细介绍了基于栈结构的指令执行原理和过程，然而，了解 WebAssembly 原理最有效的方式仍然是自己动手实现一个执行引擎；本文将从零开始实现一个简单的 WebAssembly 解释器 WAInterp (WebAssembly Interpreter)，通过这一过程来进一步掌握和实践 WebAssembly 虚拟机技术。
2020年，百度融合多项领先AI技术，推出国内首个可交互的虚拟偶像-度晓晓。经过近几年数字人行业的迅速发展，我们希望通过IP升级，让晓晓焕发更大的魅力。本文包含了虚拟人IP从前期设计到后期应用整体思路，尤其是在面对庞杂的视觉触点中，设计团队如何保障IP能够高质高效的进行落地，希望我们的思路与经验能为相关项目的同学带来帮助。
目前，前端平台探索大仓研发模式，通过Monorepo大仓的技术，整合前端平台现有应用的仓库代码，使得各业务域应用质量衡量标准统一，通用基础组件以及工具函数能够快速复用，当基础通用功能出现问题的时候，能快速地在各应用中升级，提升研发工作效率，节省人效。 我们知道在普通的项目开发中进行 git 的克隆和拉取不会遇到什么问题。但是随着我们代码的不断扩充，代码仓库内容会变得越来越大，需要几个G甚至几十上百G的磁盘空间时，如果把所有代码都pull到本地属实是个不现实的方式，不仅是我们没有这么大的磁盘空间，而且还有网络流量的占用问题以及网络速度问题都是没有办法解决。而且，如果Git仓库特别大，每次执行Git命令，等待时间会特别长。对于这些问题，我们做了相关的技术调研。
作者是腾讯 TDMQ 初创团队的成员，在多年的业务中台的实践中，也频繁地使用到了 MQ，比如最常见的消息推送，异常信息的重试等等，对消息队列有深刻的了解。此篇文章，作者会站在时间维度讲解这二十年每款 MQ 诞生的背景以及解决了何种问题，让你能够更加清晰地了解到 MQ 的底层逻辑，帮助你学习今后可能会出现的新架构。欢迎阅读~
