功能特性

TensorSharp 目前能力的完整目录。每一项都链接到你可以使用它的页面。

亮点

模型与模态

• 多架构支持 —— DeepSeek V4 Flash、DeepSeek V4.1 Flash、GLM 5.2、GLM-5.3、GLM-5.3-Flash、Gemma 4、DiffusionGemma、Qwen 3.5/3.6-family、Qwen 3.8 Flash Next、GPT OSS、Nemotron-H、Mistral 3、Hunyuan Dense、Muse-Glimmer、Qwen-Image-Edit、MiniMax-H3 音视频、Wan 2.1 / 2.2 视频。→ 支持的模型
• DeepSeek V4 Flash（284B MoE） —— 一套压缩稀疏注意力、1M 上下文的架构，配有三套专属的整模型执行器：Direct CUDA 引擎（--backend cuda）、原生 ggml 执行器（ggml_cuda / ggml_vulkan），以及 100% 纯 C# 的 CPU 执行器（--backend cpu，零原生依赖）。权重自动按层切分到所有可见 GPU，服务端以原生 per-sequence slot 与连续批处理托管它。→ DeepSeek V4
• DeepSeek V4.1 Flash（384 个路由专家） —— 专用的原生 V4.1 计算图：四条残差流与延迟 hyper-connection 混合、带候选块过滤的 lightning indexer，以及在第 1 层与第 14 层注入的 Engram n-gram 特征；两张合计 60.2 GiB 的 Engram 表默认驻留 GPU，在图内直接 gather。服务后端是 ggml_cuda；ggml_cpu 是标量正确性通道，cpu 是 100% 纯 C# 的 V4.1 执行器（无 ggml、无原生依赖、也不用 GPU），已按 atol=rtol=2e-5 对齐独立的 PyTorch 参考实现 eng/dsv41-reference.py 并要求贪心 argmax 完全一致，但只验证到五层 F32 fixture 的规模 —— 那是与参考实现的架构一致性，而非真实量化权重上的对齐 —— 因此它是正确性与可移植性路径而非服务路径，并且在这条路径上只支持文本（视觉伴随文件是原生 ggml 组件）；cuda 用直连 CUDA 引擎自己的内核运行 V4.1，但尚未通过数值门槛。mlx 会拒绝该检查点。图像与视频需要单独准备的视觉伴随文件，音频会被拒绝；每一种量化都必须先准备好 Engram sidecar 才能运行 —— Q2_K 与 Q4_K_M 均已测试。→ DeepSeek V4.1
• GLM 5.2（744B-A40B MoE） —— 带权重吸收的多头潜在注意力（MLA）加上 DeepSeek 稀疏注意力的 lightning indexer，256 个路由专家 top-8 加一个共享专家，自报 1M 上下文，直接从 6 分片的 split GGUF 加载。两套实现：一个原生整模型 ggml 执行器（ggml_cuda / ggml_vulkan / ggml_cpu / ggml_metal，把 226 GiB 按层切分到所有可见 GPU），以及 --backend cpu（100% 纯 C#、零原生依赖）与 --backend cuda 使用的托管逐算子路径。→ GLM 5.x
• GLM-5.3（非 Flash，256 个路由专家，仅文本） —— 非 Flash 的 5.3 与 GLM-5.2 是同一套 glm-dsa block 结构 —— 79 个 block（78 个主干 + 1 个 NextN）、256 个路由专家 top-8 加一个共享专家、带 lightning indexer 的 MLA、rope base 8e6（n_rot 64）—— 因此它就走 GLM-5.2 那条加载路径，既不需要新代码也不需要新参数：同一个架构描述符同时服务 GLM-5.2、GLM-5.3 与 GLM-5.3-Flash，Flash 与非 Flash 的区别只是 general.architecture 上的一个布尔值。下载 unsloth/GLM-5.3-GGUF，每种量化一个子目录，每个都是多分片集合 —— 把 --model 指向 -00001-of- 那个分片；UD-Q2_K_XL 是七个分片、236.4 GiB。它在两重意义上仅文本：该仓库在任何量化下都没有发布 mmproj，而且 LoadVisionEncoder 在 glm-dsa 上遇到 --mmproj 只会告警并忽略它，于是得到的是一次纯文本运行，而不是一次失败。自报的 1M 上下文是个上限：除非用 MAX_CONTEXT 明确指定数值，加载器会按设备容量下调。原生整模型执行器可跑在 ggml_cuda / ggml_vulkan / ggml_metal / ggml_cpu 上；托管逐算子路径则用于 --backend cpu / cuda，或在 GGML 后端上设 TS_GLM_NATIVE=0。--spec（必须在加载前就出现在命令行上）从 blk.78 那个完整的 NextN block 起草；该 block 没有随附 nextn.shared_head_head.weight，因此借用主干的 LM head —— 推测解码在默认的按层切分下、也就是不传 --tp 时生效。--tp N 可以接受，但仅限本地单进程，且 MLA 与 indexer 缓存按 rank 复制，多于一个 rank 的配置尚无实测；--tp-node-id / --tp-peers 对整个 GLM 家族都会在模型构建之前就被拒绝。在 8× A40 46 GB（无 NVLink）上与 llama.cpp 实测（UD-Q2_K_XL、10,531 token 提示、300 个 decode token、三次取中位数、整层放置）—— 与 Flash 不同，llama.cpp 对这个型号是有效的参照引擎：prefill 251.6 t/s、decode 20.48 t/s，加载耗时 264 s；llama.cpp 为 decode 20.28 t/s、加载 753 s —— decode 打平，而 236.4 GiB 的检查点加载快 2.9×；老实说差的一项是 TTFT，41.9 s 对 29.0 s（约慢 1.4×）。→ GLM 5.x
• GLM-5.3-Flash（320B MoE，文本 + 图像） —— 这个混合后继型号走的是与 GLM-5.2 完全相同的原生执行器和同一个 GlmDsaModel，GGUF 架构 id 为 glm5next，在其之上叠了四处架构改动：45 个主干层中有 34 层用 KDA 线性注意力，另外 11 层用 NoPE MLA + DSA，一个池化 indexer（4 格一池，先在池上取 top-k 2048，再展开到池内成员），×4 流的 Sinkhorn 超连接，以及上限为 10 的 SwiGLU 截断；288 个路由专家 top-8 加一个共享专家、×2.5 路由缩放，46 个 block = 45 主干 + 1 NextN。不传 --tp 时默认按层切分到所有可见 GPU，支持 --cpu-moe / --n-cpu-moe，并通过原生 per-sequence slot 提供服务。在 GGML GPU 后端上，--tp N 与 GLM-5.2 一样选择仅支持本地单进程的原生张量并行：KDA / MLA head 与路由专家隐藏行切分，KDA 递归状态按 rank 持有。完整切分、每张本地 GPU 一个 rank、不启用 CPU MoE 或 tracing、且具备原生超连接内核时，按 rank 分段计算图会并发提交：路由 MoE 局部输出先归约，随后每个 rank 在本地计算并加入其复制的共享专家，再进入 Sinkhorn 超连接；超连接、池化 indexer、router、norm、稠密层与 embedding 保持不切分并按 rank 执行，output norm / LM head 留在 rank 0。CPU MoE、tracing、部分切分、超额 rank 或缺少原生超连接内核时选择组合调度器回退，其中共享专家只在 rank 0 运行一次；TS_GLM_TP_FUSED=0 可强制该诊断回退。NextN/MTP 推测解码仍未支持。视觉能力来自 mmproj-BF16.gguf（GLM-OCR ViT）：支持 --image、多图与多轮图像会话。在 2× RTX PRO 6000 Blackwell（96 GB）上与 llama.cpp 对比实测，UD-Q2_K_XL（101 GiB），两个引擎都用分层切分、n_ubatch 均为 2048、背靠背运行：tg64 为 73.5 对 36.6 t/s —— decode 达到 llama.cpp 的 2.0×，prefill 两边相差均在几个百分点以内（pp2048 2014 对 2070，pp16384 1692 对 1690，pp32768 1446 对 1483）。它同样能跑在 100% 纯 C# 的 --backend cpu 路径上（文本），但那是用于对拍的参考实现而非快路径：prefill 约比 ggml_cpu 慢 5.7×、decode 约慢 2.4×，prefill logits 与 ggml_cpu 的余弦相似度为 0.9567 —— 已经很接近，但并未被证明达到逐位一致，因此在前两名接近打平时贪心解码出的文本会分叉。→ GLM 5.x
• Qwen 3.8 Flash Next（混合 MoE，文本 + 图像） —— 48 层里有 36 层是 GatedDeltaNet 循环层，与全注意力层交错（其中一些位于 Qwen 稀疏注意力的 indexer 之后），第 1 层还有一个 PLE n-gram 嵌入块，外加 ×4 超连接流与 512 专家 top-10 的 MoE（hidden 2560，24 个 query / 2 个 KV 头，head_dim 256，词表 248320）。GGUF 架构 id 为 qwen4exp。在 GGML 后端上，整个 token（几乎）作为一张计算图运行 —— 嵌入、图内 PLE、全部 48 层、最后的 mixer 与 LM head —— 并从按形状索引的已捕获图缓存中重放。视觉走 Qwen3.5-VL 塔并使用 (T,H,W) IMRoPE，因此多图与多轮图像会话都可用，并能跨轮复用 KV（只能向后延长：GDN 的循环状态无法回退）。思考、服务端，以及基于 per-sequence 状态持有器的连续批处理均已支持，--tp N 则运行多 GPU 分层切分。通用工具调用尚不可用：这个家族还没有能返回工具调用的输出解析器。→ Qwen 3.8 Flash Next
• 多模态推理 —— Gemma 4 支持图像、视频与音频输入；Qwen 3.5-family、Qwen 3.8 Flash Next、GLM-5.3-Flash、Mistral 3、Nemotron-H Omni 与 Muse-Glimmer 支持图像。→ 多模态
• PDF 文档输入 —— 原生数字（born-digital）PDF 会完整提取文本层并内联进提示词；扫描版 PDF 则回退为页面图像，交给具备视觉能力的模型。可通过 Web UI 上传使用，也可用 CLI 一次性生成的 --pdf 参数；用 TS_PDF_MAX_PAGES 限制读取的页数（默认：全部）。→ Web UI
• 专家混合（MoE） —— Gemma 4 MoE（如 26B-A4B）、GPT OSS MoE（gpt-oss-20b）、Qwen 3.5/3.6 MoE（35B-A3B）、Nemotron-H MoE FFN 层，以及 GLM 5.2（744B-A40B：256 个路由专家 top-8 加 1 个共享专家，sigmoid 门控路由带一个只影响选择的 bias 与 x2.5 的路由缩放），配以融合的批量 GPU MoE 调度。
• 混合 SSM-Transformer —— Nemotron-H 在一个模型中混合 Mamba2 SSM 层、注意力层与 MoE FFN。
• 混合注意力-循环 —— Qwen 3.5/3.6-family 将全注意力层与 GatedDeltaNet 循环层混合；Qwen 3.8 Flash Next 在 48 层中的 36 层上同样如此，并加上 PLE n-gram 块、×4 超连接流与 512 专家 MoE；GLM-5.3-Flash 则在 45 个主干层中用 34 层 KDA 线性注意力、其余用 NoPE MLA 加池化稀疏 indexer。
• 音视频联合生成（MiniMax-H3） —— 一个 50 块的扩散 Transformer 把视频与原生 32 kHz 立体声音轨当作同一份打包潜变量去噪，音轨因此是模型输出本身，而不是事后配上去的。四种条件模式（--video-mode t2v / i2v / fl2v / ref）：只给提示词、把一张照片当首帧动起来（--image）、给定首尾两张关键帧（--end-image），或用最多九个身份参考——静图、片段与音轨——去生成全新场景（--ref-image / --ref-video / --ref-audio）。两个去噪器是彼此独立的检查点而非开关：关键帧要 FL2VA 那个文件，参考要 Ref2VA 那个。它经过 CFG 蒸馏，因此必须用 --cfg 1.0，默认 20 步、4–8 步是快车道。可从 CLI、/api/video-generate、/v1/videos/generations 或 Web UI 驱动；MP4 会附带一个旁挂的 .wav。四种条件模式同样可以跑在 100% 纯 C# 的 --backend cpu 路径上，零原生依赖。→ MiniMax-H3
• 视频生成，仅画面（Wan 2.1 / 2.2） —— Wan 2.1（文本 → 视频）与 Wan 2.2 TI2V-5B / A14B（文本 → 视频，以及图像 → 视频，上传的图像作为首帧）可从 CLI、/v1/videos/generations 或 Web UI 输出 H.264 MP4。把 --model 指向步数蒸馏权重（Turbo / Lightning / FastWan），管线会自动识别，把去噪循环从 100 次 DiT 前向降到 4 次。→ 视频生成
• 文本扩散生成 —— DiffusionGemma 使用迭代式 EntropyBound 去噪采样器，而非自回归解码。→ DiffusionGemma
• 图像编辑（Qwen-Image-Edit） —— 提示词 + 输入图像，经 60 块 MMDiT 扩散 Transformer、Qwen-Image VAE 与 Qwen2.5-VL-7B 文本编码器生成编辑后的图像（FlowMatch-Euler true-CFG、CUDA 图捕获的 DiT 前向）；可选的 Lightning 蒸馏 LoRA（--qwen-image-lora）能以 CFG 1.0 将去噪循环缩减到寥寥几步。→ 图像编辑

