🏠 home › journal › 2026-04-24

2026-04-24 变更日志

摄取 Google TPUv8 全面解析（公众号深度文，转引 Cloud Next 2026 官方）

来源：raw/notes/google-tpuv8-deep-dive-2026-04.md（公众号 TPU 系列深度解析，转引 Google Cloud Blog 2 篇官方原文：TPU 8t/8i deep dive + Virgo Network；发布事件 Google Cloud Next 2026，2026-04-22 拉斯维加斯）

新建页面

关键知识提取

  1. Google TPUv8 把训练-推理硬件分叉做到了产品 SKU 层 — 不是"训练芯片砍刀做推理"，而是 TPUv8t 保留 SparseCore + 3D Torus + Virgo + FP4，TPUv8i 删 SparseCore + 加 CAE + 3x SRAM + Boardfly 拓扑——die 平面图重新设计两条线。这与 AWS Trainium 单 SKU 收敛、NVIDIA NVL72/144 模块化堆叠形成 2026 三大硅商路线分歧 → 与 training-inference-bifurcation 的连接：本概念页就是为承接这条洞察而抽出的——TPUv8 是首个产品级证据，把"workload 分叉是结构性的"从假说变成被旗舰 SKU 验证的事实

  2. 跨 DC 100 万 TPU 单训练把电力卡脖子从绝对约束削成相对约束 — Virgo fabric 设计目标是把跨园区训练做成可行——训练规模不再被单 DC 电力上限锁死。这部分反向缓解了 hidden-chokepoints 中大型燃气轮机交付排队 2-3 年的隐性卡脖子，但电力总盘子仍是约束，且 "近线性 scaling" 宣称未被独立验证 → 与 hidden-chokepoints 的连接：原页认为燃气轮机是"看不见的垄断 + 数据中心建多快取决于电厂建多快"，本次摄取在该页新增"跨 DC 训练对电力瓶颈的反作用"段落，把 fabric 层创新对供应链卡脖子的"削弱但未消除"关系做出来

  3. Boardfly 用 OCS + Dragonfly 思路解决 reasoning + MoE 的 All2All 通信瓶颈 — 3D Torus 在 1024 芯片下最远 16 跳，对 dense 训练相邻通信友好但对 MoE token 路由 + reasoning 多步 sampling 灾难性。Boardfly 的 7 跳是"网络层必须为推理 workload 重新设计"的直接产物——CAE chiplet 卸载 collectives 的努力会被远端 16 跳吃掉，所以拓扑层也得重做 → 与 training-inference-bifurcation 的连接：Boardfly 是训练-推理分叉在网络层的证据，与 die 层（CAE vs SparseCore）、内存层（384MB SRAM vs HBM 优先）、scale-out 层（Boardfly vs Virgo）一起构成"分叉是全栈的"完整图景

  4. Google "2.8x FP4" 对比 Ironwood 的 "FP8" 是分母偷换 — 这是 keynote 营销陷阱的典型模式：新代芯片刚加 FP4 支持时没有跨代同精度数据可比 → 用旧代 FP8 数当 FP4 数 → 翻倍优势凭空出现。同精度对比下提升幅度小于 2.8x。AI 算力是 2026 资本市场最大叙事之一，万亿美金 capex 决策依赖这些数字，每一处偷换会被层层放大到二级市场 → 与 ai-vendor-spec-traps 的连接：本页就是为承接这条洞察而抽出的——把"批判性消费厂商宣称"做成 6 条 checklist 防御性资产，方法论上类比 profit-source-ethics（先建批判框架再批判性消费叙事）

  5. 硬件分叉与平台层坍缩是方向相反的镜像现象 — 软件层：模型厂商往上吞噬应用 / SDK / Agent runtime（platform-layer-collapse），栈在收敛；硬件层：通用 TPU 拆成训练 + 推理两颗 SKU，栈在分叉。共同信号：AI workload 已经成熟到可以重塑栈的两端——上端被吞，下端被拆 → 与 platform-layer-collapse 的连接：在该页相关概念加 training-inference-bifurcation 链接 + 注 "方向相反的镜像现象"。两个概念互为对照，加深"AI workload 成熟度"这一根本判断

  6. 国产芯片追赶难度结构性上升：要同时跟两条 SKU + DC fabric + 全系统协同 — 智谱 GLM-5.1 在昇腾 910B 上做到 SWE-Bench Pro 58.4 是国产硬件的强证据，但同月 Google 把硬件参照系再次推高。国产芯片要追的不再只是单芯片算力，而是 SKU 拆分能力 + DC fabric + 全系统协同——结构性追赶难度上升 → 与 china-us-ai-gap 的连接：原页只覆盖软件模型层差距（GLM-5.1 vs Claude Opus 4.6），本次在该页新增"硬件层差距：Google TPUv8 设的新参照系"段落，把硬件层参照系拉进差距讨论，且对照 ai-vendor-spec-traps 提醒不被 FP4/FP8 偷换分母放大焦虑

