前文 《大语言模型的基石：Transformer 入坑笔记（四） - 线性注意力(Linear Attention) 的基础》 介绍了线性注意力的基本思路：把历史 K/V 压进固定大小的状态，避免每次读出都遍历完整历史。 但计算量降下来以后，还有两个问题：有限状态该怎样保留和更新信息，以及怎样把递推计算组织成 GPU 擅长的大块矩阵运算。
各家 LLM 对长上下文的解决方案并不完全一致。Kimi K3 发布后，我自己体验下来效果相当好，也因此想了解它所用的 KDA。 此前公开的 《Kimi Linear: An Expressive, Efficient Attention Architecture》，正好给出了这条路线的设计和实验。
这篇继续梳理 Performer、DeltaNet、GLA、Mamba-2 / SSD 和 Gated DeltaNet，重点放在状态更新与分块计算上。最后再到 KDA 的逐通道 Delta 更新。
涉及的论文比较多，我也是零散地抽时间看和理解，阅读周期拖得比较长。这里主要记录公式和计算过程，性能结果以各论…
接上文 《大语言模型的基石：Transformer 入坑笔记（三） - 注意力机制和 Transformer》。
通过之前的内容，我们大致了解了大语言模型的基石：Transformer 的基础原理。 但随之而来有一个问题：随着参数量和上下文长度的增长，计算量太大扛不住了。
现在很多大语言模型，经过了多轮迭代，终于陆陆续续能在参数量持续提高的前提下同时支撑 1M 上下文。
接上文 《大语言模型的基石：Transformer 入坑笔记（二） - 基本原理和 Word Embeddings》，继续我们的 Attention Is All You Need/Transformer 学习之旅。
首先简单了解下传统的方案。
卷积神经网络（CNN）似乎更适合静态数据（比如图片处理、提取特征等）。 所谓静态数据，是指每个数据组都单独和目标矩阵运算，通过卷积层、池化层、全连接层等输出。 每个数据组都单独运算所以可以大规模并发，但是数据组之间也缺乏关联。 我大概看了下原理，和我们要关注的 Transformer 关系不大，先略过了。
继续我们的 Attention Is All You Need 学习之旅。
我不是这个领域的，只是感兴趣想补一下基础，所以这一篇先只看最通用的原理：神经网络训练的大概流程、Embedding 是什么，以及 Word2Vec 里两种常见优化思路。
Attention Is All You Need 最早落在机器翻译任务上，它提出的核心架构就是 Transformer。工程上我们常接触到的 Transformers 库，则是围绕这类模型提供了更完整的封装。
这几年 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。
海报和宣传图看着都很唬人，但真到自己拿去干活的时候，往往还是会闻到一点“跑分没输过，实战没稳过”的味道。所以我干脆把最近几个真实使用场景里的体验记了下来。
很久很久以前，我为了解决以前项目中bus通信膨胀的问题设计了 libatbus, 当时主要解决的核心问题是解决大量服务器节点互通时服务器间两两建立通道时的大量内存浪费问题。也同时使用跨进程的无锁队列避免了多写单读场景下的加锁以提高性能。
前段时间例行升级我为游戏框架写的构建系统 cmake-toolset 时，又遇到了 protobuf 的一个新 ABI 兼容性问题。
这已经不是第一次被 protobuf 的 ABI 兼容性问题“教育”了。这篇把问题拆开讲清楚，并给出一套可落地的规避方案，供遇到类似问题的同学参考。
首先在链接阶段出现错误：
近期，公司代理侧的流量负担持续上升；在高峰期访问常见开发资源（包管理器、SDK、依赖镜像、CDN 文件等）会出现明显抖动。为降低重复下载带来的外网带宽开销与峰值波动，决定在内网引入一套“通用下载缓存代理”。
现代化的C++项目可以借助多种静态分析工具来检查和发现潜在问题，包括空指针访问风险、未定义行为（UB）、内存错误等。
在我们的项目中，服务器工程基于 CMake 构建系统，可以方便地利用社区支持来集成这些静态分析工具，如 clang-tidy、clang-analyzer、CodeChecker 等。然而，另一部分 C++ 代码运行在 UE（Unreal Engine）引擎中。由于 UE 在编译流程上做了一些特殊扩展，再加上 UBT（UnrealBuildTool）工具在某些能力上的限制，直接开启静态分析会遇到一些问题：
在大型 UE（Unreal Engine）项目中，“模块/插件"是维持工程可维护性的基本手段。但随着工程规模增长，很容易出现循环依赖问题：
.so/.a 时），最终表现为 循环依赖UBT（UnrealBuildTool）能检测到循环依赖，但输出的是 ActionGraph 层面的信息：大量 Action #xxxx，并提示"这些 action 互相成环”。对于实际排障来说，主要痛点在于：
近期在给一个项目换一些底层接口的日志处理部分。把原始的类 printf 的格式化方式换成 fmtlib / C++ 20 Text Formatting 的方案。
然后发现，替换完一段未执行的代码后，会发生内存写坏的情况。
通过跟踪生成的汇编和 gdb 的 info frame 位置。发现替换之后，栈帧位置大幅增加了。比如对这类代码:
近年来可观测性领域越来越成熟，游戏服务的可观测性能力建设日益成为提升产品质量与运维效率的关键环节。随着游戏系统架构的不断复杂化，传统的监控和故障排查方式已难以满足业务高可用和用户体验优化的需求。通过健全的可观测性体系，可以实现对游戏服务全链路的实时监控、异常检测与分析，助力技术团队及时发现和定位问题，推动产品持续优化与稳定迭代，从而为玩家提供更加流畅和可靠的游戏体验。
我给我们的服务器框架深度集成了一些可观测性的能力。使用 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的所有特性。
我们的新项目有个比较复杂的全区全服交易行系统，其中搜索和推荐是高实时性全区服多维度排序的，并且要支持比较复杂的标签交集查询和属性范围查询的自由组合。 当有订单发生变化时，它不仅仅会影响全服状态下搜索和推荐条件的结果变化，也会同时影响商品维度的聚合，交易行层面的数据聚合。