背景

接上文 《大语言模型的基石：Transformer 入坑笔记（二） - 基本原理和 Word Embeddings》，继续我们的 Attention Is All You Need/Transformer 学习之旅。

首先简单了解下传统的方案。

卷积神经网络（CNN）

卷积神经网络（CNN）似乎更适合静态数据（比如图片处理、提取特征等）。 所谓静态数据，是指每个数据组都单独和目标矩阵运算，通过卷积层、池化层、全连接层等输出。 每个数据组都单独运算所以可以大规模并发，但是数据组之间也缺乏关联。 我大概看了下原理，和我们要关注的 Transformer 关系不大，先略过了。

背景

继续我们的 Attention Is All You Need 学习之旅。

我不是这个领域的，只是感兴趣想补一下基础，所以这一篇先只看最通用的原理：神经网络训练的大概流程、Embedding 是什么，以及 Word2Vec 里两种常见优化思路。

前言

这几年 AI 的热度一直很高。日常问答、写代码、整理文档、做工具，它已经开始进入不少人的日常工程流。我最近也开始认真补这块东西，主要是想搞清楚：这些模型到底是怎么一步步训练出来的，以及它有没有机会更深入地帮我们优化游戏研发里的工作流。

背景

这两天 DeepSeek V4 Pro 刚上线，小米那边也送了一个月的 Mimo Token plan。我本来就在试着用 AI 做一个完整工具，正好顺手把几个国产大语言模型都拉进来跑了一轮：GLM 5.1、Kimi K2.6、Mimo v2.5 Pro 和 DeepSeek V4 Pro。

背景

今年国产大模型是真的热闹。新模型一出来，宣传话术一个比一个猛。

尤其是最近出来的 GLM 5.1。

还有 Kimi K2.6。

海报和宣传图看着都很唬人，但真到自己拿去干活的时候，往往还是会闻到一点“跑分没输过，实战没稳过”的味道。所以我干脆把最近几个真实使用场景里的体验记了下来。

前言

在上一篇文章中，介绍了 libatbus 从静态子网树到动态拓扑注册表的路由设计变更。新的拓扑模型解决了代理层无法弹性伸缩和跨区域隔离的问题，但路由只是底层基座——上层应用框架 libatapp 才是真正面对业务开发者的接口。

前言

很久很久以前，我为了解决以前项目中bus通信膨胀的问题设计了 libatbus, 当时主要解决的核心问题是解决大量服务器节点互通时服务器间两两建立通道时的大量内存浪费问题。也同时使用跨进程的无锁队列避免了多写单读场景下的加锁以提高性能。

背景

前段时间例行升级我为游戏框架写的构建系统 cmake-toolset 时，又遇到了 protobuf 的一个新 ABI 兼容性问题。

这已经不是第一次被 protobuf 的 ABI 兼容性问题“教育”了。这篇把问题拆开讲清楚，并给出一套可落地的规避方案，供遇到类似问题的同学参考。

背景

在很久以前，我给我的Blog的主题加了 Hugo 的针对 Mermaid 和 Chart.js shortcodes 的支持。但是之支持迁入代码的方式。 如果文档很复杂，在Markdown里写大段的代码体验观感也不是很好。 而现在很多Markdown生态里是支持通过代码块的方式嵌入的。 同时现在很多插件可以直接按文件后缀编辑文件，然后直接指向文件的形式引用进来，这样可维护性会好很多。

背景

近期，公司代理侧的流量负担持续上升；在高峰期访问常见开发资源（包管理器、SDK、依赖镜像、CDN 文件等）会出现明显抖动。为降低重复下载带来的外网带宽开销与峰值波动，决定在内网引入一套“通用下载缓存代理”。

前言

现代化的C++项目可以借助多种静态分析工具来检查和发现潜在问题，包括空指针访问风险、未定义行为（UB）、内存错误等。

