大模型要成功，算力是关键。 这是腾讯云面向大模型训练场景，发布的全新一代的HCC高性能计算集群性能参数： “算力性能和上一代相比提升3倍，服务器接入带宽从1.6T提升到3.2T。” 采用最新一代腾讯云星星海自研服务器，并搭载NVIDIA H800 Tensor Core GPU的这代HCC高性能集群，单GPU卡支持输出最高1979 TFlops的算力。 具体强在哪里？ 去年10月，腾讯完成首个万亿参数的AI大模型——混元NLP大模型训练。在同等数据集下，将训练时间由50天缩短到11天。如果基于新一代集群，训练时间将进一步缩短至4天。
近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”，统一交给下游网关团队，组成统一的应用层。这种由多个网关合并成大前台(酒店业务网关)的融合，带来的好处是核心系统边界清晰了，但是对酒店业务网关来说，也带来了不小的困扰，系统面临的压力主要来自两方面：首先，一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异，有些甚至是跨语言的代码迁移。其次，后续的复杂多变的应用层业务需求，之前分散在各个子网关中，现在在源源不断地汇总叠加到酒店业务网关。这就导致了一系列的问题
Katalyst 是字节跳动对多年大规模业务云原生化场景中资源管理能力的抽象和总结，我们期望通过 Katalyst 的开源直接或间接的帮助用户做好资源管理，实现降本增效。 当下互联网应用以天为单位，在线业务的资源使用情况往往会随着访问数量的波动而变化，具备明显的潮汐特性。为了确保业务稳定性，业务方往往会参考高峰时段的资源使用情况来申请资源，但这部分资源在低峰时段容易被闲置。 如果可以把这些闲置资源暂时出让给优先级低的服务，当在线业务需要使用的时候及时将资源归还，形成在离线服务混部，就可以达到削峰填谷，节约成本的效果。
我们每天都会收到各种各样触达信息，就在这小小的信息里，蕴含了不少的智能技术。本篇文章介绍了严选触达场景下的智能化技术，包括人群、方式、创意、福利等因素的决策。
淘苏（花名）目前是大淘宝技术的一名开发工程师。从国企跳槽来到互联网，【职业规划】是他被问得最多，也思考得最多的问题。 回忆国企的三到五年时间，他完成了最初始的技术和经验的积累。接下来的职业生涯规划里，他希望成为一名优秀的技术专家，想更深入的培养自己技术攻坚能力，想去更高的平台学习大型项目的功能拆分实践，塑造自身的技术品牌，于是，他来到了大淘宝技术。
众所周知，堆crash dump是最难分析的dump类型之一。此类crash最大的问题在于，造成错误的代码无法在发生堆破坏时被发现。线上采集到的minidump，仅能提供十分有限的信息。当调试工具报告了堆破坏、堆内存访问违例后，即便是有经验的开发人员也会觉得头疼。剪映专业版及其依赖的音视频编辑SDK、特效模块均采用MD的方式链接标准库，这意味着任何一个模块出现了堆损坏都会互相影响。从crash的位置回溯堆破坏的源头，是一个非常有挑战性的工作。剪映业务模块较常见的是Use-after-free，而音视频编辑SDK和特效模块这类底层算法特效模块更多的是Buffer-overflow，不同团队模块间的堆错误互相影响，导致问题难以定位。 GWP-ASan是Google主导开发的用于检测堆内存问题的调试工具。它基于经典的Electric Fence Malloc调试器原理，概率采样内存分配行为，抓取内存问题并生成上传崩溃报告。说到这里，也许你会好奇它和ASan（Address Sanitizer）的区别。
WebAssembly 作为一项新兴的技术，已经发展至 2.0 版本；相较于 1.0 版本，2.0 版本增加了更全面的指令支持和对大容量内存的友好性；同时，向量指令的加入也提高了 WebAssembly 在复杂场景下的性能表现。目前，WebAssembly 已经广泛应用于各种 Web 和非 Web 场景，例如 Web 端的视频渲染、编解码、算法移植，以及非 Web 端的 Serverless、客户端跨平台等领域。 除了广泛的应用场景，WebAssembly 还具有跨平台、高效、安全的优点。它可以在各种计算机架构上运行，并且具有接近原生代码的性能。此外，WebAssembly 的代码可以在沙箱中运行，不会影响主机环境的稳定性和安全性，从而有助于保护用户数据和隐私。 随着 WebAssembly 技术的不断进步，未来还有许多值得期待的方向。例如 WebAssembly 的多线程支持、AI 模型的推理和训练，以及在区块链领域的智能合约编写和执行。这些发展方向有助于进一步提高 WebAssembly 的性能和功能，从而推动 Web 上更多应用场景的发展。
Mooncake是得物API一站式协作平台。从2022年3月份开始负责Mooncake，到现在已经一年了，回顾这一年，Mooncake大的阶段上，总共经历过两个版本: 1、Mooncake 1.0: 面向前端和客户端的mock平台，主要解决接口调用者的数据mock问题 2、Mooncake 2.0: 面向前后端的，融合了yapi和mock的一站式文档管理平台，从供需两端解决接口文档的流通效率问题
大型系统的本质问题是复杂性问题。互联网软件，是典型的大型系统，如下图所示，数百个甚至更多的微服务相互调用/依赖，组成一个组件数量大、行为复杂、时刻在变动（发布、配置变更）当中的动态的、复杂的系统。而且，软件工程师们常常自嘲，“when things work, nobody knows why”。 本文将重点围绕软件复杂度进行剖析，希望能够帮助读者对软件复杂度成因和度量方式有所了解，同时，结合自身的实践经验谈谈我们在实际的开发工作中如何尽力避免软件复杂性问题。
