Mengman 的异想世界

在单台 DGX Spark 的部署中，“量化”至少涉及三类不同数据：模型权重、PLE 查找表和 KV Cache。它们都是 FP4 或 FP8 类型，但量化对象、scale 粒度、读取方式和反量化位置并不相同。 如果只说“模型采用 NVFP4”，很容易产生两个误解。第一，checkpoint 中的每一个张量并不一定都使用同一种格式；第二，权重量化解决的是固定参数的容量问题，不能阻止 KV Cach

0. 摘要 / TL;DR DeepSeek-V4.1-Flash 是一个 552B backbone、196B Engram 参数的多模态 MoE 模型，prefill 每 token 激活 8B，decode 每 token 激活 16B，支持 100 万 token 上下文。它的核心目标不是继续堆参数，而是把长上下文 Agent 的部署成本打到新低。 它通过 CED、CSA2、FP4 KV

上一篇介绍整体部署方案时，我们把 Qwen3.8-Flash-Next 的参数分成了两类。一类是注意力、GDN、MoE 和视觉塔中的矩阵权重，它们会在推理过程中被 GPU 反复读取；另一类是 n-gram embedding 查找表，它的容量很大，但每个 token 只访问少量离散表项。 这两类参数不应该采用相同的部署方式。前者需要留在 GPU 能够高效访问的位置，后者则可以放到容量更大、速度更慢

Qwen3.8-Flash-Next 的主模型有 125B 参数，另外还有 51B n-gram embedding 参数。把这样一个模型放到只有 128GB 统一内存的 DGX Spark 上运行，问题不只是选择一种更低精度的权重量化格式。模型权重、PLE 查找表、KV Cache、CUDA 工作区和 Linux 文件页缓存最终会竞争同一个内存池，任何一项估算得过于乐观，都可能让服务在加载或长请

五分钟全景图 论文名称: “FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution” (2026, Shuo Yang*, Xiaoze Fan*, et al.) 一句话概括 FreeToken 是一个边缘原生的 MoE（混合专家）模型推理系统，它不再把个人电脑（如游戏本、工作站）当作&quo

我在上一篇文章 “从 CUDA 到 Triton：深入理解 Triton 的即时编译与自动调优” 中介绍了 triton 编译缓存，同时还介绍了如何在部署环境复用编译缓存。 本篇文章我将介绍编译文件中的 manifest 文件对于缓存命中的影响。 回顾 Triton 编译缓存文件 缓存默认存储在 ~/.triton/cache/ 目录下。在该目录中你可以看到一系列以哈希命名的文件夹，每个文件夹内包

目标： 安装, 测试 将 MathFunctions 库安装到 lib 目录下，头文件安装到 include 目录下 将 Tutorial 可执行文件安装到 bin 目录下 为 Tutorial 添加单元测试， 并且使用 ctest 来执行测试 源码实现 MathFunctions/CMakeLists.txt 123456789# TODO1 设置要安装的库 "MathFuncti

目标: 学习使用 cmake 中的 Generator Expression 语法。 Generator expressions 是 CMake 中一种强大的功能,它允许用户根据生成系统的状态有条件地设置变量或选项。这种表达式在构建时进行计算和展开,因此可以根据构建配置的不同动态地设置值。 源码实现 使用 Generator Expression(GE) 根据不同的编译器，为 target 添加不

flex-gemm 是一个使用 triton 开发的稀疏卷积库，在运行的过程中因为要根据输入数据进行算子调优，所以在计算时间上有很大的波动。在解决 flex-gemm triton 算子编译优化的过程中，系统性的学习了一下 triton 的编译流程。 这里写一篇文章做个记录。 一、CUDA 编程核心 1.1 线程架构 NVIDIA GPU 的设计哲学是“用海量线程隐藏内存延迟”。为了高效管理这些线

独立草稿模型的两大痛点 草稿模型输出 token 的概率分布与目标模型存在偏差，限制了草稿的接受长度。 在部署的时候再额外维护一个小模型的成本太高。 自主多头预测架构 (Self-Speculative / Multi-Head Decoding) 的解法：把草稿模型“吞进”目标模型内部。 在目标模型上增加多个独立的预测头作为草稿模型，并且复用目标模型的 hidden-state 来确保在概