Ling-3.2-flash

架构（非标准 GQA 常数）

此模型是 MLA 多潜注意力 / 压缩稀疏注意力 / 哈希记忆一类架构，套不进本站「层数 × KV头 × 头维」的六字段常数—— 硬填就是编数字，所以这里不假装精确：KV 按官方口径（该模型自己公布的每 token 字节数，含它自己的 KV 精度）的保守近似线性估，容量表标注「近似」。 来源：未找到可核的 config.json —— 核查记录（核查于 2026-11-13）。ling-3-2-flash 在 2026-11-13 的全站一手来源巡检里判定为「官方仓不存在 / 没有 config.json」：HF 镜像 API 返回 404、owner 全量仓列表 200且列表里也没有这个仓。所以本页的架构常数（层数 / KV 头数 / 头维 / 原生上下文）没有一手来源，KV 是保守兜底值；下方「来源」链接是这次查证的记录地址，不是 config.json。

上下文档位（按 Q4_K_M）

* 含 1G 框架开销；可用水位按 Windows 口径 88% = 14.1G。

各显存档位能开多大

「最多可开」已扣掉权重与 1G 开销；标注为「模型原生上限」时表示显存还有余但模型只支持这么长。净可用还要再减聊天模板与系统提示词的 250 token（估算值，未逐项核实）。量化档后带「（估算）」= 官方仓库没核到这档、按公式算的权重体积（方向保守偏高）；不带 = 核过官方仓库真实文件体积。

估算速度（Q4_K_M · 8K）

推算 本站暂无这一模型的实测记录。

同一套公式也用于显卡页，两页数字必然一致。带宽按 60–85% 效率折算（offload 场景更低），并对单流解码设经验上限，因此这里的数字比纯带宽公式保守。 总需显存 = 337.6G，对比各卡可用水位。

实测数据区

llama.cpp

# 1) 取 GGUF 权重（本站核实过的仓库名）
huggingface-cli download inclusionAI/Ling-3.2-flash config.json
#   GGUF 量化版通常在第三方转换仓库，搜「inclusionAI/Ling-3.2-flash GGUF」
# 2) 起服务（Linux/macOS 用 ./llama-server，Windows 用 llama-server.exe）
llama-server -m LING-3-2-FLASH-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# MoE：想让专家留在内存以塞更大模型，加 --n-cpu-moe（参数名随版本变，用 --help 确认）

Ollama

# 本站没核实到 Ollama 仓库里有 Ling-3.2-flash 的可用标签，所以不给命令
# 自己去查一眼：https://ollama.com/search?q=Ling-3.2-flash

宁可不给命令，也不给一条跑不通的命令——照抄未核实的标签是新手最常见的卡死原因。

vLLM

vLLM 直接吃 Hugging Face 仓库名，这条最可靠：
vllm serve inclusionAI/Ling-3.2-flash --max-model-len 8192 --gpu-memory-utilization 0.90

LM Studio

模型页搜「inclusionAI/Ling-3.2-flash」→ 选 Q4_K_M 或 Q4_K_M → Load →
Chat Context Length 设 8192 → GPU Offload 拉到最大