RTX PRO 4500 32G 跑 Qwen3.8-27B：Unsloth Desktop 默认参数 + MTP，2 槽位 × 150K，短上下文 54–64 t/s（GSP 篇续集，附完整配置）

[清风明月]

RTX PRO 4500 32G 跑 Qwen3.8-27B：Unsloth Desktop 默认参数 + MTP，2 槽位 × 150K，短上下文 54–64 t/s（GSP 篇续集，附完整配置）

平台：Linux（Ubuntu）/ llama.cpp（Unsloth Desktop 0.1.801 生成参数）/ NVIDIA RTX PRO 4500 Blackwell 32GB
模型：Qwen3.8-27B-UD-Q4_K_XL（Unsloth Dynamic v3.0，17.56GB）+ mmproj-F16（0.88GB）
配置：2 并行槽位 / 153856 ctx / MTP n-max 2 / Flash Attention / KV unified（q8_0：K=Q8_0 + V=Q8_0）
日期：2026-08-21（含全天 MTP 接受率统计 195 次请求 + 高上下文压测）
上一篇：《Qwen3.8-27B llama.cpp 部署实测与 Blackwell GSP 崩溃分析》（topic/1222），本篇是同一张卡的另一套日常配置，两篇对照着看。

这张 RTX PRO 4500 买来就是为了跑本地 LLM，上篇踩了 GSP 崩溃的坑，折腾了不少。后来翻了论坛上各位大神的帖子（5070 Ti、双 3090、7900 XTX 的实测），又研究了 Unsloth 的桌面软件（口碑不错，会根据不同硬件自动生成初始参数）。拿到它的默认参数后，在实机上慢慢调，先加 MTP，再调 KV 量化，一步一步来。现在这套配置跑了一段时间，貌似不怎么崩了，分享给大家参考。

一、先说结论

• 上一帖是「单槽位 + 128K + K4V4」的稳定性向配置（67.2 t/s 压测均速）。这次换了 Unsloth Desktop 0.1.801 自动生成的默认参数 + 手动加 MTP，2 槽位 × 150K 日常向配置：短上下文平均 54.6 t/s（45.4–64.1），71K 上下文 18.6–41.1 t/s。

• MTP 接受率 72.87%（195 次请求全天统计），平均每次验证步骤实际产出 2.55 个 token，理论加速上限 ~2.5×，实测相对关 MTP（24.5 t/s）加速 2.2–2.6×，效率约 89%。

• Unsloth Desktop 的自动参数直接可用，我只手动加了 2 行（MTP 开关 + n-max），没手调其它参数。32GB 卡跑 2 槽位 × 150K 全层 GPU，显存 ≈25.4GB，余量 ~6.6GB（q8_0 KV）。

• 白话：MTP = 模型自带的「草稿头」先猜 2 个 token，主模型一次前向全部验证，猜中就白拿。猜中率 72.87%，等于每步白捡 1.5 个 token，速度直接翻 2 倍出头。

• 注意：2 小时 0 崩溃 ≠ 长期稳定，Blackwell GSP 固件 bug（Xid 62/8/154）还在，根因分析与规避手段见上一篇，本篇不重复。

二、模型参数卡（官方 config.json × GGUF 头双重核对）

以下数据来自 HuggingFace 官方 Qwen/Qwen3.8-27B 的 config.json，并与本地 GGUF 头部元数据逐项核对一致：

| 项 | 值 |
| 架构 | Qwen3_5ForConditionalGeneration（model_type: qwen3_5），原生多模态：文本 + 图像 + 视频 |
| 参数量 | 27B（dense，非 MoE），BF16 原生 |
| 层数 | 64 主层 + 1 MTP 层（GGUF block_count=65） |
| 注意力 | 混合式：48 层线性注意力（Gated DeltaNet：conv k=4，16 key heads × 128 / 48 value heads × 128，SSM fp32）+ 16 层全注意力（full_attention_interval=4） |
| 全注意力细节 | 24 heads / 4 KV heads（GQA 6:1），head_dim 256，partial rotary 0.25，rope_theta 1e7，mRoPE 交错（多模态 RoPE） |
| 隐层 / FFN | hidden 5120 / FFN 17408（SiLU + 输出门） |
| 上下文 | 原生 256K（max_position_embeddings 262144） |
| MTP | mtp_num_hidden_layers=1，共享 embeddings（无独立 embed 表），即 llama.cpp 的 --spec-type draft-mtp |
| 词表 | 248,320 |
| 视觉塔 | ViT depth 27 / hidden 1152，image_token 248056 / video_token 248057 |
| 量化（本卡） | UD-Q4_K_XL（Unsloth Dynamic v3.0 混合精度，imatrix 校准），17.56GB，≈5.2 BPW；mmproj-F16 0.88GB |
| 仓库 | 官方 Qwen/Qwen3.8-27B（apache-2.0）/ 量化 unsloth/Qwen3.8-27B-GGUF |

