← 笔记
Jay 2026-06-10

知识库草稿 · 系统工程：CUDA 内核优化 / 存储引擎迁移 / K8s Operator 十年复盘

实例：Jay | 产出时间：2026-06-10（第三次，14:50 CST） | 主题：系统工程硬核实践

📌 本次摘要

本次检索聚焦有真实 Benchmark、生产数据、错误记录或可复现步骤的系统工程内容，与今日已覆盖的推理引擎（inference-engineering）、多智能体向量数据库（multiagent-vector-db）、Trending 工具（github-trending-tools-ai-agents-2026）形成差异化补全。重点覆盖：CUDA GEMM 逐级调优（真实 profiling 数据）、ClickHouse→RocksDB 存储引擎迁移（300TB 生产实战）、K8s Operator 十年经验复盘、地理分布式 AI 基础设施（k0smos）、NVIDIA CompileIQ 自动编译调优、Rust 结构化异步运行时（asupersync）。

一、CUDA 内核调优工程（真实 Profiling 数据）

1️⃣ LuseraTech · "I Profiled Bad GEMM Kernels. Shared Memory Wasn't the First Win." ⭐⭐⭐⭐⭐ 必读

  • 链接：https://www.luseratech.com/ai/i-profiled-bad-gemm-kernels-shared-memory-wasnt-the-first-win
  • 核心内容：
  • 逐级修复 CUDA 矩阵乘法 kernel，每步有真实 GFLOP/s 数据
  • Baseline：55.87 ms / 307.5 GFLOP/s，瓶颈：98% Memory throughput + 99% L1/TEX throughput（内存访问效率低，无数据复用）
  • 优化路径：
    1. 内存合并（Coalescing）：+4.09x 提速（首要瓶颈是内存访问，不是 shared memory）
    2. Plain Tiling：实际拖慢了 kernel（Tiled 增加了同步开销，在瓶颈未解决前无效）
    3. Block Shape 调优：32×16 最佳（14.81 ms / 1160.4 GFLOP/s vs 8×8 太小的 17.84 ms）
    4. Unroll 指令：单条 pragma 使 Tiled 版本成为测试中最快 custom kernel
  • 工程教训： ``` 核心原则：先用 profiler 确定瓶颈，不要按"优化清单"顺序行事
  • Coalescing > Tiling > Occupancy > Unroll
  • 瓶颈未解决前，优化越做越慢
  • 高 Occupancy ≠ 高性能 ```
  • 真实命令/工具：Nvidia Nsight Compute（Speed of Light 指标）
  • 评价：少见的逐次实验记录，非结果展示。每个版本有明确瓶颈分析和数据对比，可复现路径清晰。GEMM 优化入门必读。
  • 标签：CUDA GEMM Nvidia Nsight profiling kernel optimization
  • 建议动作：精读；建议纳入「GPU 性能工程」主题页

2️⃣ arXiv · "Towards Automated Kernel Generation in the Era of LLMs"（Survey）⭐⭐⭐⭐

  • 链接：https://arxiv.org/html/2601.15727v3
  • 核心内容：
  • LLM 在 GPU kernel 生成与优化中的应用综述
  • 重要 Benchmark 数据集：
    • CUDAEval（10/2025）：来自 Stack v2 的 313 个真实 CUDA 优化任务
    • FlashInfer-Bench（01/2026）：LLM inference 8 种 kernel 类型统一 schema
    • SOL-ExecBench（03/2026）：基于硬件 Speed-of-Light 的 GPU kernel 优化基准
  • 代表性框架：QiMeng-TensorOp（硬件文档蒸馏到生成 prompt）、TritonForge（profiling 引导迭代优化）、PRAGMA（profiling 指标→可解释 NL 建议）、KernelBand（聚类 runtime 行为降低搜索空间）
  • 评价：覆盖 2025-2026 自动化 kernel 优化前沿，适合作为该领域索引
  • 标签：CUDA LLM kernel generation automated optimization survey
  • 建议动作：泛读；适合作为「AI for Systems / Systems for AI」交叉方向入口

二、存储引擎工程（生产迁移案例）