更新页面

事实核查记录

待办

补充：FundaAI 范式视角（2026-04-24 同日追加）

来源：raw/notes/fundaai-tpuv8-commentary-2026-04.md（FundaAI Substack 2 篇独立分析师评论文，非 Google 官方 blog；属性需明确标注） - https://fundaai.substack.com/p/deepai-infra-2026-shifting-from-brain - https://fundaai.substack.com/p/deeplite-googles-newly-introduced

新建页面

关键知识提取（4 条）

  1. 这次升级的是 DCN（scale-out），不是 scale-up — TPUv8t 仍 3D Torus，只是 SerDes 升 224G；真正改的是 Virgo 把 scale-out 带宽 4x、做到 134K 单 fabric / 跨 DC 100 万 TPU。市场把发布读成"3D Torus 升级"是错的——拓扑层变化发生在 DCN 而非 chip-to-chip → 与 virgo-fabric 的连接：在该页新增"DCN vs scale-up 误读修正"段，引用 FundaAI in-rack switch tray 评注预言；这个区分对国产追赶的意义是"要补的是 DCN 全栈能力，不只是 chip-to-chip 互联"

  2. Dragonfly 拓扑哲学统一 scale-up + scale-out — Boardfly（Pod 内 scale-up 范畴）借鉴 Dragonfly，Virgo（DCN / scale-out）也走"分组 + long links + 高 radix + OCS"思路。两层网络的设计哲学正在收敛，传统"Torus 做 scale-up / fat-tree 做 scale-out"的二分被打破——拓扑选择首先服从 workload 通信模式（All2All / bisection bandwidth 主导），不再首先服从物理分层 → 与 boardfly-topology 的连接：在该页新增"Dragonfly 哲学统一 scale-up + scale-out"段，把 Boardfly 与 Virgo 殊途同归讲清楚；这是 training-inference-bifurcation 的反向力量——硬件分叉但拓扑哲学收敛

  3. compute-driven → bandwidth-driven 是范式转变（最高权重论点） — Google 不是在"升级网络"，而是承认整个 AI 系统从单芯片 FLOPS 上限走向 bisection bandwidth 上限。MoE All2All + reasoning 多步 sampling 让"chip 1/3+ 时间在等数据"成为常态。CAE chiplet / 224G SerDes / Virgo 4x 带宽 / Boardfly 7 跳全部是同一范式驱动力下的产物——单芯片算力已富余，通信成新硬约束 → 与 google-tpu-v8 的连接：在主页"定义"之后插入独立的"范式总论"段，把 die / scale-up / scale-out / DC-to-DC 四层证据全部串到 bandwidth-driven 框架下；这是给读者的"读 TPUv8 不要只读单芯片参数表"的元解读

  4. Optics 从外围辅助晋升为系统级核心约束 — 光通信链路（OCS / transceiver / 激光器 / 长距光纤 / co-packaged optics）从"机房布线问题"变成"决定 token throughput 的硬瓶颈"。FundaAI 推算：scale-up OCS port 比 1.5:1 → 2:1～10:1，scale-out 0.2:1 → 1:1，TAM 阶跃式扩张。投资 / 产业含义：在味之素 ABF / TOTO ESC / 燃气轮机之外，光学供应链是 2026 起的新增隐性卡脖子点 → 与 optics-as-scaling-constraint 的连接：本概念页就是为承接这条洞察而抽出的；同时回连 hidden-chokepoints 作为该页待补的第四类案例 + 回连 china-us-ai-gap 作为国产追赶的额外结构性难度

更新页面

事实核查记录

待办

DeepSeek V4 开源（同日追加）

来源：raw/notes/deepseek-v4-release-2026-04.md（InfoQ 公众号文章，作者冬梅，转引 DeepSeek 官方公众号 + 技术报告 + Engram 2026-01 论文） - 模型开源：https://huggingface.co/collections/deepseek-ai/deepseek-v4 - 技术报告：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf - Engram 论文：https://github.com/deepseek-ai/Engram/blob/main/Engram_paper.pdf

新建页面（3 页）

