Tuple
从元组与嵌套结构的数学定义出发，理解 profile、rank、depth 与 size，并对应到 CuTe 的 Tuple、Shape 和 Stride API。
完整正文 · CUTLASS 与 CuTe：原理、编程与优化INFERENCE PERFORMANCE LAB
推理优化
从请求调度到 GPU Kernel，拆解生成式模型服务的真实瓶颈。
覆盖 Serving 架构、连续批处理、KV Cache、并行策略、多模态链路与算子优化，并用统一负载记录吞吐、时延、显存和稳定性。
查看相关性能数据 →01调度与编排
02KV Cache
03并行与通信
04GPU Kernel
NOTES FIELD RECORDS
推理优化工程记录
CuTe 中的整数
解释 Int<1>{}、静态整数与普通整数的区别，以及静态信息如何在类型、模板参数和运算中保留。
完整正文 · CUTLASS 与 CuTe：原理、编程与优化Layout 起源
从行优先、列优先和 padding 出发，理解 shape:stride 如何统一表达矩阵存储，并进一步描述分块与嵌套布局。
完整正文 · CUTLASS 与 CuTe：原理、编程与优化从BF16到FP8：HunyuanVideo1.5推理优化复盘
本文复盘了 HunyuanVideo1.5 在单卡 L40S 上从 BF16 优化到 FP8 优化的过程。我们先把 BF16 路径做到相对充分优化，再引入 FP8，避免用一个过弱 baseline 放大 FP8 收益。 实践发现，FP8 并不是换掉 Linear dtype 就会自动变快。activation 需要运行期量化，weight layout 必须保持 column-major，不同 GEMM shape 也需要选择不同 backend。初始 FP8 版本反而明显慢于 BF16；经过 weight layout 修正、GEMM kernel 优化、多 backend selector、QKV 共享 activation quant、producer-side pre-quant 等优化后，最终 FP8 版本达到 282.44s，快于优化后的 BF16，也优于 vLLM-Omni 和 LightX2V 的 FP8 对比结果。 核心经验是：FP8 优化不是单个 GEMM benchmark 的胜利，而是完整推理 hot path 的系统工程。layout、量化开销、backend 选择、模型语义和 runtime 分发都会影响最终端到端收益。
完整正文 · performance