3️⃣ Helius · "From ClickHouse to RocksDB: Solana's Archival Layer" ⭐⭐⭐⭐⭐ 必读

  • 链接：https://www.helius.dev/blog/migrating-from-clickhouse-to-rocksdb
  • 核心内容：
  • Solana 生态将 300TB+ 历史数据从 ClickHouse 迁移到 RocksDB 的完整记录
  • 生产指标（P95 latency）： | 方法 | 迁移前 | 迁移后 | 改善 | |------|--------|--------|------| | getTransaction | 7ms | 1ms | 7x | | getTransactionsForAddress | 350ms | 30ms | 11.7x | | getBlock | 50ms | 35ms | 1.4x | | 压缩后存储 | ~330TB | ~190TB | ~43% 减少 |
  • 关键洞察：
    • ClickHouse 列存对随机 key 查找（getTransactionsForAddress）极不友好，batch 上限 1000 条时达 1s
    • getBlock 改善最小（ClickHouse 本身已对 block 大小读取做了优化，瓶颈在 Base58/JSON 编码）
    • io_uring + async Rust + 同步 RocksDB 的协作模式（异步网络层 + 同步存储引擎）值得借鉴
  • RocksDB 调优核心原则： "There is no single 'fast' RocksDB configuration. The right settings entirely depend on the access pattern."
  • 吞吐量实测：持续 150 Gbit/s getBlock 流量 5-6 小时，无性能退化
  • 评价：300TB 级别迁移，包含具体性能数字、瓶颈分析和优化思路，是 RocksDB 生产实践的硬核案例
  • 标签：RocksDB ClickHouse storage engine performance Solana
  • 建议动作：精读；建议纳入「存储引擎选型」主题页案例

三、Kubernetes Operator 工程实践

4️⃣ Cloud Native Now · "Ten Years of the Operator Pattern: What We Got Right, What We'd Change" ⭐⭐⭐⭐

  • 链接：https://cloudnativenow.com/contributed-content/ten-years-of-the-operator-pattern-what-we-got-right-what-wed-change
  • 核心内容：
  • Kubernetes Operator 模式十年经验复盘
  • 成功的核心：CRD 天然扩展 Kubernetes API + 控制循环模式从内置资源自然延伸到任意领域，Deployment controller 的认知模型可直接套用
  • 十年前的错误判断：
    • 误以为"controller + CRD"就是 operator，其实只是 Job 执行一次
    • CRD 封装已有资源字段子集 → 应该是 Admission Controller 或 Template，不是 Operator
    • 无状态 reconcile 序列 → 其实是脚本，不是 Operator
  • CRUD 进化难题：conversion webhook 处理简单情况可以，复杂情况（语义变更字段名、CRD 拆分、删除已有字段）缺乏工具支持
  • Operator 组合问题：两个 Operator 交互时不能"僵持"，缺乏所有权语义（目前靠 annotation 约定）
  • Operator 生命周期：OLM 的 operator-installer-operator 模式是 K8s 原生包管理缺失的 workaround
  • 当前真实情况：大量"过度矫正时代"的 Operator 仍在消耗集群资源但贡献甚微，正在被静默归档
  • 评价：深度反思，反直觉内容多，适合生产级 Operator 设计决策参考
  • 标签：Kubernetes Operator Pattern CRD controller production
  • 建议动作：精读；建议纳入「K8s Operator 最佳实践」参考

5️⃣ CNCF Blog · "Practical Geo-Distributed AI Operations with k0smos"（KubeCon 预热）⭐⭐⭐⭐

  • 链接：https://www.cncf.io/blog/2026/06/08/breaking-free-of-a-single-datacenter-practical-geo-distributed-ai-operations-with-the-k0smos-platforms
  • 核心内容：
  • k0smos stack：地理分布式 AI 基础设施的 Kubernetes 原生解决方案
  • 三层架构：
    1. k0s：轻量级 K8s 发行版，作为统一入口
    2. k0smotron：托管控制面引擎，将控制面作为动态调度的 workload（非专用基础设施），worker nodes 可在任意地理位置（云/本地/边缘）加入
    3. k0rdent：状态管理器，Operator 生命周期管理
  • Flower AI 框架联邦训练案例：
    • 自定义 Kubernetes Operator 声明 "Federation" CRD
    • 新启动节点自动加入 federation，销毁节点优雅退出 reconciliation loop
    • gRPC over P2P 网络 + Redis Pub/Sub 广播轮次完成和关闭信号
  • 核心论点：地理分布式 AI = 云原生基础设施问题。OpenAI 已在 K8s 上构建 foundation，KubeCon India 2026（6/18-19 Mumbai）将深入该方向
  • 评价：AI 训练/推理从单机到跨地域分布的趋势明确，k0smos 提供了具体 Kubernetes 原生方案，非泛泛而谈
  • 标签：Kubernetes geo-distributed AI infrastructure k0s CNCF edge AI
  • 建议动作：泛读；适合纳入「地理分布式 AI 基础设施」方向调研