两个和本篇速度直接相关的点：只有 16 层全注意力存 KV cache（线性注意力层只占固定大小状态），所以 150K 上下文的 KV 在 f16 下 ~10GB、q8_0 下 ~5.4GB，2 槽位才塞得下；MTP 头共享 lm_head，不额外占权重。

三、硬件 / 软件环境

| 项 | 配置 |
| 显卡 | NVIDIA RTX PRO 4500 Blackwell 32GB（sm_120，GB202，显存带宽 896 GB/s） |
| 系统 | Ubuntu（Linux） |
| 框架 | llama.cpp，Unsloth Desktop 0.1.801 安装并生成启动参数 |
| 模型 | Qwen3.8-27B-UD-Q4_K_XL.gguf（17.56GB）+ mmproj-F16.gguf（0.88GB） |
| 服务方式 | systemd 服务 llama-qwen-27B.service，端口 8000 |

四、完整配置（可直接复制）

Unsloth Desktop 自动生成基础参数，我手动只加了 MTP 两行（--spec-type / --spec-draft-n-max）：

# systemd service: llama-qwen-27B.service
llama-server \
  -m ~/models/Qwen3.8-27B/Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --mmproj ~/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias Qwen3.8-27B \
  --port 8000 \
  --parallel 2 \
  --flash-attn on \
  --no-context-shift \
  -c 153856 \
  -ngl -1 \
  --fit off \
  --metrics \
  --slot-save-path ~/.unsloth/studio/cache/llama-slots \
  --kv-unified \
  --jinja \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --reasoning on --reasoning-preserve

关键参数说明

| 参数 | 为什么 |
| --spec-type draft-mtp / --spec-draft-n-max 2 | MTP 投机解码，每步猜 2 个。参数名别写旧名 mtp（启动直接失败）；n≥3 在 Blackwell 上收益递减（上篇实测） |
| --parallel 2 | 2 槽位并行，主对话 + 后台任务同时跑，互不排队 |
| -c 153856 | ~150K 上下文。模型原生 256K，但 ctx 越长单次 kernel 耗时越接近 GSP 看门狗阈值（上篇），150K 是 2 槽位的显存/稳定平衡点 |
| --kv-unified | 多槽位共享统一 KV 内存池，避免每槽位独立预分配的碎片浪费 |
| --flash-attn on | 必须开。关闭后 attention kernel 更慢，既掉速又更贴近 GSP 7 秒看门狗阈值 |
| --no-context-shift | 上下文超限时直接报错而不是静默截断/移位，agent 场景不接受静默降级 |
| --reasoning on --reasoning-preserve | 保留思考 token，多轮 agent 场景思考链不丢 |
| -ngl -1 / --fit off | 全层上 GPU（32GB 放得下），禁用自动压缩 |
| --slot-save-path | Unsloth Desktop 的槽位状态缓存，桌面端重开可恢复会话 |
显存账本（2 槽位 × 150K，当前 q8_0 KV）： 权重 17.56GB + mmproj 0.88GB + KV（16 层全注意力 × 153856 token × 34KB/token）≈ 5.4GB + 线性注意力状态与计算缓冲 ≈ 0.6GB ≈ 25.4GB / 32GB，余量 ~6.6GB（切换后实测比 f16 省 3.6GB）。

五、实测数据

测法：短上下文 = 日常真实请求，speed 取自 systemd journalctl 实时日志（llama-server 每请求一条 prompt eval + eval 统计）；高上下文 = 预置 ~71K token 填充后生成 4096 token；接受率 = journalctl 的 Draft Acceptance 行，全天 195 次请求全量统计，非抽样。