关键知识提取（6 条）

  1. 跨硬件解耦战略首次产品化 — V4 是首个明确把细粒度专家并行（EP）方案在 NVIDIA GPU 与华为 Ascend NPU 双栈完成验证的旗舰开源模型；NxCode 等第三方分析认为这是首个"完整可用的、frontier 级中国 AI 技术栈，从芯片到模型，无任何美国软件成分"。但当前开源工具链 gaMoE / DeepGEMM / TileLang 仍主要基于 CUDA bit-级对齐，价格下调依赖 2026 下半年昇腾 950 超节点上市 → 与 model-hardware-decoupling 的连接：本概念页就是为承接这条战略而抽出的；同时回连 china-us-ai-gap 作为模型侧给国产追赶节奏添加的反向力量、回连 asymmetric-chokepoints 作为模型厂商主动 hedge 非对称博弈的工具化实践

  2. 模型层 SKU 拆分对照硬件层 SKU 拆分 — V4-Pro（1.6T 总参数，对标 Gemini-Pro-3.1）+ V4-Flash（284B 总参数，极低成本接近 GPT-5.2 / Gemini 3.0 Pro）双 SKU 拆分，逻辑与 Google TPUv8t / v8i 硬件层拆分同源不同层：workload 已成熟到可以为不同场景独立设计 → 与 training-inference-bifurcation 的连接：在该页新增"模型层 vs 硬件层 SKU 拆分对照"段；与 google-tpu-v8 行业脉络段形成跨层对照——硬件按 workload 分家、模型按场景分家、并发于同一时间窗

  3. Engram "查—算分离" 是新一轴稀疏性（梁文锋署名） — 传统 Transformer 把事实性记忆与逻辑推理混在同一组 dense 参数里，等于用深度逻辑电路反复重建本该是哈希查找的操作。Engram 把固定模式存入哈希查找表 O(1) 调用，dense 参数专注推理。MoE 是 conditional computation（按 token 路由专家），Engram 是 conditional memory（按 token 查 hash 表），两者正交可叠加。论文给出新稀疏分配律：iso-参数 + iso-FLOPs 下最优 75-80% 计算 + 20-25% 记忆——对"MoE 已是终极稀疏方案"的实证否定 → 与 engram-conditional-memory 的连接：本概念页就是为承接这条架构创新而抽出的；CEO 个人下场署名通常代表公司战略方向，2026-01-13 论文 → 2026-04-24 V4 集成体现"开源研究先行 → 工程化跟进"的 DeepSeek 节奏

  4. 6.1 TFLOP/GBps 论点与 bandwidth-driven 范式形成对立 — 技术报告对硬件厂商的反向指引："当前每 GBps 互联带宽足以覆盖 6.1 TFLOP/s 的计算需求，盲目增加带宽会带来收益递减"。模型侧已经把通信 / 计算融合到 1.5-1.96x 加速（"波"切分专家——波内通信完成立即开始计算 + 当前波计算 + 下一波 token 传输 + 已完成专家结果发送三者并行），所以认为通信层已经够用 → 与 optics-as-scaling-constraint 的连接：在该页新增"模型侧反向视角"段，平衡 FundaAI 的"光学晋升核心约束"与 DeepSeek 的"通信已经够用"两个对立判断；知识库保留张力不强行合并，这是 2026 系统层的核心争论之一

  5. Engram 的确定性寻址绕过 HBM 容量约束 — hash 函数确定性给定 token → 必然查到固定 entry → 大型 embedding 表可 offload 到 host memory（CPU 系统 RAM）而非 GPU HBM，runtime prefetch 开销可忽略。HBM 是 2026 国产芯片相对薄弱的环节之一——这是模型架构层对硬件层约束的反向破解，也是 model-hardware-decoupling 的具体技术承载之一 → 与 engram-conditional-memory / optics-as-scaling-constraint 双向连接

  6. 开源模型追平闭源是平台层坍缩的对冲信号 — V4-Pro Codeforces Elo 3206（人类第 23 / GPT-5.4 持平）/ SWE-Verified 80.6%（接近 Claude Opus 4.6 80.8%）/ Terminal Bench 2.0 67.9%（与 GPT-5.4 持平）/ SimpleQA-Verified 57.9%（远超前代开源约 30%）。但 MRCR 1M / CorpusQA 1M 长上下文检索 Opus 4.6 仍明显领先（约 10 分），素材原文未强调 → 与 platform-layer-collapse 的连接：在该页"反向力量"段新增"开源模型层追平闭源"信号；与 ai-vendor-spec-traps 的连接：DeepSeek 自报数字也需要 6 条 checklist，特别是"同 workload 对齐"——长上下文检索是 V4 相对薄弱的子集，被选择性弱化