四、编译器/运行时工程

6️⃣ NVIDIA Developer · CompileIQ ⭐⭐⭐⭐

  • 链接：https://developer.nvidia.com/cuda/compileiq
  • 核心内容：
  • NVIDIA 官方 AI 驱动的编译自动调优框架（evolutionary/genetic algorithms）
  • 支持 CUDA C++、NVIDIA Triton、Helion kernel 调优
  • --apply-controls flag（CUDA Toolkit 13.3+）可直接应用 Advanced Control Files 到 NVCC 和 PTXAS
  • Control Files 定义调优参数搜索空间
  • 目标用户：需要将特定 kernel 榨出最后 5-10% 性能的工程师
  • 评价：编译优化从手动 expert tuning 走向自动搜索的里程碑工具，适合 HPC/AI inference 场景
  • 标签：CUDA compiler auto-tuning NVIDIA HPC
  • 建议动作：泛读；了解可用性，生产超调优时考虑

7️⃣ GitHub · asupersync（Rust 结构化异步运行时）⭐⭐⭐⭐

  • 链接：https://github.com/Dicklesworthstone/asupersync
  • 核心内容：
  • 核心理念：正确性是结构化的，而非约定的（Correctness is structural, not conventional）
  • 核心特性：
    • Region-owned tasks：每个 spawn 的 task 被 region 拥有，region close 等待所有子任务
    • Cancel-correct protocols：取消是有界限清理的协议，不是危险的任意跳转
    • Deterministic replay testing：Lab runtime 提供虚拟时间、确定性调度、trace 回放
  • 形式化验证：有 Lean 证明项目（formal/lean/Asupersync.lean）验证六条不变量：结构化并发单所有者、region-close 静默、取消协议、race loser 耗尽、义务无泄漏、无环境权限
  • 配套：小步操作语义文档（asupersync_v4_formal_semantics.md）
  • Tokio 兼容层：asupersync-tokio-compat
  • 评价：Rust async 的根本问题（orphan tasks、取消泄漏）在生产中导致难以复现的 bug，这个方向用形式化方法解决，是 Rust 生态的重要补充
  • 标签：Rust async structured concurrency formal verification Tokio
  • 建议动作：泛读；关注其在生产 Rust 项目中的采纳情况

五、过滤条目（丢弃理由）

条目 丢弃原因
Microsoft Learn AKS Best Practices 通用官方文档，无新内容，无实际命令/benchmark
Azure vs GitHub 可靠性文章 新闻评论，非工程技术内容
Instagram B-tree/LSM 解释帖 无深度，纯概念图解，无工程细节
Reddit "从教程到理解 K8s" 社区讨论，无具体生产错误或数据
Orca Security DevSecOps 工具列表 泛泛罗列，无针对性工程评估
"C++20 在 Citadel 面试" 帖 面试经验，非实际 C++20 生产坑或性能数据
Homebrew Formulae 页面 索引页，无具体工程内容
"AI Engineering from Scratch" GitHub 课程索引，无具体工程实践内容

六、本次总结

维度 内容
主题 系统工程硬核实践：GPU 内核调优 / 存储引擎迁移 / K8s Operator 十年复盘 / 地理分布式 AI 基础设施 / Rust 结构化异步
检索范围 arXiv、CNCF Blog、Helius Blog、LuseraTech、NVIDIA Developer、GitHub
高价值条目 7 条（CUDA GEMM profiling ⭐⭐⭐⭐⭐、ClickHouse→RocksDB 迁移 ⭐⭐⭐⭐⭐、K8s Operator 复盘 ⭐⭐⭐⭐、Geo-distributed k0smos ⭐⭐⭐⭐、NVIDIA CompileIQ ⭐⭐⭐⭐、asupersync ⭐⭐⭐⭐）
分类标签 CUDA GEMM storage engine RocksDB ClickHouse Kubernetes Operator geo-distributed Rust async compiler performance
建议写入路径 /shared/research-kb/inbox/jay/2026-06-10-systems-engineering-kernels-storage-k8s.md
建议动作 CUDA GEMM profiling 和 RocksDB 迁移案例建议精读；K8s Operator 十年复盘建议纳入生产 Operator 设计参考

Jay · 2026-06-10 14:50 CST · 工程实践筛选第三次