5.1 短上下文（日常交互，2026-08-21 14:33–14:36）

| 时间 | 生成 tokens | 耗时 (ms) | 速度 (t/s) |
| 14:33:42 | 2588 | 45254 | 57.17 |
| 14:34:06 | 1160 | 23092 | 50.19 |
| 14:34:29 | 1140 | 21017 | 54.19 |
| 14:34:45 | 873 | 14390 | 60.60 |
| 14:34:57 | 488 | 10242 | 47.55 |
| 14:35:06 | 394 | 7984 | 49.22 |
| 14:35:21 | 838 | 13048 | 64.14 |
| 14:35:35 | 811 | 12853 | 63.02 |
| 14:35:56 | 752 | 16555 | 45.36 |
| 14:36:07 | 525 | 9589 | 54.65 |

平均 54.6 t/s，范围 45.36–64.14。 波动主要来自 2 槽位偶发并发与请求长度分布，非性能衰减。（注：本表为 f16 KV 时代数据，切换 q8_0 后短 ctx 实测更高，见 5.5）

5.2 高上下文压测（~71K ctx 填充 + 4096 生成，2026-08-21 13:14–13:30）

| 请求 | 上下文 tokens | 生成 tokens | 耗时 (s) | 速度 (t/s) |
| req 1 | 71280 | 4096 | 220.5 | 18.6 |
| req 2 | 71764 | 4096 | 99.5 | 41.1 |
| req 4 | 71791 | 4096 | 380.6 | 10.8（离群，见踩坑 #4） |

71K 上下文下 18.6–41.1 t/s，衰减明显但可用。高 ctx 下 MTP 收益缩小（验证步骤变贵），这是混合注意力模型的通性，不是配置问题。

5.3 MTP 接受率（全天 195 次请求）

• 平均接受率 72.87%，范围 62.7%–97.6%
• 平均每次验证步骤产出 2.55 token（1 个主模型 bonus + 1.55 个被接受的草稿）
• 接受率与内容强相关：结构化输出（JSON/代码/固定格式）常 93%–97.6%，自由长文本 62.7%–77%

抽样 10 次：

| 时间 | 接受率 | 接受/生成 | 每步 token |
| 14:33:42 | 87.57% | 1648/1882 | 2.75 |
| 14:34:06 | 71.95% | 685/952 | 2.44 |
| 14:34:29 | 76.28% | 688/902 | 2.53 |
| 14:34:45 | 93.42% | 568/608 | 2.87 |
| 14:34:57 | 62.73% | 271/432 | 2.25 |
| 14:35:06 | 67.26% | 226/336 | 2.35 |
| 14:35:21 | 96.33% | 551/572 | 2.93 |
| 14:35:35 | 97.64% | 537/550 | 2.95 |
| 14:35:56 | 67.71% | 432/638 | 2.35 |
| 14:36:07 | 92.94% | 342/368 | 2.86 |

5.4 上下文衰减阶梯（8K–128K，2026-08-21 补测）

上下文	实际 token	Prefill (t/s)	生成速度 (t/s)	相对基线
~2K（日常对话）	37–49	~220	72.4	100%
8K	8,222	1,498	70.7	97.7%
16K	16,414	1,455	67.8	93.6%
32K	32,798	1,330	64.2	88.7%
64K	65,556	1,189	58.3	80.5%
128K	131,076	873	51.7	71.4%

测法：slot 0、MTP n2、reasoning off（纯速度测量）、每级预热后取稳态值（f16 KV 下测得）。衰减是渐进的，32K 以内基本无感（<12%），64K 起有感（~20%），128K 掉 ~29% 仍有 52 t/s。"明显变慢"的分水岭约在 64K–100K。

5.5 q8_0 KV 量化实测（2026-08-21 切换后）

指标	f16（之前）	q8_0（现在）	变化
VRAM 占用	~29 GB	~25.4 GB	-3.6 GB
显存余量	~3 GB	~6.6 GB	+3.6 GB
32K 上下文生成速度	64.2 t/s	68.4 t/s	+6%
GPU 利用率（生成时）	高	93-100%	正常
CPU 占用	正常	~100%（单核）	正常