生成与控制

• 思考 / 推理模式 —— 带 <think> / <|channel> 标签的结构化思维链（Qwen 3.5/3.6、Gemma 4、GPT OSS、Nemotron-H、DeepSeek V4、DeepSeek V4.1、GLM 5.x）。→ 思考模式
• 工具调用 / 函数调用 —— 与架构无关的输出解析，无论模型输出的是 JSON（Nemotron-H）、<tool_call> 块内的 XML（Qwen 3.5/3.6）、GLM 5.x 的 <arg_key> / <arg_value> 成对标签、Harmony commentary（GPT OSS）还是 DSML 标记（DeepSeek V4，以及 DeepSeek V4.1 上带空格、受语法约束的变体），都会转成结构化 tool_calls。→ 工具调用
• 可配置采样 —— 温度、top-k、top-p、min-p、重复 / 存在 / 频率惩罚、随机种子与停止序列。→ 采样
• 结构化输出 —— OpenAI response_format 支持 text、json_object 与经过校验的 json_schema。→ 结构化输出
• 聊天模板 —— 从 GGUF 元数据自动加载（Jinja2），并按架构提供硬编码回退。
• 流式输出 —— 通过 SSE（Web）或 stdout（控制台）逐 token 输出，支持中止 / 停止进行中的生成。

