支持的模型
TensorSharp 加载 GGUF 格式的模型，并从文件的 general.architecture 元数据自动识别架构——MiniMax-H3 是例外，它公开的 GGUF 完全没有元数据，只能靠张量表来识别。选择适合你硬件的量化（低内存用 Q4_K_M，更高质量用 Q8_0）。
Gemma 4 E4B 是《From Tensors to Tokens》采用的示例模型。配套图书提供从张量基础到多模态推理的连贯构建过程；这组参考页面则提供最新下载与能力细节。了解本书 →
浏览模型参考
完整参考分为四个页面。如果你已经确定要用哪个模型，从"模型下载"开始；如果还在挑选，从对应的分类页面开始。
模型下载
所有 GGUF，以及各家族所需的投影器、VAE、编码器与草稿模型。
文本与 LLM 模型
十二种架构及其运行示例，加上多模态输入、思考模式与工具调用。
图像生成
Qwen-Image-Edit、Lightning LoRA，以及 DiT 步缓存。
视频生成
MiniMax-H3 带原生立体声音频，以及 Wan 2.1 / 2.2 与那个把数小时变成几分钟的蒸馏检查点。
支持的架构
| 架构 | GGUF 架构键 | 示例模型 | 多模态 | 思考 | 工具 | MTP 推测 |
|---|---|---|---|---|---|---|
| DeepSeek V4.1 Flash | deepseek41 | DeepSeek-V4.1-Flash（40 层，384 个路由专家 top-6 加一个共享专家，四条残差流与延迟 hyper-connection 混合，第 1 与第 14 层注入 Engram n-gram 特征，声明 1M 上下文）。服务后端为 ggml_cuda，cuda 与 ggml_cpu 作为可移植性与正确性通道，而 cpu 是 100% 纯 C# 执行器——不用 ggml、不用原生库、也不用 GPU，完整实现整张 V4.1 计算图，并以 atol=rtol=2e-5 加贪心 argmax 完全一致对齐一个独立的 PyTorch 参考实现（该把关是 fixture 规模的——五层、256 隐藏维的合成模型，因此确立的是与参考实现的架构级一致，而不是真实 246 GiB Q2_K 权重上的 CPU/CUDA 一致性），属于正确性与可移植性路径，而非服务路径；每一种量化（Q2_K 与 Q4_K_M 均已测试）都必须先准备 Engram sidecar 才能运行 | 配合单独准备的视觉伴随文件（--mmproj）支持图像与视频；音频会被拒绝，而不是被忽略。该伴随组件是原生 ggml 组件，因此在纯 C# 的 cpu 后端上无法使用，那条路径仅文本 | 支持 | 支持（带空格的 DSML，受语法约束） | —（V4 的草稿模型会被拒绝） |
| DeepSeek V4 Flash | deepseek4 | DeepSeek-V4-Flash（284B MoE，256 专家，压缩稀疏注意力，1M 上下文） | 仅文本 | 是 | 是（DSML） | 是（DSpark 块级草稿器，独立 GGUF） |
| GLM 5.x | glm-dsa、glm5next | GLM-5.2（744B-A40B MoE，256 专家，MLA + DeepSeek 稀疏注意力，1M 上下文）；GLM-5.3（与 5.2 完全相同的 79 个 block 的 glm-dsa 结构——78 层主干加 1 个 NextN，256 个路由专家 top-8 外加 1 个共享专家，带 lightning indexer 的 MLA，rope base 8e6，声明 1M 上下文，除非 MAX_CONTEXT 指定具体数字、否则会按设备容量截断——因此直接走 GLM-5.2 的路径，无需新代码也无需新开关；UD-Q2_K_XL 量化下为 7 个分片共 236.4 GiB，位于 unsloth/GLM-5.3-GGUF，--model 指向 -00001-of- 分片）；GLM-5.3-Flash（320B，288 个路由专家，45 个主干层里 34 层 KDA 线性注意力，另外 11 层是 NoPE MLA/DSA 配池化索引器） | 仅 5.3-Flash 支持图像；5.2 与 5.3 都仅文本——GLM-5.3 仓库在任何量化下都没有发布 mmproj，而 glm-dsa 碰到 --mmproj 只会告警并忽略、而不是报错，所以得到的是一次仅文本的运行，而不是一次失败 | 是 | 是（XML 工具调用） | glm-dsa 支持（GLM-5.2 与 GLM-5.3 都在 blk.78 内嵌了完整的 NextN 块，无需额外下载；--spec 必须在加载之前就写在命令行上，而且只在默认按层切分时生效——在 --tp N>1 下加载器会在 stderr 上打印一行并改跑标准解码，因为该块没有自己的 LM head，而它借用的主干 head 又是按列切分的）。glm5next（GLM-5.3-Flash）尚未实现 |
| Gemma 4 | gemma4 | gemma-4-E4B、12B、31B、26B-A4B (MoE) | 图像、视频、音频 | 是 | 是 | 是（独立草稿） |
| Qwen 3.5 / 3.6 | qwen35、qwen35moe、qwen3next | Qwen3.5-9B、Qwen3.5/3.6-35B-A3B (MoE) | 图像 | 是 | 是 | 3.6 支持（内嵌 NextN——仅限保留 NextN 块的 GGUF，例如 -MTP- 仓库） |
| Qwen 3.8 Flash Next | qwen4exp | Qwen3.8-Flash-Next（混合 MoE：GatedDeltaNet 递归层与全注意力层交错，其中一部分挂在 Qwen 稀疏注意力的索引器之后；PLE n-gram 嵌入块；×4 超连接流；512 专家、每 token 用 10 个） | 图像 | 是 | 否——暂没有结构化输出解析器 | — |
| GPT OSS | gptoss、gpt-oss | gpt-oss-20b (MoE) | 仅文本 | 是（始终） | 是 | — |
| Nemotron-H | nemotron_h、nemotron_h_moe | Nemotron-H-8B、47B、Nemotron 3 Nano Omni | 图像（Omni） | 是 | 是 | — |
| Hunyuan Dense | hunyuan-dense | 腾讯稠密 Hunyuan 解码器，例如 Hy-MT2 系列——GQA，其 per-head QK-norm 在 NeoX RoPE 之后，随后是 SwiGLU。单设备 | 仅文本 | 不支持 | 不支持 | — |
| Mistral 3 | mistral3 | Mistral-Small-3.1-24B-Instruct | 图像 | 否 | 否 | — |
| Muse-Glimmer | muse-glimmer、muse_glimmer | Muse-Glimmer-30B（交错滑动窗口 + NoPE 全注意力层，注意力输出门控） | 图像 | 是 | 是（ATEM） | 是（DFlash 块草稿模型，独立 GGUF） |
| Bonsai Q1_0 | qwen3（8B）、qwen35（27B） | Bonsai-8B（36 层稠密 GQA）与 Bonsai-27B（48 层 GatedDeltaNet + 16 层全注意力），均为每权重 1.125 比特。仅本地导入——这两个 GGUF 既未声明发布仓库 URL，也未声明许可证 | 仅文本 | 27B 支持；8B 模板固定输出一个空的 think 块 | 支持 | — |
| DiffusionGemma | diffusion-gemma、diffusion_gemma | diffusion-gemma 文本扩散 GGUF | 仅文本 | 否 | 否 | — |
| Qwen-Image-Edit | qwen_image、qwen-image | qwen-image-edit MMDiT（+ VAE 与 Qwen2.5-VL 伴随文件） | 图像编辑（图像+文本 → 图像） | 否 | 否 | — |
| MiniMax-H3 | minimax-h3、minimax_h3 | MiniMax-H3 FL2VA / Ref2VA 去噪器（+ Qwen3-VL-32B 文本编码器、视频 VAE 与音频 VAE 伴随文件）。公开的 GGUF 没有任何元数据，靠张量表识别 | 视频输出 + 32 kHz 立体声音频（文本 → 视频、图像 → 视频、首尾帧、参考 → 视频） | 否 | 否 | — |
| Wan 视频 | wan、wan2.1、wan2.2 | Wan 2.1 T2V 1.3B/14B、Wan 2.2 TI2V-5B、Wan 2.2 A14B T2V/I2V（两个 14B 专家）（+ UMT5-XXL 与视频 VAE 伴随文件） | 视频输出（文本 → 视频、图像 → 视频） | 否 | 否 | — |
各模型的详细架构卡（前向图、组件、参数，以及 TensorSharp 如何优化 prefill/decode）位于仓库的 docs/models/ 下。
哪个更快——每个家族最关键的那一项设置
每个模型家族都有一项主导端到端耗时的设置。两个视频家族最容易被忽略，而且被忽略的点还不一样：MiniMax-H3 出厂即经 CFG 蒸馏，杠杆是你要多少步、多少像素，而不是去换哪个文件；而在 Wan 上，你下载的是哪个检查点，直接决定一段 5 秒 720p 视频是跑三个半小时还是十七分钟——而且不需要加任何参数。
| 家族 | 快车道 | 实测效果 |
|---|---|---|
| MiniMax-H3 | 它本身就经过 CFG 蒸馏——没有更快的文件可换。用 --cfg 1.0 跑 4–8 步（默认 20 步），把省下的时间花在 --width / --height 上 | M5 Pro / ggml_metal、22 帧、8 步、相同种子，对比 stable-diffusion.cpp：256×256 49.3 s → 20.9 s（快 2.4×），640×384 108.5 s → 63.1 s（快 1.7×）。步数买到的是质量而不只是时间——同一条 640×384 图生视频请求，8 步 79 s、运动的手周围有彩色边缘，24 步 212 s、干净 |
| Wan 视频 | 加载步数蒸馏检查点——DiT 文件名中含 Turbo、distill、Lightning、lightx2v、FastWan、-dmd 或 …-4steps-… 即被自动识别，无需任何参数 | 100 次 DiT 前向 → 4 次，关闭引导。同一条 1088×832×121 帧图生视频请求，M5 Pro / ggml_metal：约 3 小时 30 分 → 17 分 30 秒 |
| Wan 视频 | --cfg-cache-stride 2 / 3——仅适用于未蒸馏的基础检查点 | 50 步下 1.30× / 1.43×（100 次前向只跑 77 / 70 次）。属于近似方法；在本就无引导的蒸馏检查点上没有意义 |
| Qwen-Image-Edit | 用 --qwen-image-lora 加载 Lightning 蒸馏 LoRA | 基础配方 30 步、cfg 2.5，即 60 次 DiT 前向 → 4–8 次、cfg 1.0。544×1184、4 步的热态编辑：40.44 s，对比 stable-diffusion.cpp 的 48.16 s |
| DeepSeek V4 | 用 --draft-model 加载 DSpark 块级草稿器（仅 cuda / ggml_cuda） | 4×A40、200 个贪心 token：decode 26.0 → 34.0 tok/s（cuda）、26.4 → 37.1 tok/s（ggml_cuda），接受率 69%；5 轮对话中可达 1.5–2.0×。输出保持不变 |
| Muse-Glimmer | 用 --draft-model 加载 DFlash 块级草稿器（不要传任何采样参数，它需要纯贪心） | RTX PRO 6000、128 个贪心 token：60 token 提示下 35.0 → 50.9 tok/s，2 050 token 下 33.5 → 43.5。在 Apple Silicon 上目前并不划算（20.7 → 13.9 tok/s），那里请用普通 decode |
| Qwen 3.6 / Gemma 4 | 在 TensorSharp.Server 上加 --spec——Qwen 3.6 用 -MTP- GGUF 内嵌的 NextN 块，Gemma 4 用独立的 --draft-model 草稿 | 仅在单独（无并发）序列上启用，并且只在有收益处启用：Qwen 3.6 的内嵌 NextN 块在所有后端上都被认为有收益，而 Gemma 4 的独立草稿头只在各 ggml 后端与直连 cuda 后端上启用；CPU / GGML CPU / MLX 走标准 decode。可用 --spec-draft（默认 8）与 --spec-pmin（默认 0.15）调节 |
| 所有文本家族 | 选对 --backend：NVIDIA 用 ggml_cuda，Apple Silicon 用 ggml_metal，CPU 用 ggml_cpu（而非 cpu） | RTX 3080 Laptop、gemma-4-26B-A4B QAT：ggml_cuda decode 78.7 tok/s，直连 cuda 后端 35.3；prefill 1832 对 128。Apple Silicon、Muse-Glimmer-30B：ggml_metal prefill 413.6，mlx 仅 29.0 |
| 装不下的 MoE | --n-cpu-moe N / --cpu-moe——把前 N 层的路由专家权重留在系统内存 | 以 decode 换显存；但只要能避免显存溢出就是净赚：gpt-oss-20b 在 16 GB 卡上 16.2 → 2.9 GB，--n-cpu-moe 12 把 WDDM 换页导致的 0.3 tok/s 变成 25.4 |
| GLM 5.x | TS_GLM_UBATCH=2048 —— 显存允许时把 prefill 微批调大 | 3× RTX PRO 6000、GLM-5.2 UD-IQ2_XXS：pp2048 从 918.9 到 1145.8 t/s，pp4096 从 864.7 到 1048.7 t/s；decode 受访存约束，仍是约 43.9 tok/s。256 个专家 top-8 的情况下，分块太小会让每个专家 GEMM 的 tile 大半是填充 |
| 多 GPU | 在直连 cuda 与 GGML CUDA / Vulkan 上使用 --tp N（环境变量 TENSORSHARP_TP_DEGREE） | Muse-Glimmer-30B UD-IQ2_XXS、2× RTX PRO 4000：prefill 1171 → 1569（1.34×），decode 40.2 → 63.2 tok/s（1.57×）。它还能跑单卡完全装不下的模型——但前提是互连付得起这笔账：在没有 NVLink 的 PCIe 主机上，逐层的 all-reduce 可能比拆分省下的还贵，GLM-5.2 在 3× RTX PRO 6000 上就从 pp2048 915.9 / tg64 43.9 掉到 --tp 3 的 505.6 / 17.6。GLM-5.2、GLM-5.3 与 GLM-5.3-Flash 的原生 TP 都只支持本地单进程——--tp-node-id / --tp-peers 对整个家族都会在模型构造之前被拒绝。GLM-5.3 上从来没有跑过 --tp 1 以上的配置：这个模式是接受的，但 MLA 与索引器缓存会按 rank 复制，缓存占用随 N 成倍增长、能装下的上下文也更短；唯一有记录的算术是一次装不下——--tp 8 每个 rank 需要 41.7 GiB，而 A40 只有 46 GB |
工具支持同时要求提示词渲染器与匹配的结构化输出解析器。TensorSharp 目前对 qwen4exp 使用透传解析器，因此不会向 Qwen 3.8 Flash Next 提供调用者定义的工具、Agent Skills 渐进披露工具或代码执行工具；被选中技能的说明会以内联方式回退。
MiniMax-H3、Wan、Qwen-Image-Edit 与 DiffusionGemma 构造时不接受张量并行度，因此 --tp 对它们无效。在视频家族里，Wan 还是唯一会直接拒绝某个后端的：不支持 mlx。MiniMax-H3 —— 生成类家族里最后一个还没有纯托管 CPU 路径的 —— 现在也能完整跑在 --backend cpu 上，即 100% 纯 C#、零原生依赖的那条路径：文生视频、图生视频、首尾帧，以及参考图像、参考片段与参考音轨。它与原生 ggml_cpu 路径的速度是互有快慢，而不是一律更慢。在 Qwen 3.8 Flash Next 上，--tp N 的含义又不一样——它跑的是按层切分，每张 GPU 持有一段连续的完整层、不切分任何权重，因此是容量特性而非速度特性：2× A100-80GB、UD-Q2_K_XL（73.4 GiB）下，贪心输出与单卡逐字节相同，显存变成 24.2 + 26.2 GB，prefill（约 1520–1550 t/s）与 decode（约 56 t/s）都没有变化。GLM-5.3 与 GLM-5.3-Flash 不传 --tp 时都使用按层切分——原生执行器会用上每一张可见 GPU 并按整层放置，TS_GLM_NGPU 可以限制它最多用几张；在 GGML GPU 后端上，--tp N 则会选择仅支持本地单进程的原生张量并行。在 GLM-5.3 上，按层切分也是它的 NextN 块唯一能为 --spec 加载的放置方式。既不支持张量并行、也不支持按层切分的架构，现在会在 stderr 上直说，并只用一张 GPU 运行，而不是让其余的卡白白闲着。