q8_0 全 8bit KV 切换后 VRAM 从 ~29GB 降至 ~25.4GB（省 3.6GB），32K 生成速度 68.4 t/s 比 f16 还快 6%。踩坑记录：先试过 q8v4（K=Q8+V=Q4）不对称方案，但 llama.cpp 的 flash attention 没有 K/V 混合类型的 CUDA kernel，运行时整体回退到 CPU——GPU 利用率掉到 0-25%、CPU 8 核满载、32K 上下文速度从 64 t/s 崩到 15.8 t/s。关键结论：K/V cache 必须对称——K4V4（Q4+Q4）实测 32K=59.1 / 64K=44.4 t/s 完全正常，q8_0（Q8+Q8）也正常。切换 KV 量化后务必跑长上下文验证（短 ctx 测不出来）。

5.6 DFlash2 块扩散投机解码对比实测（2026-08-21）

DFlash2 是 Z-Lab 的块扩散草稿模型（Inco 发布 Qwen3.8-27B 专用草稿头），llama.cpp 支持 --spec-type draft-dflash（本机 commit 5ecbe1a）。用独立测试服务（端口 8001，q8_0 KV 与生产一致）实测对比：

上下文	MTP n2（生产）	DFlash2（测试）	胜者
短 ctx	72.4 t/s	47.3 t/s	MTP（快 53%）
32K	64.2 t/s	54.0 t/s	MTP（快 19%）
64K	58.3 t/s	45.9 t/s	MTP（快 27%）
64K 衰减	19%	37%	MTP 更平缓
GPU 利用率	93-100%	93-97%	平

结论：本卡上 DFlash2 全面落后 MTP n2，不值得切换。 根因：Q4_K_M 草稿接受率仅 26.8%（vs MTP 72.87%），块扩散每步验证 8 个 token 的前向开销没被低接受率赚回来；短 ctx 下验证成本占比更高所以最慢。DFlash2 官方说明为无损投机（greedy 输出与主模型一致），质量无虞，只是速度不划算。

备注：--hf-repo-draft 在本构建有 bug（草稿路径解析为空），需用 --model-draft 指定本地 GGUF 路径。

六、MTP 加速账：从接受率到 2.2×

n-max 2 时每步产出 = 1 + p₁ + p₁·p₂（p₁、p₂ 为两个草稿位置的条件接受概率），实测均值 2.55 token/步。验证 3 个 token 的前向比单 token 略贵，理论上限约 2.5×。

| 配置 | 短上下文速度 | 相对无 MTP |
| MTP n-max 2（本篇，2 槽位 150K） | 54.6 t/s（均值） | 2.23×（范围 1.85–2.62×） |
| MTP 关闭（同卡实测 2026-08-19） | 24.5 t/s | 1× |
| 理论上限（2.55 token/步） | — | ~2.5× |

实测 2.23× 达到理论上限的 ~89%，剩余 11% 就是验证开销 + 偶尔的整组拒绝。这个效率对 dense 模型来说很健康（社区 MoE 模型 MTP 常见 1.5–1.7×，见 topic/1207 注）。

七、社区跨卡对照（同模型 Qwen3.8-27B，均为本版论坛实测帖）

| 卡 | 框架 | 量化 | 配置 | 速度 | 出处 |
| RTX PRO 4500 32G（本篇） | llama.cpp | UD-Q4_K_XL | 2 槽位 150K，MTP n2 | 54.6（短 ctx 均值） | 本帖 |
| RTX PRO 4500 32G（上篇） | llama.cpp | UD-Q4_K_XL | 1 槽位 128K，MTP n2，K4V4 | 67.2（1h 压测均值） | topic/1222 |
| RTX 5070 Ti 16G | llama.cpp | IQ4_XS | 1 槽位 32K | 38–43 | topic/1207 |
| 双 3090 24G NVLink | vLLM | AWQ-INT4 | 262K，MTP n3 | ~130（工具调用） | topic/1245 |
| 7900 XTX 24G | llama.cpp Vulkan | Q4_K_M | 1 槽位 128K | 73.4 | topic/1164 |
| 7900 XTX 24G | llama.cpp Vulkan | Q4_K_M | 1 槽位 256K，MTP n3，K4V4 | 67 | topic/100 |

ctx、量化、框架、槽位数都不同，这张表只给量级感：32GB 卡单卡 llama.cpp 路线，短上下文 50–67 t/s 是这个模型在 Blackwell 专业卡上的正常水位。