更新页面（6 页）

事实核查记录

待办

6.1 TFLOP/GBps 论点深化（同日追加，第四节）

来源：raw/notes/deepseek-v4-6.1-flop-gbps-deep-dive-2026-04.md（curl 直抓 V4 PDF + pdftotext 提取 + GB300 数值核查）

缘起：知识库初版把 DeepSeek "6.1 TFLOP/GBps" 与 FundaAI bandwidth-driven 处理成"对立张力"，过简化。回头读 V4 论文原文 + 算 GB300 数字后发现：两侧覆盖不同物理层级，各自坐标点上都正确，应作为 Roofline 框架的不同切片处理。

新建页面

关键知识提取（4 条）

  1. 6.1 数字非黑箱，完全可推导 — 论文 §EP Scheme：每 token-expert pair 6hd FLOPs（SwiGLU 三 projection）/ 3h bytes 通信（FP8 dispatch + BF16 combine），简化 C/B ≤ 2d。V4-Pro d=3072 → 阈值 6144 FLOPs/byte = 6.1 TFLOPS/GBps。通信精度是 FP8 + BF16，不是 FP4——之前理解里这条偏差被原文修正 → 与 compute-vs-bandwidth-roofline 的连接：本页就是为承接完整推导而抽出的工具页

  2. GB300 现实算账：V4-Pro × FP8 训练 NVLink 富余 2.2x — GB300 单 GPU NVLink 5 = 1.8 TBps，按 V4 训练精度（FP8）C/B = 5 PF / 1.8 TBps = 2.78 TFLOPS/GBps，远低于 6.1 阈值。DeepSeek 论点对这个组合完全成立。但 FP4 训练精度下 ratio 升到 8.33，超过阈值——FP4 时代 NVLink 反而偏紧。GPT-5 量级模型 d≥8192 阈值升到 16+，GB300 NVLink 远不够用。NVIDIA 把 NVLink 推到 1.8 TBps 不是过度，是按 frontier 模型设计 → 与 compute-vs-bandwidth-roofline / ai-vendor-spec-traps 的连接：这种"看起来权威但有边界"的数字应纳入批判性阅读 checklist

  3. 两侧不在同一物理层级，"对立"过简化 — DeepSeek 6.1 论点覆盖 NVLink/IB/卡间互联（TB/s 量级），FundaAI bandwidth-driven 覆盖 DC fabric / 跨 DC 光纤（Pb/s 量级）。DeepSeek 论文完全没有覆盖 virgo-fabric 那一层（DC 级 134K 芯片 / 跨 DC 100 万 TPU）。两边其实都对，但场景不重叠 → 与 optics-as-scaling-constraint / virgo-fabric 的连接：在 optics 页"模型侧反向视角"段重写为"覆盖不同物理层级"，删除"对立"措辞

  4. 国产芯片窗口期具象化 — 按 V4-Pro × FP8 训练 ratio = 2.78 TFLOPS/GBps，国产芯片只要 NVLink-equivalent 互联做到约 900 GBps（GB300 的一半），就够支撑 V4-Pro 训练。但 FP4 训练时门槛升到 ~1.6 TBps，frontier 模型时门槛升到 ~3 TBps+ → 与 model-hardware-decoupling / china-us-ai-gap 的连接：在 model-hardware-decoupling 加"国产芯片窗口期具象化"段——国产追赶"模糊的通信不重要"变成"可量化的具体目标 + 与 frontier 增长速度赛跑"

更新页面

事实核查记录

待办

摄取 BK7258 AI 玩具 IoT 架构导读（同日追加，第五节）

来源：raw/snippets/bk7258-build/iot-architecture-onboarding.md（Sentino 内部工程文档 /Users/momo/local/bk7258aitoypro/projects/common_components/IOT_ARCHITECTURE.md，700 行 / 七部分。写给"互联网后台背景"新人）

缘起：Sentino 内部为新加入的后台背景工程师写的入门文档。覆盖三件 wiki 此前没有上位概念页的事：(1) 后台 vs IoT 概念对照表 + 7 条嵌入式与后台关键差异；(2) 业务/适配/SDK/BSP 四层固件分层 + import/export = Hexagonal；(3) 4G 设备没有蓝牙时如何拿到 MQTT 接入点 + 5 种方案 + 信任根问题。这三块是补足 Sentino IoT 系列概念页的"上位上下文层"——之前 wiki 直接讲了 mqtt-device-protocol / ble-provisioning / device-lifecycle，但没有"为什么 IoT 跟后台不一样"的元层。