Agent Skills（智能体技能）

• 技能是什么 —— 一个目录，里面放着 SKILL.md（YAML frontmatter + 写给模型看的 Markdown 说明），以及这些说明会用到的脚本、参考文档和素材。TensorSharp 扫描一个或多个技能目录（--skills-dir，或二进制文件旁边的 skills 目录），把每个技能的一行描述展示给模型，其余内容只在模型主动索取时才加载。→ CLI 参数 · HTTP 字段与端点 · C# API
• 两个内置工具（开启 --skills-allow-exec 后是三个） —— skills_list() 列出可达技能与随包路径；skills_read(skill, path, offset) 分页读取文件，包括 SKILL.md。skills_run(skill, path, args) 默认关闭；开启后仍使用解释器白名单、清洗过的环境、超时 / 输出上限，以及默认 required 的 OS 沙箱。
• 这些调用由 TensorSharp 自己应答 —— 在进程内、紧挨着权重完成。这正是该功能对“完全不了解技能”的客户端也成立的原因：普通的 OpenAI 客户端只要发 "skills": ["pdf"]，收到的就是一条已经写完的回复，而不是一个它根本无法执行的工具调用。调用方自己的工具则从不会被执行——它们照常回传给调用方。
• 渐进式披露 —— 对能调用工具的家族，启动提示词只放名称与描述，显式选中的技能也一样；元数据层约占上下文的 2%（约 1024–10000 token）。模型通过读取匹配技能的 SKILL.md 来激活它，随包文件仍按 48 KB 分页按需读取。无法完成工具往返的家族才会把选中技能正文内联。
• 提示词形态 —— 该文本块会并入首条 system/developer 消息，而不是另起一条——这是本仓库所有聊天模板都能正确处理的唯一注入点。它的每一个字节都是“排序后的技能选择”的纯函数：没有时间戳、没有路径、没有计数，因此同一段对话逐轮哈希结果一致，KV 前缀缓存可以从第 0 块起持续命中。
• 边界约束 —— 模型给出的每一个路径都要经过 SkillPathGuard，它同时封堵词法层（..、绝对路径、~、UNC、盘符限定）、规范化层与符号链接三类逃逸，并把每个技能限制在它自己的目录内。ZIP 安装同样让每个条目走这道关卡（zip-slip），按解压后的字节流校验大小，并设置单文件（64 MB）、整包（256 MB）、条目数（4096）与压缩比（200×）上限。
• 模型家族差异 —— 只有聊天渲染器与输出解析器都支持时才提供工具。Mistral 3 不承载工具声明，qwen4exp 则没有工具输出解析器；两者都会内联选中技能正文，并隐藏技能 / 代码工具，而不是发出无人能处理的调用。
• 智能体代码执行 —— --code-exec 增加 read_file、edit_file、write_file、shell 与 apply_patch。TensorSharp 在同一个有界循环中执行这些内置工具；调用方自己的工具从不代跑，仍回传调用方。普通技能循环默认 8 轮；提供代码执行时自动提高到 24 轮，除非运维显式设过上限。→ 架构、权限与平台限制
• 工作区与结果 —— Web/CLI 聊天跨轮保留一个工作区；每个 OpenAI/Ollama 请求在其内部轮次间拥有独立工作区，结束后删除。技能脚本与代码工具共用它。Web UI 用临时 tool_progress 显示实时活动，并保留生成文件链接；服务端产物可从 /api/code/artifacts/ 下载。
• 安全边界 —— 生成命令默认离线。macOS Seatbelt 与 Linux bubblewrap 0.12+ 会约束写入与主目录读取；macOS 无法保证清理故意脱离的子进程。Windows job object 只能约束进程树，无法限制文件或网络，因此 required 模式会拒绝代码；运维必须显式选择 --code-exec-unconfined（技能脚本则是 --skills-sandbox preferred）。TensorSharp 没有逐命令审批 UI：启动参数就是运维的决定。
• 结构化输出 —— 使用 response_format 的请求仍能选择技能，但技能正文会改为内联，内置技能 / 代码工具会被隐藏，因为 schema 约束下无法生成工具调用标记。
• 选择技能 —— CLI 用 --skill pdf，所有聊天 API 用 "skills": ["pdf"]（/v1/chat/completions、/v1/responses、/api/chat/ollama，以及 Web UI 的 /api/chat）；再加上 "skills_discovery": false，即可把本次请求限制在它点名的技能上。服务端同时暴露技能注册表本身 —— GET /v1/skills、GET /api/skills、POST /api/skills（上传 .zip）、DELETE /api/skills/{name}；/api/models 会返回一个 skills 块（enabled、installable、count），供前端判断是否要显示相关控件。可直接取用的开源技能：github.com/anthropics/skills。

