功能特性

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

嵌入模型： Snowflake Arctic Embed L v2.0、MiniLM，以及支持文本与可选图像/音频/视频输入的 EmbeddingGemma 2。通过 --embeddings 提供兼容 OpenAI/Ollama 的向量 API；后端支持依模型而定。模型、API 与验证范围 →

亮点

TensorAgent：在一个面向 iPhone、iPad、macOS 与 Windows 的应用中运行本地文本、图像、视频、文件、代码、技能与桌面浏览器工作流。界面支持八种语言；具体工作流取决于设备内存与平台策略。桌面下载与使用指南 → · 能力与验证边界 →

模型与模态

• 多架构支持 —— 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（含 Bonsai2）、Qwen 3.8 Flash Next、GPT OSS、Nemotron-H、Mistral 3、Hunyuan Dense、Muse-Glimmer、Muse Spark、MiniMax-M3.1-Flash、Qwen-Image-2.1、LTX 2.5 音视频、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，零原生依赖）。权重通过 --layer-split N 按整层放置，服务端以原生 per-sequence slot 与连续批处理托管它。→ DeepSeek V4
• DeepSeek V4.1 Flash 1017 —— 独立的 V4.1 计算图，包含压缩注意力、索引器、超连接与内嵌 Engram。最新选取的转换是六分片 UD-IQ2_XXS（60ad3651）；ggml_cuda 是服务后端。其他后端、视觉伴随模型与数值资格各有局限；默认近似 YOCO 与精确 prefill 的取舍见模型卡与基准。→ 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，在 CUDA 或 Vulkan 上通过 --layer-split N 将 226 GiB 按层放到 N 张本地 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 家族都会在模型构建之前就被拒绝。→ 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。用 --layer-split N 将整层放到 N 张本地 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 运行一次。NextN/MTP 推测解码仍未支持。视觉能力来自 mmproj-BF16.gguf（GLM-OCR ViT）：支持 --image、多图与多轮图像会话。→ 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 的循环状态无法回退）；video_url 片段会按时间采样成帧。可开关的思考、服务端，以及基于 per-sequence 状态持有器的连续批处理均已支持，--layer-split N 则运行多 GPU 分层切分。工具调用经由 Qwen 3.5 的 <tool_call> 解析器（XML 或 JSON 正文）解析，因此它也能获得技能、代码工具与子智能体；另有一个独立的共享 MTP 头，可在 GGML 后端上通过 --draft-model 挂载。→ Qwen 3.8 Flash Next
• Muse Spark（816B 稀疏 MoE，文本 + 图像） —— 原生整模型执行器支持按层切分与本地 GGML CUDA 张量并行；支持范围见模型卡。十张 A40、UD-IQ3_XXS 的报告更新于 2026-10-22（未记录测量日期）：按层切分 4,075 token 提示的 prefill 为 999.7 对 483.2 tok/s（2.07×，输出上限 32）；TP 单请求 decode 为 22.63 对 16.19（1.40×，167 token 提示，输出上限 256）。参照为对应 llama.cpp 模式，传输条件不同。→ 测量范围 · 模型支持
• MiniMax-M3.1-Flash（428B 稀疏 MoE，文本 + 图像、DSpark） —— ggml_cuda 上的原生整模型执行器，每层都是 MiniMax 稀疏注意力（位置 2048 之后用 TensorSharp CUDA 内核），按层切分带流水线 prefill 与主机专家，基于 ggml meta 后端的本地张量并行，以及 DSpark 块级投机解码。2026-10-24 在八张 A40 上对照 llama.cpp 测量：32K token 服务器 prefill 为 1,544 对 240 tok/s（6.43×），4K 深度 decode 为 23.9 对 19.2（1.24×），DSpark 为 32.3 对 25.8 tok/s；短对话首 token 时间略慢（0.41 对 0.39 s）。→ 测量范围 · 模型支持
• 多模态推理 —— Gemma 4 支持图像、视频与音频输入；Qwen 3.5-family、Qwen 3.8 Flash Next、GLM-5.3-Flash、Mistral 3、Nemotron-H Omni、Muse-Glimmer、Muse Spark、MiniMax-M3.1（转换得到的投影器）与 DiffusionGemma 支持图像；Qwen 3.8 Flash Next 还支持视频，MiniMax-M3.1 以抽样帧接收视频；DeepSeek V4.1 挂上单独准备的视觉伴随文件后支持图像与视频。→ 多模态
• 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。
• LTX 2.5 Distilled —— 完整 8+3 两阶段视频/48 kHz 立体声，首尾/定时图像、可选 Ingredients 参考；五文件校验预设与 TensorAgent 48 GB 实验条目。 模型与限制 →
• 音视频联合生成（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 步；两个可选的 LightX2V Turbo LoRA 插件（config/lora/minimax-h3-fl2v-turbo-8step.json 与 -4step.json）让 FL2VA 按锁定的配方只跑 8 或 4 步（4 步配方为推断所得），Ref2VA 不接受插件。可从 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 去噪采样器，而非自回归解码。它通过 Gemma 4 视觉塔读取图像，视觉塔可从 mmproj GGUF 或上游 model-00011-of-00011.safetensors 分片加载（音频、视频与工具都会被拒绝）。同一模型还提供 Jev 兼容的 POST /v1/systemone 端点，针对文本或最多 8 张图像回答类型化问题——是 / 否概率、选项与期望分数（Jev 卡片）。→ DiffusionGemma
• 图像生成与编辑（Qwen-Image-2.1） —— 提示词生成图像，提示词加一张或多张参考图生成编辑后的图像；由 Qwen-Image-2.1 扩散 Transformer、专用 2.1 VAE 与 Qwen3-VL-8B 文本编码器完成（FlowMatch-Euler，采用官方指数动态偏移调度；在 GGML 后端上以常驻量化权重运行一张完整的 GGML 图，在纯 C# 的 cpu 后端上则以托管代码运行）。默认 2048×2048、40 步、CFG 1.0，RGBA 输入与 PNG 输出保留透明度。--lora / --lora-scale / --lora-config 以不合并的方式在量化权重上应用 LoRA 插件；config/lora/ 提供十四个 Qwen-Image-2.1 预设，其中四个是只需 4–8 步的步数蒸馏配方，另有两个 MiniMax-H3 Turbo 插件。文本与参考 token 的前缀 K/V 缓存默认开启（TS_QWEN21_PREFIX_CACHE=0 关闭），可避免在每个去噪步骤中重复计算不变的前缀 token。--tp N 可在 ggml_cuda / ggml_vulkan 上切分扩散 Transformer。→ 图像生成

