这次在 NVIDIA B300 和 PPU 上做 RDMA visibility 实验，我想建立的对照是：不加额外处理时读错，加入处理后恢复正确。但截至 2026 年 10 月 14 日的实验记录，两组一直都通过。值得整理的是，每次未复现以后改了什么条件，以及查到的 OWNER 保证怎样改变了我对结果的理解。

从 Oct 12 开始训练。

国庆节和鑫鑫去了越南。

总的体会

• 各种 skill、harness 等返璞归真，不太需要了，模型自己有非常强的能力。
• 模型自己本身的防御性编程意识非常浓厚，需要进行限制。否则写出来的代码非常啰嗦。

本文来自于我和 GPT-6 聊天的总结。

本文只解释结构：输入从哪里来，模块如何连接，哪些位置能够互相读取，以及推理时保存什么数据。例如模型里的数据通路，以及 GPU 上的计算和缓存组织。

覆盖范围以 Transformer 和大语言模型为主，同时补充经典序列模型、视觉、语音和图数据中常见的 Attention 结构。

Database paper part 1–7：对照论文原文的核查报告

核对日期：2026-09-22。按 7 篇博文组织，覆盖其中 23 篇论文／技术报告及 Titan 工程延伸，共保留 36 处值得纠正或澄清的表述。

核查日期：2026-09-22。使用 chatgpt 6 修订该站 Redis 标签下的六篇文章。

本地版本依据实际 Git HEAD 确认：

二者均为 unstable 开发快照，不直接等同于 Redis 5.0 / 6.0 正式版。对象篇的 dict 分析使用 2018 快照，其余主要使用作者明确链接的 2020 快照；涉及跨版本结论的地方另行标注。

学习 RDMA 的基本知识。

讨论如何评估一个 RDMA 网络。

这篇笔记想弄清楚两个问题：把历史 KV 放进更大的内存池，究竟是在节省计算，还是在扩展 GPU 的活跃工作集？一份 KV 即使命中了缓存，把它恢复到能继续计算的状态，又要付出多少代价？

我更愿意从“复用一份计算状态”来理解 KVCache，而不是从“增加一层缓存”开始。它类似于数据库中的物化中间结果：保留下来能省掉一部分计算，但结果不在执行端时，还要把它取回来。大语言模型在生成过程中又会反复读取历史状态，这就让“恢复一次”和“每一步都从外部读取”成了两笔性质不同的账。

下面用一份 4 GiB 的 KV 串起这些问题，这个大小会从模型参数推出来。全文的主线是：先辨认正在复用什么状态，再沿实际路径计算搬运成本，最后看它是否减少了请求的等待。文中的产品参数来自公开资料，计算使用的工作负载与有效带宽则是明确设定的算例，不是实测成绩。