基准测试

近期记录的 DeepSeek V4.1 Flash 1017、Muse Spark 与 MiniMax-M3.1-Flash 对比，明确工作负载与质量局限，并介绍正确性测试框架。

最新记录的文本推理对比

这里选取五张 A40 上的 DeepSeek V4.1 Flash 1017、十张 A40 上的 Muse Spark与八张 A40 上的 MiniMax-M3.1-Flash结果。每一行都保留模型、量化、放置方式、工作负载与参照模式；不同指标的最佳 TensorSharp 模式不同，不能把这些行合成总分，也不能据此推断其他硬件或模型的加速比。本次文档更新没有重新运行 DeepSeek 与 Muse Spark 的基准；MiniMax-M3.1-Flash 的数据来自 2026-10-24 的运行。

DeepSeek V4.1 Flash 1017：精确与近似 prefill

记录于 2026-10-22–23：五张 NVIDIA A40（每张 46 GB），unsloth/DeepSeek-V4.1-Flash-1017-GGUF，UD-IQ2_XXS、六个分片，Hugging Face 修订 60ad3651。TensorSharp 使用未修改的 ggml da8e2a5 与 --tp 5；参照是 Unsloth llama.cpp be836572 的按层切分，使用它自带的 in-tree ggml。上下文为 32,768 token，并发 1，输出 256 token，贪心采样、关闭思考；预热后运行三次取中位数。

默认 YOCO 重放是近似执行。设 TS_DSV41_YOCO_KEEP=0 使用精确 prefill。记录的 teacher-forced wikitext-2 检查中，困惑度为精确 2.4811 / 默认近似 2.4978 / llama.cpp 2.4697（越低越好）。近似吞吐量必须与这项质量代价一起阅读，不能称为精确执行的加速比。

速率使用两个引擎的内部 prefill 计时，不是流式 TTFT 或客户端总耗时。参照数据来自另一轮会话，不能声称这是交替执行的受控实验，也没有给出置信区间。5.50× 只对应上表约 1.8K token、单请求、默认近似 TP5 的工作负载。模型布局、启动设置、数值检查及构建与来源局限见 DeepSeek V4.1 模型卡。选择支持的运行路径 →

十张 A40 上的 Muse Spark 816B

报告更新于 2026-10-22，未记录实际测量日期。Muse-Spark-Open-816B-A42B，UD-IQ3_XXS、八个分片，全部专家驻留显存，十张 A40 46 GB，ggml_cuda，32,768 上下文、F16 KV、flash attention、关闭思考。记录中的 TensorSharp 工作树构建使用未修改的上游 ggml da8e2a5，llama.cpp 为未修改的 7170cad，使用其自带的 in-tree ggml。按层切分对照 -sm layer，张量并行对照 -sm tensor。

Muse Spark 的 prefill 为未缓存的提示 token 数除以流式 TTFT，与上面的 DeepSeek 内部计时指标不同。按层切分给出记录中最高的 prefill，张量并行给出记录中最高的生成吞吐。比值大于 1 表示吞吐更高，按层切分 decode 的 0.99× 也予以保留。TensorSharp 与 llama.cpp 按层切分耗时为三次重复的中位数；llama.cpp 张量并行各行只有两次。参照的短提示与 4K 张量并行行来自相同构建的较早会话。Teacher-forced 按层切分与 llama.cpp 的平均 KL 散度为 0.0026；集成校验用例不构成通用模型质量评测。

单台主机，没有可用的 P2P 或 NVLink：TensorSharp 通过主机内存使用 NCCL；llama.cpp 的 NCCL 构建在十张 GPU 上中止，因此参照构建未启用 NCCL，传输条件是重要限制。模型文件位于网络文件系统。图像、投机解码、CPU 专家卸载、16K 以上上下文、其他 GPU 数量与非 CUDA 后端未测量。报告没有冻结最终 TensorSharp 提交，也未提交完整原始记录；这是已记录的工作树构建对比，不是对本次文档提交的基准。完整环境、逐场景结果与局限 →

八张 A40 上的 MiniMax-M3.1-Flash

2026-10-24 测量。Unsloth MiniMax-M3.1-Flash UD-Q4_K_XL，七个分片 / 232.3 GiB，八张 A40 46 GB GPU，ggml_cuda，未注明时为按层切分。TensorSharp 使用未修改的上游 ggml da8e2a5；参照为 unslothai minimax-m31 分支（ef8f94cc，PR #320）的 llama.cpp。同一台机器，两个引擎轮流运行且独占 GPU，三次重复取中位数。