新建页面（3 页）

关键知识提取（5 条）

  1. "后台 vs IoT 概念对照表"是 wiki 缺失的元层 — 此前 wiki 直接讲 MQTT/BLE/设备生命周期/RTSA 各种具体技术，但缺 "为什么 IoT 跟后台不一样" 的上位陈述。后台工程师没有这一层会反复在"为什么不是 HTTP req/resp"、"为什么状态要存 Flash"、"为什么重启是解决方案"上撞墙。10 行对照表 + 7 条差异是这个心智模型的最短路径 → 与 iot-platform-fundamentals 的连接：本页就是为承接这条洞察而抽出的；同时回连 sentino-iot 在"经验教训"段加"后台背景工程师入门"指路条目，把这页定位为入门必读

  2. import/export 命名约定 = Hexagonal/Ports & Adapters 的嵌入式版本 — Sentino 适配层（rino_interface）的 import/export 命名长期被认为是"嵌入式特殊命名"，但本质上完全等价于 Hexagonal 的 Driving Port / Driven Port——SDK 是六边形内核，import 是被动暴露给业务回填（≈Spring DI），export 是主动暴露给业务调用（≈ SDK 接口包）。这个识别让"为什么这么分层"从工程经验论变成有架构理论支撑的判断 → 与 embedded-firmware-layering 的连接：本页就是为承接这条架构判断而抽出的；同时与 harness-engineering 形成跨域同构连接——嵌入式适配层 ↔ Agent 平台 Harness 都是"把核心做成黑盒、把环境做成可替换层"，Sentino 在嵌入式和 Agent 平台两个领域做这种分层是组织级架构判断的一致性

  3. "99% 的产品迭代只动业务层"是分层架构最直接的回报 — 业务/适配/SDK/BSP 四层每层的"知道什么/不知道什么/谁会换"具体到表格——加 DP 点改业务层 / 接入云端新增命令改适配层 / 换连接的云平台域名改 SDK / 换芯片整层换 BSP。4G 形态切换具体到改动清单：BSP 重写 + 适配层小调整 + 上层零改动。这把"分层有用"从抽象判断变成可量化承诺——客户对话时可以直接用这套数据 → 与 embedded-firmware-layering / sentino-iot 的连接：在 sentino-iot 关键决策段新增"底层 SDK 已为 4G 形态留好基础设施"一条，把"分层架构 + 已留位"两件事连成"Sentino 工程成熟度"的对外叙事

  4. MQTT 接入点不在固件硬编码是 Sentino 一个重要但容易被误解的设计 — mqtt-iot.sentino.jp:8883 是配网时 APP 蓝牙下发到 Flash 的，不是固件常量。rino_iot_common.h:10 QCLOUD_IOT_MQTT_DIRECT_DOMAIN 是腾讯云原厂 SDK 留下的常量、当前业务流程不读它。这条事实在排查"MQTT 连不上"问题时容易被误以为是固件硬编码——实际是 Flash 里的配网信息。设计好处是 APP 端可以根据用户区域/账号路由到不同 MQTT 集群（国内/海外、生产/测试、多租户），固件出厂后不用换 → 与 ble-provisioning / iot-device-bootstrap / mqtt-device-protocol / sentino-iot 的连接：分别在四个页面加这一事实——BLE 配网包加完整 8 字段表 + sentino-iot 关键决策段加新条目 + mqtt-device-protocol 加 broker 地址来源 + 经验教训段加排查指南

  5. "开机第一个连谁"在 4G 形态下是结构性问题，5 种方案 + 信任根不可避免 — 4G 设备没有蓝牙就不能用"配网时下发"路径，必须从 5 种方案里选：硬编码 / 引导服务器（行业主流，AWS Fleet Provisioning + 阿里一型一密 + 腾讯动态注册）/ DNS / HTTP 配置 / LwM2M。核心洞察是"不可能零硬编码"——固件总得硬编码某个入口作为信任根，区别只是入口的形态（host:port / Bootstrap URL / 逻辑域名 / 配置 URL / BS server URI）+ 信任怎么验证（TLS pin / DNSSEC / 文件签名 / DTLS PSK）。Sentino SDK factory_dynamic_register.c 已经为方案 B 留好基础设施，纯 4G 形态产品扩展路径清晰 → 与 iot-device-bootstrap 的连接：本页就是为承接这条结构性问题而抽出的；同时与 sentino-iot 关键决策段连接——Sentino 当前不需要 4G 形态但已经留好扩展能力，这条事实强化了"工程成熟度"的对外叙事

更新页面（6 页）

事实核查记录

待办