生成与控制

• 思考 / 推理模式 —— 带 <think> / <|channel> 标签的结构化思维链（Qwen 3.5/3.6、Qwen 3.8 Flash Next、Gemma 4、GPT OSS、Nemotron-H、DeepSeek V4、DeepSeek V4.1、GLM 5.x），MiniMax-M3.1 使用自适应的 <mm:think> 块，Muse-Glimmer 与 Muse Spark 则用 to=self 通道。→ 思考模式
• 工具调用 / 函数调用 —— 与架构无关的输出解析，无论模型输出的是 <tool_call> 块内的 JSON（Nemotron-H）、同一种块内的 XML（Qwen 3.5/3.6、Qwen 3.8 Flash Next）、Gemma 4 的 <|tool_call> 标记、GLM 5.x 的 <arg_key> / <arg_value> 成对标签、Harmony commentary（GPT OSS）、ATEM 标记（Muse-Glimmer、Muse Spark）、MiniMax-M3.1 带语法约束 tool_choice 的命名空间 XML，还是 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；未指定时，依次是从当前工作目录向上直到 Git 根目录的每个已存在的 .agents/skills，再加上二进制文件旁边的 skills 目录——服务端把它用作上传目录，总是最先扫描它），把每个技能的一行描述展示给模型，其余内容只在模型主动索取时才加载。→ CLI 参数 · HTTP 字段与端点 · C# API
• 基础技能工具与可选执行 —— 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、Hunyuan Dense 与 DiffusionGemma 不承载工具声明，因此会内联选中技能正文，并隐藏技能 / 代码工具，而不是发出无人能处理的调用。qwen4exp（Qwen 3.8 Flash Next）已能完成工具往返。
• 智能体代码执行 —— --code-exec 增加 read_file、write_file（仅新建文件）、shell 与 apply_patch。TensorSharp 在同一个有界循环中执行这些内置工具；调用方自己的工具从不代跑，仍回传调用方。普通技能循环默认 8 轮；提供代码执行时自动提高到 24 轮，除非运维显式设过上限。→ 架构、权限与平台限制
• 子智能体 —— 在服务端聊天路径上（OpenAI Chat 与 Responses、Ollama chat、Web UI），支持工具的模型可以用 spawn_agent、wait_agent、send_input、close_agent 与 list_agents 委派相互独立的工作。它默认开启，既不依赖技能也不依赖 --code-exec；子智能体运行在同一个已加载模型上，默认只读（只有 worker 子智能体能使用父智能体的可写工具，且仅在设置了 --agents-allow-worker-tools 时），并受 --agents-* 各项上限约束。--no-multi-agent 或请求中的 "multi_agent": false 可关闭它；TensorAgent 默认委派，可在设置 → 沙盒 → 子代理中关闭，CLI 不做委派。项目没有发布延迟或质量数据。→ 子智能体
• 浏览器自动化 —— TensorAgent/skills 中的 playwright 技能通过 skills_run 与固定版本的 @playwright/cli 驱动真实浏览器；没有屏幕或鼠标工具。它需要脚本执行权限、网络与宿主上的 Node.js，已记录 macOS arm64 模型工作流，另有 Windows 的有界合成技能运行器/会话探针。→ Playwright 技能
• 工作区与结果 —— 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。