服务器 prefill 按未缓存提示 token 数除以流式首 token 时间计算；llama-server 使用 -np 1 --no-kv-unified（否则 MiniMax 稀疏注意力以稠密方式运行），引擎按 ABBA 轮换（两次启动之间未清除页缓存，因此不比较加载时间）。llama-bench 的每个 prefill 单元取 -ub 512 与 -ub 2048 中较快者，64K 单元为单次运行。短对话与并发时的首 token 时间略慢于 llama.cpp。不用草稿器时，两个引擎在这些 DSpark 提示上的 decode 分别为 22.9 与 20.5 tok/s。--tp 8 在深度 2,048 之后降到 26.0–26.5 tok/s，并把上下文限制为 45,824 token，因为注意力与缓存在每张 GPU 上镜像；该数字来自合并前张量并行分支的构建。

限制：使用未提交的工作树构建而非冻结的提交；只有一台主机与一个检查点，没有置信区间。未测量视频、其他 GPU 数量与后端，以及完整检查点的困惑度或 KL 散度（已测量 MoE CPU 卸载：decode 1.30×、4K prefill 1.62×，两次重复）；与 llama.cpp 的 logit 一致性只在合成夹具上检查。原始记录是测量主机上的本地验证证据，未提交。所有单元、方法与限制 →

其他模型家族各有能力与工程说明：文本模型、图像模型、视频模型。上述选取的文本对比不对这些工作负载作性能承诺。

测试

下方构建与测试命令需要按平台安装的 .NET 10 SDK；运行命令前请先验证安装。

单元测试（xUnit）

InferenceWeb.Tests 测试无需运行服务器的进程内行为：托管量化运算、直接 CUDA 与 MLX 后端内核（在硬件可用时）、分页 KV 调度、批量执行器正确性、各模型批量前向与单序列路径的一致性、MTP / NextN 推测解码正确性、纯 C# DeepSeek V4.1 执行器对独立 PyTorch 参考实现的数值门控、DiffusionGemma 探针、编解码器往返、提示词渲染，以及服务器 CLI 选项构建器。

其中 V4.1 那一项值得展开说。InferenceWeb.Tests.Dsv41CpuExecutorTests 把 DeepSeek4CpuExecutor（--backend cpu 跑 DeepSeek V4.1 Flash 所用的 100% 纯 C# 执行器，不依赖 ggml、不依赖原生库、不依赖 GPU）对齐到独立的 PyTorch 参考实现 eng/dsv41-reference.py，容差 atol=rtol=2e-5，并要求贪心 argmax 完全一致，覆盖一次性 prefill、分块 prefill（块大小 1/3/5/8，逐位置检查）与 reset。有两条注意事项必须一起交代：夹具检查需要 TS_DSV41_FIXTURE_DIR，不可用场景会显式跳过；而 fixture 是刻意做小的 —— 五层、256 隐藏维、16 token 的 F32 合成模型 —— 因此它证明的是与参考实现的架构级一致，而不是真实 246 GiB Q2_K 权重上的 CPU/CUDA 一致性。它是正确性与可移植性路径，而非服务路径，这也是它只出现在这里、不出现在上面任何表格里的原因：--backend cpu 上跑完整 V4.1 权重的吞吐、加载时间与常驻内存都从未测量过。

dotnet test InferenceWeb.Tests/InferenceWeb.Tests.csproj

Pull request 的 CI 在 GitHub 托管的 x64（ubuntu-latest）与 ARM64（ubuntu-24.04-arm）runner 上运行该测试集中与环境无关的那一档：它强制关闭 GPU 原生构建（CUDA、Vulkan 与 cuDNN），固定 TS_TEST_GGML_BACKEND=cpu，先运行不需要 GPU 的 GB10 容器契约检查 eng/tests/gb10-container.py，全程不需要 GPU，也不下载模型。在本地运行同一档：

dotnet test InferenceWeb.Tests/InferenceWeb.Tests.csproj --filter "Category!=Bench&Requires!=Cuda&Requires!=Mlx&Requires!=Models"

服务器集成测试

TensorSharp.Server.Host/testdata/ 中的集成测试覆盖全部三种 API 风格（Web UI SSE、Ollama、OpenAI）、多轮对话、思考模式、工具调用、结构化输出、队列状态兼容、并发请求与中止支持。架构相关功能会自动检测，并在当前模型不支持时跳过。

# 先启动 TensorSharp.Server.Host，然后运行：
python3 TensorSharp.Server.Host/testdata/test_multiturn.py
# 或
bash TensorSharp.Server.Host/testdata/test_multiturn.sh

推理矩阵运行器

TensorSharp.TestMatrix 是更广泛的、由 CLI 驱动的长时段 模型 × 后端 × 功能 × 环境变量 覆盖框架。它发现 GGUF 文件、过滤不可用后端与不支持的提示类型、运行基线加环境变量扫描的各个 cell、为每个 cell 写一份 JSON 结果、生成聚合 Markdown 报告，并与各主机基线对比。

dotnet build TensorSharp.TestMatrix/TensorSharp.TestMatrix.csproj -c Release
dotnet run --project TensorSharp.TestMatrix -c Release -- --dry-run