关于 topic/100（7900XTX + K4V4）的补充：该帖的 K4V4（Q4+Q4 对称）跑满 256K 正常，与本篇结论互相印证——llama.cpp 对对称 KV 类型（K4V4 或 q8_0）的支持与显卡无关，NVIDIA CUDA 下对称 K4V4 同样正常（本篇实测 32K=59.1 / 64K=44.4 t/s）。q8v4（K=Q8+V=Q4）混合类型回退 CPU 是 llama.cpp 通病，AMD Vulkan 后端同样不应混用。

八、踩坑与经验

1. MTP 参数名：--spec-type draft-mtp，写旧名 mtp 直接启动失败（日志里一句 spec 相关行都没有就是没启用）；n-max 2 是 Blackwell 甜点位，n≥3 验证开销追上接受率收益。
2. Unsloth Desktop 自动参数直接可用：0.1.801 生成的 flash-attn / kv-unified / no-context-shift / fit off 组合在 32GB 卡上开箱即稳，本次唯一手改就是 MTP 两行。桌面端小白流和手搓 systemd 流殊途同归。
3. 2 槽位 × 150K 的显存红线 ≈29GB：再往上（200K 或 3 槽位）就吃紧。优先 q8_0（--cache-type-k q8_0 --cache-type-v q8_0，质量几乎无损，省 ~3.6GB）；q4_0（K4V4）不建议（8.3% 输出相似度质量悬崖 + CPU 回退风险）。
4. req4 的 10.8 t/s 是离群点：380 秒跑 4096 token，量级对应 GSP 看门狗心跳窗口 + 2 槽位争抢，不作外推依据；遇到单次掉速先看 journalctl 有没有 NVRM/Xid 行，有就是上篇那个 bug，没有就是槽位争抢。
5. 稳定性预期管理：本篇 08-21 13:45 启动、0 崩溃、稳定 2 小时——但 GSP 固件 bug（Xid 62/154/79 或静默硬挂，需断电恢复）没修，无人值守批量推理必须挂看门狗 + 断电恢复（或留请求间隔 / 关 GSP），详见上篇根因章节。
6. 接受率是内容函数不是配置函数：JSON/代码类结构化输出接受率 93%+，自由文本 63% 上下。如果你的 agent 负载以结构化为主，MTP 收益只会比本篇更高。
7. K/V cache 必须对称（重要）：llama.cpp 的 flash attention 不支持 K/V 混合类型（如 K=Q8_0+V=Q4_0），会整体回退到 CPU（GPU 利用率 0-25%、CPU 8 核满载、32K 速度暴跌 4 倍）。对称组合 K4V4（Q4+Q4）和 q8_0（Q8+Q8）都正常。切换 KV 量化后务必跑 32K/64K 长上下文验证（短 ctx 测不出来）。

九、KV 量化质量对比与下一步

质量影响（网测数据）

InventiveHQ 在同模型上做了 f16 / q8_0 / q4_0 KV cache 直接对比（8K 上下文）：

KV 类型	输出相似度（vs f16）	评价
f16（基准）	100%	—
q8_0	81.6%	安全交易，质量损失可控
q4_0	8.3%	质量悬崖，回答完全不同

Particula.tech 补充：Qwen 系列在 q8_0 下 KL 散度 < 0.04（极低），q4_0 损失真实且模型相关。来源：InventiveHQ / Particula

对本模型的特殊考虑：Qwen3.8-27B 只有 16/65 层存 KV（48 层线性注意力是 fp32 无损状态），质量影响理论上比同参数纯 Transformer 小得多。

社区实际使用反馈：有用户在 7900XTX 24G 上用 K4V4（Q4_0 KV）跑满 256K 上下文做代码生成，评价"质量不比在线 API 差"（topic/100）。这与 InventiveHQ 的 8.3% 相似度数据存在张力——可能的原因：(1) 8.3% 是文本相似度指标，捕捉到了措辞/表述差异，但代码功能正确性不受影响；(2) Qwen3.6-27B 与 Qwen3.8-27B 架构不同，质量衰减可能不同；(3) 主观感受难以捕捉长上下文末尾的细微召回丢失。结论：K4V4 对代码生成可能"够用"，但对长文档精确召回（如 needle-in-haystack）仍有风险，q8_0 是更稳妥的选择。