共享技能包现为 17 个；原生 find-skills 提供 skills_search、skills_inspect 与同请求固定提交安装。网络、可达技能与可写注册表是独立条件；默认 CLI 仅搜索/检查。 技能包与验证范围 →

性能与扩展

• 近期的限定范围对比 —— DeepSeek V4.1 Flash 1017 在五张 A40、约 1.8K token 提示下，精确 TP5 prefill 为参照的 3.23×；默认近似 YOCO 为 5.50×，并记录了困惑度代价。Muse Spark 在十张 A40 上，单请求 TP decode 为 llama.cpp 对应模式的 1.40×。模型与计时方法不同，不能称为通用加速比。→ 条件、日期与质量局限
• GPU 后端 —— 在支持的平台上使用 GGML Metal、GGML CUDA、GGML Vulkan、直接 CUDA/cuBLAS 与 MLX。后端与模型覆盖范围不同。→ 后端
• 连续批处理与分页 KV 缓存 —— 块分页 KV 存储、默认开启的 Radix 前缀共享，以及可接纳和抢占序列的迭代级调度器。容量、公平性与总吞吐取决于模型执行器和工作负载。→ 深入了解
• 批量推理 —— 支持的模型执行器将序列工作打包进前向计算，请求数量本身不能预测吞吐。
• 多 GPU 模式 —— --tp N 选择张量并行，--layer-split N 选择整层放置。两种模式互斥，支持范围取决于模型与后端。按层切分仅限本地节点，部分 TP 实现支持跨节点。→ 多 GPU 与多节点
• MoE CPU 卸载 —— --cpu-moe / --n-cpu-moe N 可把路由专家留在系统内存中，以 CPU 工作与传输成本换取 GPU 容量，不是通用提速开关。→ 内存
• 投机解码 —— 模型专属的 MTP、NextN、n-gram 与块级草稿器提出 token，再由主干验证。收益、支持的放置方式与数值范围取决于模型和提示。→ 投机解码 · DeepSeek V4.1 资格范围
• 整模型计算图 —— 支持的原生执行器提交融合 prefill 或 decode 图，降低主机调度开销。选取的对比行测量完整的受支持路径，并非隔离某一项优化。→ 实现说明
• 媒体配方 —— LTX 2.5 使用两阶段蒸馏配方；MiniMax-H3 与 Qwen-Image-2.1 提供模型专属 LoRA 配方，Wan 识别支持的步数蒸馏检查点。步数与组件耗时不等于完整生成基准。→ 图像模型 · 视频模型
• 原生量化计算 —— 支持的量化权重在矩阵乘法中保持紧凑表示，而非把所有权重展开为 F32，覆盖范围取决于量化与后端。
• 托管 CPU 内核 —— C# GEMM 与归一化、位置编码、softmax、激活函数的 SIMD 内核，配合模型专属执行路径与线程池。功能和数值验证局限见各模型卡。→ CPU 后端

接口与集成

• Ollama 与 OpenAI API 兼容 —— 面向现有工具的即插即用替代端点。→ HTTP API
• 浏览器聊天 UI —— 多轮对话、最大 500 MB 文件上传（图像、视频、音频、PDF、文本/代码）、思考开关、工具调用、实时子智能体卡片、消息编辑与实时流式。→ Web UI
• 交互式 REPL —— 逐轮控制台聊天，带斜杠命令、可热切换的模型 / 后端 / 投影器，以及实时采样调参。→ REPL
• 批处理 —— 控制台应用的 JSONL 输入，外加内置的 prefill/decode 基准测试。
• 源码项目嵌入 —— 在 .NET 应用中只引用需要的层。当前源码发布流程打包十四个项目；使用比发布标签更新的功能时请引用当前源码。→ 包边界
• 逐轮可观测性 —— 结构化有界输入摘要、模型原始输出日志与 KV 缓存命中率，并通过每个 API 暴露（prompt_cache_hit_*、cached_tokens、kvReused*）。上传文档正文不会写入日志，但仍保留附件元数据与用户指令。