EschaLabs/Qwen3.8-27B-Escha-W2 · Hugging Face

来源：https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#qwen38-27b-escha-w2–2-bit-quantized-eschaQwen3.8-27B-Escha-W2 — 2‑bit 量化版 (escha)

由 Escha Labs Inc. (https://eschalabs.com/) 提供

Escha‑W2 是 Qwen3.8-27B 的 2‑bit 量化版本。它在 10.15 GB 的权重中保留了完整的 27B 参数量——模型、其 KV 缓存和 64k 上下文可以完整放入单个 24 GB 消费级显卡，且仍有剩余空间（或在优化配置下支持 128k 上下文，参见 长上下文 (https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#long-context)）。

我们在三个维度上将其与同后端的 FP8 参考版本进行了对比，该版本的性能未可测量地变差：在常识推理上领先，在 GPQA‑Diamond 上恰好落后一道题，在 LiveCodeBench 上则在其基准本身的噪声范围内领先。

基础模型Qwen/Qwen3.8-27B (https://huggingface.co/Qwen/Qwen3.8-27B)量化方式2‑bit (escha；每个投影混合 2/3‑bit，2.469 bits/weight)，int8 嵌入层 + 输出头下载大小****10.18 GB 总计 ——10.15 GB 权重（10,153,088,224 字节）加上分词器和配置文件已验证显卡RTX 5090 (32 GB, sm_120), RTX 4090 (24 GB, sm_89), RTX 3090 (24 GB, sm_86)。16 GB 显存在降低上下文长度时可能适用；未经测试。平台Linux x86-64, NVIDIA sm_80+CUDA / Python12.8 运行时 / 3.12接口OpenAI 兼容的 HTTP 服务器

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#contents内容

路径说明model\-\*\.safetensors,\*\.json,tokenizer\.json量化权重、分词器和配置文件opencode\.json现成的opencode (https://opencode.ai/) 提供商配置块，指向本地服务器LICENSE,THIRD\_PARTY\_LICENSES/许可与归属信息 此仓库仅包含模型。运行时环境位于EschaLabs/escha-runtime-qwen3dense (https://huggingface.co/EschaLabs/escha-runtime-qwen3dense)—— 一个 SGLang 构建版本，包含此格式所需的解码内核。这是本模型卡中所有服务和测量所用的引擎。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#quickstart快速入门

`` python3.12 -m venv .venv && source .venv/bin/activate pip install -U pip wheel

先安装 PyTorch，并指定版本。内核与其 ABI 链接，

裸安装 “torch>=2.9” 会解析为 2.11 且无法修正——

你只能稍后通过 undefined symbol: _ZN3c10... 发现问题。

pip install “torch==2.9.*” –index-url https://download.pytorch.org/whl/cu128

运行时 wheel 包。它包含 SGLang 构建和完整的依赖闭包——

不要从 PyPI 额外安装 sglang，那会与此冲突。

pip install -U “huggingface_hub[cli]” hf download EschaLabs/escha-runtime-qwen3dense –include “sglang/” –local-dir runtime pip install ./runtime/sglang/escha-.whl

权重（独立仓库；扁平文件夹，无嵌套子目录）

hf download EschaLabs/Qwen3.8-27B-Escha-W2 –local-dir Qwen3.8-27B-Escha-W2

MODEL=./Qwen3.8-27B-Escha-W2 bash runtime/sglang/serve.sh ``

启动前进行完整性检查——以下三项必须全部打印 True：

python -c "import torch, escha, sglang; print(torch.cuda.is_available(), \ hasattr(torch.ops.escha, 'escham_decode_gemv'), bool(sglang.__version__))"

（import sglang 有目的地作为检查项——一个仅检查 torch, escha 的早期版本在无法实际服务的机器上也能通过。）

然后，从另一个终端：

curl http://127.0.0.1:30000/v1/models

如果生成流畅但不正确——自信、结构良好的废话——你几乎可以肯定使用的是 transformers < 5\.8，它以静默的不同注意力路径加载了此架构。在报告质量问题前请升级。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#connecting-a-client连接客户端

基础 URLhttp://127\.0\.0\.1:30000/v1模型 IDescha\-qwen38\-27b\-w2API 密钥任意非空字符串 此仓库中的 opencode\.json 是一个可用的提供商配置块——将其放入即可指向本地服务器。

启动脚本绑定到 localhost。如果你设置 HOST=0\.0\.0\.0 以便从其他机器访问，请同时设置 API\_KEY；服务器本身没有认证机制。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#thinking-mode思考模式

这是一个思考模型。通过 chat\_template\_kwargs 切换——顶级的 enable\_thinking 会被忽略：

{ "model": "escha-qwen38-27b-w2", "messages": [{"role": "user", "content": "..."}], "chat_template_kwargs": {"enable_thinking": true, "reasoning_effort": "xhigh"} }

当思考开启时，答案可能同时出现在 reasoning\_content 和 content 中——需要读取两者，否则会得到空字符串。启动脚本上的 THINK=0 默认将其关闭。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#reasoning_effort–the-knob-most-people-should-touch-firstreasoning\_effort —— 大多数人应首先调整的参数

默认值为 xhigh，它是控制答案生成时长的最关键杠杆。它与 enable\_thinking 一起放在 chat\_template\_kwargs 中，仅在思考开启时生效。

值模板行为适用场景xhigh默认。 前置提示：“仔细思考任务，验证关键假设，考虑合理的替代方案，并优先考虑正确性、一致性和清晰度。” 难推理、数学、代码。本卡所有基准均在此设置下运行。medium不前置任何内容 —— 中立、无引导的模型通用对话、智能体交互，任何 xhigh 对简单请求过度思考的情况low前置提示：“保持你的思考简短且聚焦，直接得出结论，无需不必要的阐述。” 对延迟敏感或高流量的场景 在依赖它之前需要了解两点：

• 这是提示，而非限制。 每个级别注入（或省略）一句系统指令。它要求更短的推理；没有任何强制执行机制，一个难题在 low 设置下仍可能产生长链条。当你需要保证时——基准测试、智能体循环、任何有超时要求的场景——请使用思考预算，它在 N 个 token 后强制 </think\> 以确保始终产生答案：运行时手册 → 有限思考 (https://huggingface.co/EschaLabs/escha-runtime-qwen3dense/blob/main/sglang/INSTALL.md#bounded-thinking-thinking_budget)。
• 任何其他值都会导致硬性错误。 模板对这三个值以外的任何输入都会抛出异常，表现为 HTTP 400 错误——而非静默回退到默认值。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#tuning调优

serve\.sh 在文件顶部文档化了所有参数。在 24 GB 显卡上重要的参数有：

变量默认值说明MEM``0\.72权重 + KV 池占用的显存比例。设置过低也会失败，提示 “Not enough memory … increase --mem-fraction-static”。如果 CUDA‑graph 捕获出现内存不足，请降低（0.70, 0.68），而非提高。在大于 24 GB 的显卡上可提高此值。CTXLEN``65536每请求的上下文上限——这是一个默认值，而非硬性上限，其本身不分配任何资源。实际限制的是服务器启动时打印的共享池 max\_total\_num\_tokens，该值必须 ≥ 并发流数 × 上下文长度。仅提高 CTXLEN 而不提高 MEM 会导致池太小，且在 TRUNCATE=1 时会进行静默截断。参见长上下文 (https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#long-context)。MAMBA\_RATIO``0\.3``\-\-mamba\-full\-memory\-ratio。非 sglang 的 0\.9——这是一个混合‑SSM 模型，每个并发流都持有循环状态，其大小不随上下文增长。0\.3 是在 CTXLEN=65536 下为 KV 和 图捕获留出空间的值。GRAPHS``1CUDA 图。性能所必需——该架构每个 token 运行许多小内核，因此 eager 解码受启动限制。仅在调试捕获故障时设置为 0。CUDA\_GRAPH\_BS``1 2 4 8 12 16要捕获的批处理大小。必须包含你的最大批处理大小，否则该批处理会静默运行 eager 模式（约低 15%）。注意 12/16 条目在发布时的 MEM/MAMBA\_RATIO 下不会生效——循环池将 24 GB 显卡限制为 8‑9 个流，这些条目会被丢弃。首先提高 MAXREQ/MAXMAMBA/MEM，然后扩展到 "1 2 4 8 12 16 24 32"。RADIX``0前缀缓存，此处默认关闭——没有投机解码的基数缓存会禁用重叠调度器，在此混合模型上它仅服务于精确、完整的重复（测量：长上下文 (https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#long-context)）。它不会加速不断增长的对话，因此不是智能体延迟的杠杆。如果你确实设置为 1，同时将 MAXREQ≥ 2——前缀缓存占用一个请求槽，RADIX=1 配合 MAXREQ=1 会清空捕获列表并导致启动时失败，错误为 AssertionError: capture\_bs=\[0\]。THINK``1``0 默认提供关闭思考模式。无论哪种设置，客户端都可以通过 chat\_template\_kwargs 按请求切换。ATTN\_BACKEND*（未设置）在消费级 Blackwell（RTX 50 系列，sm_120）上设置 triton——默认解析为 flashinfer，该分支拒绝为该系列上的混合模型使用。在 Ampere/Ada/Hopper 上保持未设置。ESCHA\_ROUTE（自动）*内核启动几何形状，按 GPU 自动选择。在 Ampere (sm_80/86) 上，单用户工作设置为 blackwell——在 RTX 3090 上批处理大小为 1 时快 1.72 倍，输出相同。批处理大小 2‑16 时性能相当，因此在批量服务时保持自动。SERVED\_NAME``escha\-qwen38\-27b\-w2客户端必须发送的模型 ID。 针对不同架构和不同显存的启动配置方案请参见运行时“在您的 GPU 上运行”手册 (https://huggingface.co/EschaLabs/escha-runtime-qwen3dense/blob/main/sglang/INSTALL.md#running-on-your-gpu)。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#verified-configurations已验证配置

三个层级，均在命名的物理显卡上测量，2026‑08‑20。以下是跨 GPU 性能 (https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#performance-across-gpus) 中数据背后的命令。

``

24 GB，单用户——出厂默认值，完整 64k 上下文

MODEL=./Qwen3.8-27B-Escha-W2 bash sglang/serve.sh # 4090: 67 tok/s bs1 · 18.1 GB

在 RTX 3090（或任何 sm_80/86）上添加 ESCHA_ROUTE=blackwell # 3090: 23.6 -> 40.7 tok/s bs1

24 GB，吞吐量优先——更多流，更短上下文，每个扫描的批处理都捕获图。

MAXREQ/MAXMAMBA 是实际提升流上限的参数：出厂的 MEM/MAMBA_RATIO

将 24 GB 显卡限制为 8-9 个流，无论 CUDA_GRAPH_BS 如何设置。

MODEL=./Qwen3.8-27B-Escha-W2 MEM=0.86 CTXLEN=32768 MAXREQ=32 MAXMAMBA=32
CUDA_GRAPH_BS=“1 2 4 8 12 16 24 32” bash sglang/serve.sh # 4090: 649 tok/s @ 16 流

32 GB (RTX 5090, sm_120)——消费级 Blackwell 必须使用 triton 注意力

MODEL=./Qwen3.8-27B-Escha-W2 ATTN_BACKEND=triton MEM=0.85 CTXLEN=65536 MAXREQ=32 MAXMAMBA=32
CUDA_GRAPH_BS=“1 2 4 8 12 16 24 32” bash sglang/serve.sh # 5090: 87.1 tok/s bs1 · 955 @ 16 ``

上下文和并发使用同一个共享池，哪部分成为限制取决于你的提示长度：对于短提示，限制是循环状态（每个流约 0.15 GB，与上下文无关）；对于长提示，限制是 KV 池。无论哪种情况，仅缩短 CTXLEN 无法增加流数——请与 MEM 一起提高 MAXREQ/MAXMAMBA，然后检查服务器日志中的 #running\-req 是否与你实际请求的批处理大小匹配。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#long-context长上下文

CTXLEN=65536 是默认值，而非限制。以下所有测试均在 RTX 4090 (24 GB) 上于 2026‑08‑21 进行，使用此 serve\.sh 和发布 wheel，GRAPHS=1 INT8=on。

上下文的成本。 只有 64 层中的 16 层是全注意力（每 4 层一个）；其他 48 层是门控‑delta‑网，每个流持有固定的约 0.15 GB 循环状态，不随上下文增长。因此 KV 缓存为每 token 64 KiB——16 层 × 4 个 KV 头 × 256 头维度 × 2（K 和 V）× 2 字节。一个在所有层上都使用全注意力的传统密集 27B 模型将消耗 4 倍于此的显存。这就是 128k 上下文能在消费级显卡上运行的原因。

容量规划。 池随 MEM 线性增长，在 24 GB 显卡上每 1.0 约 366,600 个 token：

MEM``CTXLEN池 (max\_total\_num\_tokens)余量峰值显存0\.72（出厂默认）65,53668,686+3,15018.3 GB0\.8098,304112,105+13,80119.9 GB0\.84131,072126,767*−4,305 — 太小20.8 GB0\.88131,072141,431***+10,35921.8 GB0\.92147,456156,092+8,63622.7 GB0\.94163,840163,424−416 — 太小**23.1 GB ``

24 GB，一个 128k 的长流——测量：120,000 token 的提示在 68 秒内回答，

峰值 24 GB 中的 22.1 GB。这是此显卡上具有舒适余量的最大上下文。

MODEL=./Qwen3.8-27B-Escha-W2 MEM=0.88 CTXLEN=131072 MAXREQ=1 MAXMAMBA=2
CHUNK=2048 INT8=on bash sglang/serve.sh ``

在 MEM=0\.92 时 147,456 是实际最大值；160k 无法容纳。注意 0\.84 和 0\.94 行在启动时状态健康，但其池小于自身的 CTXLEN——服务器日志无错误，且默认的 TRUNCATE=1 会静默修剪过长的提示而非拒绝。启动行是唯一重要的检查点：max\_total\_num\_tokens 必须 ≥ 你的并发流数 × 你的上下文长度。 对于智能体工作，考虑 TRUNCATE=0，这样过长的提示会大声失败，而非静默丢弃头部。

上下文和并发是同一预算。 出厂默认值的池为 68,686 token——仅比其自身 65,536 上限多 3,150。它恰好容纳一个完整长度的 64k 流。文档中其他地方提到的“8‑9 个并发流”假设了短提示（每个约 8k）；你无法同时拥有两者。上面的单流配置方案本身就是单流的。

前缀缓存对增长中的对话无帮助。 在 RADIX=1 下测量 120k：

请求重新填充的缓存耗时全新的 120k 提示120,000066.5 s完全相同的提示再次出现1,216118,784****1.4 s116k 共享前缀 + 4k 新内容120,000065.7 s完整的 60k 前缀 + 4k 追加*（在 60k 工作集上测量，池有余量）*64,000029.4 s 只有精确、完整的匹配才会被重用。纯追加——缓存序列是新请求的完整前缀，且池有余量——不会重用任何内容。我们没有追踪到具体代码路径；如果循环状态仅在它被捕获的边界处有效，那么从部分位置恢复将无物可用，这符合预期。因此 RADIX=1 适用于重试、缓存预热和对固定提示的多样本采样；对于追加工具结果并重新发送的智能体循环无效。在每个回合预算完整的预填充：120k 约 68 秒，60k 约 27 秒。 保持工作上下文小是此处的延迟杠杆，而非缓存它。（如果你仍启用它，RADIX=1 需要 MAXREQ≥ 2——MAXREQ=1 会导致服务器启动失败。）

64k 以上质量未经验证。 262,144 是架构自身的限制，上述内存已测量，但我们的长上下文检索结果来自不同的（混合专家）模型，不适用于此模型。120k token 的提示产生连贯、切题的续写——这表明其功能正常，而非检索精度可靠。在依赖它之前，请在你自己的工作负载上测量。

此检查点仅支持文本。qwen3\_5 配置声明了视觉塔，但量化权重中不包含——它在量化 ignore 列表中，且检查点没有 visual\.* 张量。serve\.sh 设置了 SGLANG\_VLM\_TEXT\_ONLY=1，因此视觉塔从不实例化。请勿发送图像输入。

https://huggingface.co/EschaLabs/Qwen3.8-27B-Escha-W2#requirements-in-detail详细要求

• GPU： NVIDIA sm_80 或更新（Ampere, Ada, Hopper, Blackwell）。wheel 包含覆盖 sm_80/86/89/90/100/120 的 fatbin。
• 仅需驱动程序 —— 无需 CUDA 工具包。如果你已安装，`TRITON_PTXAS_PATH