性能与扩展

• 与 llama.cpp 同台较量、互有胜负 —— 在相同 GGUF 文件与相同 GPU 上，这个纯 .NET 引擎在关键负载上追平乃至超越手工优化的 C++ llama.cpp。在当前的对比运行中（短提示 / 长上下文 / 多轮文本场景，两个引擎均分别在 GGML CUDA 与 Vulkan 构建上测量，可通过 benchmarks/engine_comparison 复现）：Gemma 4 E4B 与 2-bit 量化的 Qwen 3.6 35B-A3B MoE 在 CUDA 上 prefill 快 1.28×、首 token 早 1.27×（多轮提示最高 1.49×），Gemma 4 12B 在 Vulkan 上 decode 快 1.21×（长上下文最高 1.32×），四个模型中有三个的 CUDA decode 持平或更快（Qwen 3.6 27B 几何平均最高 1.07×）。较早的一次 CUDA image_edit 运行还测得 TensorSharp 的 Qwen-Image-Edit 完成一次预热后的编辑用时 40.44 s，而 stable-diffusion.cpp 为 48.16 s（快约 1.19×）。→ 同台基准测试
• GPU 加速 —— GGML Metal（macOS）、GGML CUDA（Windows/Linux + NVIDIA）、GGML Vulkan（Windows/Linux + AMD/Intel/NVIDIA）、直接 CUDA/cuBLAS 后端，以及面向 Apple Silicon 的 MLX 后端 —— 均带 CPU 回退。→ 后端
• 连续批处理与分页 KV 缓存 —— 块分页 KV 池、块哈希前缀共享、可在批中接纳 / 抢占序列的迭代级调度器、可选 SSD 后备层，以及原生融合分页注意力内核。分页 KV 缓存位于主机内存，因此并发换来的是容量与公平调度而非吞吐 —— 无论同时有多少条序列，批量分页路径都会在约 69 tok/s 处饱和。→ 深入了解
• 批量 / 并行推理 —— 将 N 个序列打包进一次前向，配以分页 K/V 散写（Mistral 3、Gemma 4、GPT OSS、Qwen 3.5 / 3.6、Nemotron-H）。
• 张量并行与分布式推理 —— 用 --tp N（CLI 与服务端均支持）把一个模型切分到 N 张 GPU 上（Megatron-LM 列/行并行，归一化层 / 词嵌入 / LM head 复制），Direct cuda 后端与 GGML CUDA / Vulkan 后端都可运行，并通过点对点 TCP 网格（--tp-node-id / --tp-peers）把并行组扩展到多台机器。分层 AllReduce 让每次集合通信只有 1/tp_local 的数据上网；MoE 专家切分与专家并行、GatedDeltaNet 按 rank 的 V-head 归属与 Mamba2 复制覆盖了各类异构层。融合的按 rank block 计算图让 Gemma 4 上 --tp 2 的 decode 超过单卡（51.7 对 37.3 tok/s），也让单卡装不下的模型得以运行。不过 TP 并不是模型用上多张 GPU 的唯一途径：DeepSeek V4 与 GLM 5.x 不加任何开关就会按层切分到所有可见 GPU，--tp 对三个 GLM 5.x 型号都会选择仅支持本地单进程的原生 TP：GLM-5.2 与 GLM-5.3 使用层内部相同的 Megatron 切分（注意力 head 列并行、输出行并行，每个路由专家按行切分，router、norm、indexer 与共享专家复制，MLA 与 indexer 缓存按 rank 复制，因此缓存占用随 rank 数成倍增加），GLM-5.3-Flash 则切 KDA / MLA head 与路由专家隐藏行，两者都在 GGML GPU 后端上 —— GLM-5.3 在多于一个 rank 时尚无实测，唯一有记录的算术是一次装不下：--tp 8 每个 rank 需要 41.7 GiB，而卡只有 46 GB —— 在 DeepSeek V4 上则只是限制按层切分使用几张卡（等同 TS_DSV4_NGPU）。在 Qwen 3.8 Flash Next 上，--tp N 同样是分层切分 —— 每张 GPU 拿一段连续的完整层，不切分任何权重，这也是 llama.cpp 为这个架构提供的唯一多 GPU 模式。它是容量特性而非速度特性：在 2× A100-80GB 上用 Qwen3.8-Flash-Next-UD-Q2_K_XL（73.4 GiB）实测，双卡贪心输出与单卡逐字节相同、吞吐也没有变化（prefill 约 1520–1550 t/s，decode 约 56 t/s），换来的只是权重从全部压在一张卡上变成 24.2 + 26.2 GB 分放。启动时会打印实际使用的模式与每张 GPU 的层数 / 字节划分，TS_Q4E_LAYER_SPLIT=20,28 可覆盖自动均衡。其他所有架构在不加 --tp 时只用一张 GPU；两种模式都不支持的架构现在会在 stderr 上明说，而不是默默让其余 GPU 闲置（见TP 与按层切分）。→ 多 GPU 与多节点
• MoE CPU 卸载 —— --cpu-moe / --n-cpu-moe N 把前 N 层的路由专家留在系统内存里，直接从 GGUF 映射取用、不做私有拷贝，并且能与 --tp 组合。它是让装不下的权重能跑起来的手段，而不是提速开关：GLM 5.2 在 --n-cpu-moe 30 下实测 pp2048 94.7 / tg64 16.4，全部常驻时为 915.9 / 43.9，但腾出的显存把能定下的上下文从 342,272 抬到 646,400 token。→ 内存
• MTP / NextN 推测解码 —— 多 token 预测草稿头加速单序列解码；因请求自身的采样器同时驱动草稿与验证，故无损。→ 推测解码
• DSpark 块级投机解码 —— DeepSeek V4 的草稿器每步提议一整块 token（Markov 头让块内每个位置以前一个 token 为条件，置信度头决定起草多远），主干用一次批量前向验证整块。以独立 GGUF 通过 --draft-model 加载；4×A40 实测 decode 提速 1.3–1.4×，多轮对话最高 2.0×，贪心输出与基线逐字节一致。→ DSpark
• 整模型融合 decode 计算图 —— Gemma 4、Qwen 3.5/3.6 与 GPT OSS 把一个 decode token 作为一次 GGML 计算图提交，而不是每层一次，GPU 因此不会在层间空等主机。GPT OSS decode 在 A40 上从 24 → 154 tok/s，且随上下文长度基本持平。→ 性能优化
• 扩散模型快车道（视频与图像） —— MiniMax-H3 出厂即经 CFG 蒸馏，没有额外的"快权重"要找：--cfg 1.0 下的 4–8 步就是工作点（默认 20 步），在 M5 Pro（ggml_metal、22 帧、8 步、相同种子）上，它在 256×256 比 stable-diffusion.cpp 快 2.4×（49.3 s → 20.9 s），在 640×384 快 1.7×（108.5 s → 63.1 s）。Wan 这边，步数蒸馏的权重（文件名中带 Turbo、distill、Lightning、lightx2v、FastWan、-dmd，或显式的 …-4steps-…）会在加载时被自动识别，只跑 4 次无引导 DiT 前向，而不是基础配方的 100 次 —— 不需要任何参数，只是换一个 --model。实测（M5 Pro、ggml_metal、Wan2.2-TI2V-5B Q8_0、1088×832×121 帧图生视频）：基础权重约 3 小时 30 分，Turbo 权重 17 分 30 秒。此外，F16 注意力 K/V 在 27,404 token 的自注意力上快 2.02×，Metal MPSGraph VAE 卷积把 736×544×81 帧的解码从 159 秒降到 80 秒，--cfg-cache-stride 2 / 3 在基础权重上再带来 1.30× / 1.43×。图像侧，Qwen-Image-Edit 的 Lightning LoRA 把基础的 30 步 CFG 2.5 换成 4–8 步 CFG 1.0，CUDA 图捕获的整 DiT 前向把 8 步去噪从约 153 秒降到约 63 秒。→ 视频生成
• 原生量化计算 —— 量化权重直接用于 matmul，无需展开为 FP32，节省内存与带宽。在 --backend cpu 上，这现在也覆盖了此前会在加载时展开成 F32 的 Wan 与 MiniMax-H3 扩散线性层：一段小型 Wan 渲染实测 80.9 s 对 121.4 s，权重内存少 4×（TS_DIRECT_QUANT_WEIGHTS=0 可恢复旧行为）。i-quant 的覆盖面也更宽了：IQ2_XS 与 IQ4_XS 在加载时保持量化而不再展开，IQ2_XS / IQ3_XXS 对 Q8_K 也有了带 AVX2 路径的直接点积内核，不必再把每一行反量化到暂存区。
• 优化的纯 C# CPU 后端 —— 托管 GEMM 快路径，外加 RMSNorm、RoPE、softmax 与融合激活的融合 SIMD 内核；托管 matmul 现在不再走每次 matmul 一遍的 Parallel.For，而是分摊到常驻的多核工作线程池上（gemma-4-E4B-it-Q8_0、122 CPU 配额实测：prefill 约 +15%、decode 约 2.8×；线程池默认只占可用核心的一半，因为自旋的 worker 否则会饿死其余 CPU 路径）。每个模型家族都有纯 C# CPU 路径，包括最后补齐的 MiniMax-H3。量化权重现在在这里也是从 GGUF 映射零拷贝绑定的（GGML 后端一直如此），不再于加载时复制进新的匿名内存：GLM-5.3-Flash UD-Q2_K_XL 从一次永远无法完成的加载变成约 48 s。→ CPU 后端
• KV 缓存编解码器 —— 可插拔的 IKvBlockCodec，内置面向分页块的 TurboQuant（Q2 / Q4 / Q8）压缩编解码器。

接口与集成

• Ollama 与 OpenAI API 兼容 —— 面向现有工具的即插即用替代端点。→ HTTP API
• 浏览器聊天 UI —— 多轮对话、最大 500 MB 文件上传（图像、视频、音频、PDF、文本/代码）、思考开关、工具调用、消息编辑与实时流式。→ Web UI
• 交互式 REPL —— 逐轮控制台聊天，带斜杠命令、可热切换的模型 / 后端 / 投影器，以及实时采样调参。→ REPL
• 批处理 —— 控制台应用的 JSONL 输入，外加内置的 prefill/decode 基准测试。
• 源码项目嵌入 —— 只引用需要的层，将推理嵌入自己的 .NET 应用。已有 8 个包 ID 在 NuGet.org 发布到 3.1.2，但落后于当前源码 / Release；Runtime.Logging、AgentHost、Chat、Server.Host 与 Distributed 已可打包并通过校验但尚未发布，仍只能从源码引用。→ C# 库
• 逐轮可观测性 —— 结构化有界输入摘要、模型原始输出日志与 KV 缓存命中率，并通过每个 API 暴露（prompt_cache_hit_*、cached_tokens、kvReused*）。上传文档正文不会写入日志，但仍保留附件元数据与用户指令。