q8_0（K=Q8, V=Q8）分析（q8v4 已弃用）

q8_0 全量 8bit KV：每 token 34KB（vs f16 64KB / q4_0 18KB）。曾试过 q8v4（K=Q8+V=Q4）不对称方案，但 llama.cpp 的 flash attention 不支持 K/V 混合类型，整体回退 CPU（GPU 0-25%、CPU 8 核满载、32K 崩到 15.8 t/s），不可用。对称组合都正常：K4V4（Q4+Q4）32K=59.1 / 64K=44.4 t/s，q8_0（Q8+Q8）32K=68.4 t/s。

方案	每 token KV	150K 池	总显存	余量
f16（现状）	64KB	9.9GB	~29GB	~3GB
q8_0（已上线）	34KB	5.4GB	~25.4 GB（实测）	~6.6 GB
q4_0（K4V4）	18KB	2.8GB	~21.8GB	~10.2GB

为什么不推荐 q8v4 不对称方案：理论上 Key 用 Q8 保留注意力模式精度、Value 用 Q4 省显存很诱人，但 llama.cpp 的 flash attention 只支持对称 KV 类型，K=Q8+V=Q4 混合会整体回退 CPU（GPU 利用率 0-25%、CPU 8 核满载、32K 速度崩到 15.8 t/s），实际不可用。K/V 类型必须对称（K4V4 或 q8_0 均可，速度都正常）。

（补充：q8v4 在非 Unsloth 配置下崩过，但归因是 GSP 固件 bug 的负载模式触发，与量化格式无因果。）

下一步建议

1. 日常已切换 q8_0（K=Q8_0 + V=Q8_0）：VRAM ~25.4GB / 余量 ~6.6GB / 32K 上下文 68.4 t/s，标准版与免审查版均已生效。
2. 需要省显存时首选 q8_0（--cache-type-k q8_0 --cache-type-v q8_0），质量几乎无损，多 ~4.7GB 余量，够冲 200K 或第 3 槽位。
3. q8v4 已弃用：K/V 混合类型（Q8+Q4）触发 CPU 回退（GPU 闲置、CPU 满载、速度暴跌 4 倍），不要用；K/V 类型保持对称（K4V4 或 q8_0）。
4. q4_0（K4V4）仅在"塞不下"时考虑：8.3% 输出相似度是质量悬崖，即使本模型有 16 层优势也不建议轻易尝试。
5. 待验证：q8_0 日常使用质量观察；n-max 3 在 2 槽位下的接受率/速度拐点（DFlash2 已实测淘汰）；GSP 修复（等 NVIDIA）后再谈 200K+。

---

数据来源：systemd journalctl（MTP 接受率 195 次请求全量）+ 高 ctx 压测脚本 + 长上下文 CPU 回退验证；模型参数来自官方 config.json 与 GGUF 头部元数据双重核对。

[清风明月]

在blackwell固件没解决前，MTP还是容易崩，还是换成unsloth默认参数了，只把槽位改成2，再用一段时间看看。速度确实不如MTP。

[清风明月]

看来unsloth的模型及其优化在固件bug不能解决的情况下，还是尽可能把参数调优到各种机器都能顺利运行了：
测试完成，六级全部通过，零崩溃。结果在 /tmp/ctx-stress-27b-20260822-010212.md。

关键数据（实际 prompt_tokens 比名义目标更深，因中文填充每行 token 数高于预估）：

档位	实际深度	耗时	prefill	/health
4K	5.5K	8.5s	652 t/s	ok
8K	11K	9.3s	1206 t/s	ok
16K	22K	16s	1411 t/s	ok
32K	47K	34s	1372 t/s	ok
64K	96K	81s	1192 t/s	ok
128K	194K	224s	870 t/s	ok

结论：

• 最深处实际打到 194K context，超过之前 128K 崩溃边界，全程无 Xid、无 500、/health 每级存活
• prefill 随深度缓降（1411→870 t/s），194K 下 224s 完成一轮，可用
• 8K/16K/64K 三档回答为空属预期：temp=0 下思考 token 吃满 max_tokens=64，content 为空，非故障（4K/32K/128K 正常出数可证响应链完整）