在我们的项目中，服务器工程基于 CMake 构建系统，可以方便地利用社区支持来集成这些静态分析工具，如 clang-tidy、clang-analyzer、CodeChecker 等。然而，另一部分 C++ 代码运行在 UE（Unreal Engine）引擎中。由于 UE 在编译流程上做了一些特殊扩展，再加上 UBT（UnrealBuildTool）工具在某些能力上的限制，直接开启静态分析会遇到一些问题：

背景

在大型 UE（Unreal Engine）项目中，“模块/插件"是维持工程可维护性的基本手段。但随着工程规模增长，很容易出现循环依赖问题：

背景

近期在给一个项目换一些底层接口的日志处理部分。把原始的类 printf 的格式化方式换成 fmtlib / C++ 20 Text Formatting 的方案。

然后发现，替换完一段未执行的代码后，会发生内存写坏的情况。

前言

近年来可观测性领域越来越成熟，游戏服务的可观测性能力建设日益成为提升产品质量与运维效率的关键环节。随着游戏系统架构的不断复杂化，传统的监控和故障排查方式已难以满足业务高可用和用户体验优化的需求。通过健全的可观测性体系，可以实现对游戏服务全链路的实时监控、异常检测与分析，助力技术团队及时发现和定位问题，推动产品持续优化与稳定迭代，从而为玩家提供更加流畅和可靠的游戏体验。

前言

我给我们的服务器框架深度集成了一些可观测性的能力。使用 opentelemetry-cpp 作为接入层。 在指标方面，我们允许业务层自由地定制化指标上报和拉取，并以此实现策略控制。上报的时候有Pull模式接口（异步接口），也有Push模式接口（同步接口）。 为了减少 opentelemetry-cpp 内部的视图合并开销，性能最佳，我们尽量使用异步接口。 但是这种情况下由于 opentelemetry-cpp 内部存在后台Processor线程、Exporter线程等，指标的采集往往需要跨线程操作。 这就要求我们上报代码逻辑需要保证线程安全。

背景

设计 《libcopp对C++20协程的接入和接口设计》 的时候，由于C++20协程的promise和awaitable是链式关联的。所以当时设计promise和awaitable之间通过一个共享的context来通信交互。当时第一版实现直接使用了 std::shared_ptr 来管理共享引用，也预留了个规划是未来可以改成非线程安全的引用来减少不必要的Cache Miss开销。

背景

我们项目组需要接入多种RPC接入和工具转换流程，并且每种接入层有自己的扩展和定制需求。为了提高开发效率，我们需要一个通用的RPC代码生成器，能够支持多种RPC接入层级的代码生成，同时支持自定义插件和模板。并且自由增加自定义插件而不需要变更构建系统流程。以便提供最佳的灵活性且能支持protobuf的所有特性。

背景

我们的新项目有个比较复杂的全区全服交易行系统，其中搜索和推荐是高实时性全区服多维度排序的，并且要支持比较复杂的标签交集查询和属性范围查询的自由组合。 当有订单发生变化时，它不仅仅会影响全服状态下搜索和推荐条件的结果变化，也会同时影响商品维度的聚合，交易行层面的数据聚合。

前言

我们项目组前段时间排查和分析压测环境下的某些业务模块大量索引结构的内存问题。通用的工具比如 jemalloc+jeperf 或者 tcmalloc+gperf 的组合过于底层，一方面开启跟踪开销较高，另一方面也是会产生过多噪音数据影响判断。所以我针对我们的智能指针（包含 std::shared_ptr 和我最近写了个非线程安全的版本的 strong_rc_ptr ， 这个后面有空再分享）和STL容器实现了allocator来帮助动态的手动插桩来分析问题。 最终的效果是可以通过一键替换类型申明的Allocator来插入动态控制和插桩统计的能力，这里分享一下手夯标准STL allocator的一些实现细节，方便其他小伙伴如果需要做类似的实现来参考。

背景

这篇分享拖更了好久了。问题起源于去年我们项目组接入 opentelemetry-cpp 的时候，在进程优雅退出的时候偶现超时，虽然可以直接kill进程没啥影响但是退出不“优雅”的话总归会破坏发布流程，增加人工介入的成本。这里记录一下问题可能其他的组件有类似的用法也会有相似的问题。