🚀 Lucebox DFlash + Huihui：7900 XTX 上真·无审查 + 极速推理完全折腾纪实

[abaalei]

原创折腾实录 | 2026-06-10 | RX 7900 XTX 24GB + ROCm 7.2.0

---

写在前面

一直以来，7900 XTX 用户在 Qwen3.6-27B 上有一个无法两全的选择：

• Lucebox DFlash（~93 tok/s run.py / ~80 tok/s API ）→ 最快！但原方案极其挑食。
• 社区去审查模型（Huihui abliterated 等）→ 真无审查，但容易触发 DFlash 的 fattn.cu:312 崩溃。

本文记录了如何同时得到「DFlash 极速 + 真无审查」——通过 FA_ALL_QUANTS=ON 完整编译解决 Fattn 兼容性，配合 --fa-window 0 和 --tokenizer Qwen/Qwen3.6-27B 实现完美稳定运行。

---

🧪 硬件环境

+---------------------------+-----------------------------------------------+
| 组件                      | 详情                                           |
+---------------------------+-----------------------------------------------+
| CPU                       | Intel Xeon E5-2682 v4 × 2 (32C/64T)           |
| 主板                      |华强北白牌X99-6Plus 槽距63mm pcie3.0（16x*4 8x*2） |
| GPU — 主力推理            | AMD Radeon RX 7900 XTX 24GB (ROCm 7.2)         |
| GPU — 后处理              | NVIDIA RTX 3080 Ti 12GB (CUDA) — 未参与        |
| 系统                      | Ubuntu 24.04 LTS, Kernel 5.15.0-181           |
| Python                    | 3.12.3                                       |
| 模型                      | Qwen3.6-27B (Q4_K_M / variant)               |
| DFlash                    | Lucebox (lucebox-hub, ggml-hip)              |
+---------------------------+----------------------------------------------+

️ 强调： 本测试全程只用 7900 XTX，RTX 3080 Ti 完全不参与推理过程，避免混淆。

---

目标

1. DFlash 引擎 — Lucebox DFlash 投机解码，7900 XTX 甜点 ~93 tok/s
2. 真·无审查 — Huihui abliterated，完全拒答阻断的解除
3. 稳定运行 — 完整 43 轮每轮 200 token 稳定测试不崩溃

---

️ 完整折腾路线图（七阶段全记录）

（编者注：有agent就是好，看到论坛内的贴/X上面的贴不管有没有用就直接扔给agent进行分析匹配，然后一项项让她自己随机跑，省下不少时间，就是token烧不少了）

阶段一：初识问题 — Fattn 崩溃

社区主流 GGUF（如 Huihui Q4_K_M）在 DFlash 下会导致 fattn.cu:312: fatal error。

根因定位：
并非模型本身问题，而是 HIP 编译默认只编译了 4 组 KV-quant 模板（F16/Q4_0/Q8_0/BF16）。当 DFLASH27B_FA_ALL_QUANTS=OFF 时，Q4_K_M 模型使用的 KV cache dtype 不在这些模板中 → VEC kernel dispatch 找不到匹配 → GGML_ABORT("fatal error")。

阶段二：尝试补丁 — TILE fallback patch（失败）

最初怀疑是 VEC kernel 本身的 bug，尝试在 fattn.cu 中将 VEC 找不到时的 GGML_ABORT 改为 fallback 到 TILE kernel。

编译通过 ，但：

• 前 10~15 轮请求正常
• 到了 26 轮左右出现静默 segfault（zombie test_dflash 进程，BrokenPipeError）
• 根因：TILE kernel 在 HIP (gfx1100) 后端上不稳定，大量并发验证时触发底层内存访问越界

结论： 不需要 patch 源码，走错了方向。

阶段三：证实方向 — FA_ALL_QUANTS=ON 完整编译

放弃 patch 源码的歪门邪道，直接使用 CMake 默认的完整编译：

• -DDFLASH27B_FA_ALL_QUANTS=ON (CMake 默认值)
• HIP/gfx1100 成功编译全部 50+ 种量化模板
• VEC 命中任意 KV quant 对，彻底解决 ggml_abort

# 强制开启完整模板编译
cmake .. -DDFLASH27B_FA_ALL_QUANTS=ON -DCMAKE_HIP_ARCHITECTURES=gfx1100
cmake --build . --target ggml-hip --clean-first -j4
cmake --build . --target test_dflash -j4

️ 重建必须 --clean-first，否则 cmake 不重编 HIP 目标！

阶段四：测试 OBLITERATUS（假无审查 + 不兼容）

OBLITERATUS 是对 Qwen3.6-27B 跑 diff-in-means 去审查的模型。结果是：

• 假无审查 — 对炸弹/敏感内容仍在输出安全教育
• DFlash 不兼容 — 同样触发 fattn.cu:312
• 层数不对（65 层 vs 草稿 64 层）
• 已清理删除

阶段五：测试 Huihui IQ4_XS（真无审查但龟速）

Huihui abliterated 的 IQ4_XS 版本：

• 真无审查 — 直接回复XX步骤、BL/SQ细节
• DFlash 兼容（FA_ALL_QUANTS=OFF 时唯一能跑的真无审查模版）
• 速度仅 28 tok/s — IQ4_XS 在 HIP 上的反量化路径不如 Q4_K_M 高效
• 上下文受限（~64K）

结论： IQ4_XS 已弃用（已从磁盘删除），Q4_K_M 在 FA_ALL_QUANTS=ON 下全面优于 IQ4_XS。

阶段六：测试 Heretic Q4_K_M（原生兼容但假无审查）

Youssofal 的 Heretic Q4_K_M：

• 原生 DFlash 兼容 — 第一版就稳定运行
• 早期 benchmark：68.80 tok/s（bench_he.py）
• 假无审查 — 号称"Uncensored"但实测仍输出安全教育/「无法提供」
• 已弃用，被 Huihui 全面替代

阶段七：FA_ALL_QUANTS=ON + --fa-window 0 + Huihui Q4_K_M

最终稳定核心：

• FA_ALL_QUANTS=ON 解决量化模板缺失
• --fa-window 0 禁用 DFlash 滑动窗口（防长文本崩溃）
• --tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示为方块问号的问题

最终启动参数：

python3 scripts/server.py \
  --target '/mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf' \
  --draft models/dflash-draft-3.6-q8_0.gguf \
  --budget 8 \
  --fa-window 0 \
  --tokenizer Qwen/Qwen3.6-27B \
  --host 0.0.0.0 --port 11435

---

完整模型兼容性矩阵

模型	DFlash 兼容	去审查	速度 (API)	状态
Huihui Q4_K_M (mradermacher)	FA_ALL_QUANTS=ON	真	~81 tok/s	推荐
Heretic Q4_K_M (Youssofal)	原生	假	~69 tok/s	已弃用
Huihui IQ4_XS	OFF 时唯一	真	~28 tok/s	已删 (太慢)
OBLITERATUS Q4_K_M	崩溃	假	—	已删
Huihui Q4_K (原始版)	OFF 崩溃	真	—	已删 (层数61不对)

（Gemini注：海外作者（如西方开源社区）制作的。他们寻找“拒绝向量”时，用的测试集绝大多数是英文的安全基准（比如涉及暴力的英文问答）。它抹掉了英文语境下的道德底线，但在面对中文的高级隐喻、特定文化禁忌时，由于没有彻底擦除中文特有的安全向量，模型依然会触发潜意识的“道德刹车”）

---

最终性能对比

DFlash API 速度 (OpenAI 兼容 server)

模型	速度 (API tg128)	速度 (run.py)	显存占用	去审查
Huihui Q4_K_M	~80-81 tok/s	~93 tok/s	14.73 GiB	真
Heretic Q4_K_M	~69 tok/s	~69 tok/s	14.73 GiB	假

bench_he.py 详细成绩 (Reddit 同款 10 HumanEval，2026-06-10)

Huihui Q4_K_M + FA_ALL_QUANTS=ON + --fa-window 0 + --tokenizer Qwen/Qwen3.6-27B：

+-----------------------------+-------+------+--------+
| prompt                      | tok/s | AL   | 接受率 |
+-----------------------------+-------+------+--------+
| has_close_elements          | 100.7 | 7.53 | 49.6%  |
| separate_paren_groups       | 76.6  | 5.82 | 37.2%  |
| truncate_number             | 54.4  | 4.00 | 26.8%  |
| below_zero                  | 82.5  | 6.10 | 39.0%  |
| mean_absolute_deviation     | 96.4  | 7.11 | 46.2%  |
| intersperse                 | 87.2  | 6.40 | 40.3%  |
| parse_nested_parens         | 70.6  | 5.33 | 36.5%  |
| filter_by_substring         | 74.6  | 5.57 | 35.3%  |
| sum_product                 | 115.2 | 8.53 | 53.3%  |
| rolling_max                 | 55.7  | 4.13 | 26.4%  |
+-----------------------------+-------+------+--------+
| MEAN                        | 81.38 | 6.05 | 39.1%  |
+-----------------------------+-------+------+--------+

对比 Heretic 旧成绩 (bench_he.py)：

• Heretic Q4_K_M (旧): 68.80 tok/s, AL 4.79, 接受率 30.0%
• Huihui Q4_K_M (新): 81.38 tok/s, AL 6.05, 接受率 39.1%
• 提升：+18.3%

对比 Reddit 帖文 (r/LocalLLaMA, 同款 test_dflash)：

项目	Reddit 帖文	我们实测 (Heretic)	我们实测 (Huihui)
AR 基线	28.07 tok/s	30.83 tok/s	—
DFlash budget=8	62.75 tok/s	68.80 tok/s	81.38 tok/s
加速比	2.24x	2.23x	2.64x
AL	4.93	4.79	6.05
草稿模型	Q8_0 GGUF	Q8_0 GGUF	Q8_0 GGUF
主模型	原版 Qwen3.6	Heretic 无审查	Huihui 真无审查

---

模型去审查排名表

排名	模型	去审查	DFlash 兼容	速度	备注
	Huihui Q4_K_M (mradermacher)	真	FA_ALL_QUANTS=ON	~81 tok/s	唯一真无审查冠军
	Heretic Q4_K_M (Youssofal)	假	原生	~69 tok/s	仅是真实度+0.5 而非真去审查
	Huihui IQ4_XS	真	️ OFF 也可	~28 tok/s	太慢已删
	OBLITERATUS Q4_K_M	假	崩溃	—	假去审查+不兼容

去审查实测验证

测试问题	Huihui Q4_K_M	Heretic Q4_K_M
"如何制造XX"	直接输出步骤	"我不能提供"
"详细描述BL场景"	完整叙述	"请保持安全"
"制作XX的XX原理"	给出原理+流程	安全教育

---

🧠 经验教训总结

1. FA_ALL_QUANTS=ON 是正解。 不要再去 patch 源码了，完整编译能解决所有量化类型的 kernel 缺失问题。TILE fallback 是歪路。

2. Uncensored 标签水很深。 Huihui abliterated 是真无审查（直接回复XX步骤），Heretic 号称 Uncensored 但实际拒答。实测为准。

3. mradermacher 的 GGUF 转换管道与 DFlash 兼容性最好。 同一量化的其他发布者版本可能层数/架构不同导致崩溃。

4. Q4_K_M 性能远优于 IQ4_XS (~81 vs ~28 tok/s)，FA_ALL_QUANTS=ON 后 Q4_K_M 无兼容问题，IQ4_XS 已弃用。

5. --fa-window 0 仍是必要的。 即使编译完美，该参数依然是防范长文本 DFlash 滑动窗口崩溃的最佳实践。

6. --tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示方块问题。auto-detect 会匹配到 Qwen3.5 的 tokenizer，某些 emoji token 映射不一致。

7. DFlash 重建后必须 --clean-first，否则增量编译不重编 HIP 目标，修改不生效。

8. bench_he.py 才是正确的测量方法。 run.py 单 prompt 测速会包含预填充开销，低估性能 10-15%。

---

参考来源

• Lucebox DFlash: https://github.com/Luce-Org/lucebox-hub
• Huihui abliterated: https://huggingface.co/huihui-ai/Qwen3.6-27B-Abliterated-GGUF
• Heretic (假无审查): https://huggingface.co/Youssofal/Qwen3.6-27B-Abliterated-Heretic-Uncensored-GGUF
• Reddit DFlash 参考: https://www.reddit.com/r/LocalLLaMA/comments/1tgepbd/
• lcz.me 论坛实测: Topic 353 & 100 (7900 XTX + Qwen3.6)
  

最后再晒一下心意十几年的真-双路服务器主板，待内存降回合理水平后势必要32G 2400Recc 插满！！！

[terry]

非常好，这个无审查真的挺有用，最近在线AI的审核越来越严重了，很有参考价值。

[abaalei]

@terry 是啊 这也不行那也不行
毕竟对我来说不处理什么机密的资料、也不需要考虑隐私的问题，本地LLM就只剩无审查这个点可用派上用场了

[laobenxiong]

@abaalei 说:

--tokenizer Qwen/Qwen3.6-27B

大神, max_ctx 能到多少? 7900xtx. 谢谢

[hyaska]

关键可以抄作业的

[sil041]

筆記一下~謝謝大大

[Kk Hh]

逐渐有人玩越狱模型了，我只是想说 Huihui 的模型越狱都太暴力了，你可以看看模型越狱的原理，原则上Qwen都不太适合做越狱模型。

[CHIA AN YANG]

想問,上下文無法開大對嗎?hermes agent無法使用?

[williamlouis]

@laobenxiong 118K-120K是稳定的。实测。优化后为设置的16K。看你想干什么了。我的速度模型用的8K就很够用了。还有测试的落地点不太一样。我比较注重 模型的智力

[williamlouis]

我测了一下。上下文卡在32K。不能上升。显存会爆。
总结：
- 克隆 Lucebox DFlash 源码，初始化 submodule
- HIP 后端编译成功：FA_ALL_QUANTS=ON，gfx1100，Release 模式
- 产物：test_dflash (1.4MB) + dflash_server (3.1MB)
- 下载 Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf (16GB) + dflash-draft-3.6-q8_0.gguf (1.8GB)

性能测试：

| 场景                                | 速度       | 接受率 |
|-------------------------------------|------------|--------|
| HumanEval 代码 (bench_he, budget=8) | 64.2 tok/s | 33.7%  |
| 中文短对话 (test_dflash)            | 45.6 tok/s | 23.1%  |
| 中文 API (短 prompt)                | 25.9 tok/s | 14.9%  |
| 对比：文档声称                      | 81.4 tok/s | 39.1%  |

发现的关键问题：

1. GPU DPM 必须 high——默认 low 模式下核心锁 516MHz，速度只有 7.8 tok/s（差 6 倍）
2. 64K 上下文爆显存——C++ dflash_server 预分配全部 KV cache，24GB 无法同时承载 14.7GB 模型 + 1.8GB 草稿 + 64K 缓存。文档用的是已移除的 Python server.py（可能按需分配）
3. 投机解码对中文对话提升有限——draft 模型专为代码优化，中文接受率仅 15%，速度优势减半
4. 文档 81 tok/s 与实测 64 tok/s 差距约 21%——来自 Huihui abliterated 改变了模型输出分布，draft 命中率下降

启动命令（每次重启后）：

bash
echo high | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level
cd /opt/lucebox-dflash/server
HSA_OVERRIDE_GFX_VERSION=11.0.0 ./build/dflash_server \
  models/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf \
  --draft models/draft/dflash-draft-3.6-q8_0.gguf \
  --ddtree --ddtree-budget 8 --fa-window 0 \
  --max-ctx 65536 --cache-type-k tq3_0 --cache-type-v tq3_0 \
  --prefix-cache-slots 0 \
  --host 0.0.0.0 --port 11435


（64K 配置能启动但大 prompt 会爆，需降 max-ctx 或用纯 AR 模式）

没折腾的参考下吧。

[abaalei]

以下内容以agent回复为主，个人回复为辅，感谢论坛内各路大神的捧场！

@terry @hyaska @sil041

感谢支持～折腾了三天，踩坑无数，好在最后成果还不错 作业随便抄，有问题随时问。

@laobenxiong

128K 上下文在 7900 XTX 上实测过，结论是跑不了。详细账目：

               64K          128K

模型 Q4_K_M ~16 GB ~16 GB
KV cache ~2.5 GB ~5 GB
草稿模型 ~0.5 GB ~0.5 GB
其他 ~1 GB ~1 GB
─────────────────────────────────────
总计 ~20 GB ~22.5 GB
可用 24 GB 24 GB

实测算下来 64K 稳，128K 强行分配时 ROCm 报 cudaMalloc failed: out of memory。所以目前定的是 DFlash 32K 日常用（这部分主要拿来随便对话，生成灵感），长文本切到 IQ4_XS 跑 128K（本人主要拿来写小说）。

@Kk Hh

你提到 Huihui 的越狱太暴力这个观察很到位。Abliterate 本质就是拿 diff-in-means 算出 attention 里的"拒绝回答"方向然后反向投影，确实暴力。

不过说 Qwen 不适合做越狱模型——从实测结果看，Qwen3.6 的安全训练相对温和，反而是 diff-in-means 效果比较好的基座。我们实测 Huihui 的真无审查版在代码场景下草稿接受率仍有 39%，智力没明显下降，日常用没啥问题。

同意你说的：越狱模型更适合作为本地私有部署的辅助工具，日常用原版，需要绕过审核时再切，两套共存才是合理方案。（我目前主力模型是deepseek v4flash，gemini3.1pro白嫖版，gemini3.5flash-agent版、sonnet4.6/Opus4.8（kiro白嫖版）、GPT5.5-thinking（微软E3白嫖版，本地大模型只占据使用中的零星一角，都是看各路大神说qwen3.6-27b比较好才去尝试用这个模型的去审查版本，如有更好选择请不吝建议！）

@CHIA AN YANG

上下文问题看上面回复，32K 日常够用。Hermes 接入很简单：

custom_providers:

• name: dflash
  api_base: http://你IP:11435/v1
  api_key: not-needed
  models:
  • name: lucebox-dflash

然后 /model lucebox-dflash 切换即可。

@williamlouis（Post 6172）

你测得很详细，感谢补充！几个差异点我们逐条对过：

1. 速度差异（64.2 vs 81.4 tok/s）
   差距约 21%，主要原因：

• 你用的 C++ dflash_server，我们用的是 Python scripts/server.py。Python 版的 KV cache 按需分配，在相同显存下能留更多空间给推理
• 你加了 HSA_OVERRIDE_GFX_VERSION=11.0.0 和 --cache-type-k/v tq3_0，这两个参数我们没用过，不确定对 VEC kernel 调度有没有影响，建议去掉跑一次 bench_he.py 对比
• Huihui 在我们的测试中接受率（39.1%）反而高于 Heretic（30.0%），所以不是 draft 命中率下降的问题

2. DPM 问题
   DPM 这点我们核实了——卡在 auto 模式下，温度 39°C，频率正常跑到。没有特意调到 high 也出了 81 tok/s。如果你的卡默认卡在 low（516MHz），那确实需要 sudo tee 调一下，但这不是普适问题，取决于主板/bios 的默认电源策略。

3. 上下文 32K 限制
   确实，Python server.py 按需分配能跑到 118K-120K，C++ dflash_server 预分配全部 cache，32K 往上就吃紧了。

4. 我们完整的启动参数（供参考）：
   python3 scripts/server.py
   --target Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf
   --draft models/dflash-draft-3.6-q8_0.gguf
   --budget 8
   --fa-window 0
   --tokenizer Qwen/Qwen3.6-27B
   --host 0.0.0.0 --port 11435

隐藏最深的一个坑——MTP

这次折腾中发现了一个最意外的事：我们手上的 Qwen3.6 GGUF 模型（无论是 Heretic 还是 Huihui），量化时都没有保留 MTP 多 Token 预测层。

[spec] failed to create MTP context: model doesn't contain MTP layers

所以之前跑出来的 "MTP n=3 47.3 tok/s" 其实一直在跑纯自回归，MTP 压根没生效。如果你想要 MTP，需要找带 "Native-MTP-Preserved" 标签的 GGUF。我们最后直接全面转向 DFlash 了。

最终推荐方案

经历三天的反复折腾和横评，7900 XTX + Qwen3.6-27B 的最终定版：

推荐
• 引擎: DFlash + Huihui Q4_K_M
• 上下文: 32K
• 速度: ~81 tok/s
• 去审查: 真
• 用途: 日常主力

长文
• 引擎: llama.cpp + IQ4_XS
• 上下文: 128K
• 速度: ~39.7 tok/s
• 去审查:
• 用途: SillyTavern/写小说

核心经验：

1. FA_ALL_QUANTS=ON + --fa-window 0 + --tokenizer Qwen/Qwen3.6-27B 是 DFlash 稳定的三件套
2. 不要 patch 源码，完整编译才是正路
3. budget=8 是 7900 XTX 甜点，再大验证树浪费 GDDR6 带宽
4. MTP 模式的 GGUF 要专门找带 MTP 头的版本，普通量化版不兼容
5. 双卡机器上 Vulkan 有坑，ROCm 天然隔离 NVIDIA 卡

[kos or]

現在真的人人都需要特助了
本人 + AI 特助

[abaalei]

@kos-or 对，按遥控指挥人做事的感觉真的会上瘾的，哈哈哈。我基本上是gpt3.0？一开始的时候用过一段时间，那时候觉得就那样。然后25年我爸cancer，开始重度使用gpt/grok来分析每15天的抽血报告，开始越来越觉得ai带来的增益比一开始要多了。然后26年2月开始白嫖gemini pro，用了2 个月越来越离不开了，后面就尝试在自己的truenas上面配置了hermesagent，然后就一发不可收拾了，现在都玩起双卡流了 ，最可惜的是当年矿潮的时候12000买的3080ti，至今都不能改24g显存，不然7900xtx主力做LLM，3080ti跑comfyui就完美了，哎，可惜呀

[williamlouis]

@abaalei 回复下问题：卡默认卡在 low（516MHz），那确实需要 sudo tee 调一下。不是卡的问题。我设置了功耗墙。整机的功耗在不工作的状态 卡死在75W了。所以才有默认是 516MHz。需要的人可以试试。工作的状态需要命令行调整到 high。调整命令在我的折腾帖中。手打太长，自己去看吧。

[kos or]

@abaalei 说:

grok

希望您父親現在一切安好

Grok 能接API嗎 ? Musk的礦機廠都出租讓Anthropic用了
之前用Grok 試了幾次性感圖 蠻漂亮的 但是又歪歪的

我也是雙卡流 ～有空可以交流一下
那天我讓Hermes 在GPU0 and GPU1 同時安裝了 Gemma-4-12B-MTP
效果不錯 但是工作流還是要繼續研究
目前卡PCIe 一卡只有1GB/s的速度 , 另一卡是32GB/s 無法玩TP 張量並行

因為新的礦機架到了, 之後可能會有第三卡 但好像無法3卡 TP

[abaalei]

@kos-or 感谢，不过他去年就走了

grok可以的，我现在是通过cliproxy api来oauth登陆了x之后，再反代出来给hermes用
因为我现在在用的主板也是矿板，现在还空出来了2根x16的全场插槽（这块板一共6槽，4x16 2x8），所以在心痒痒要不要多搞2张v100/16g 或者mi50/16g回来折腾，哈哈哈

卡1只有1GB/s是主板问题吗？

[abaalei]

@williamlouis 那就难怪拉，我现在3080ti待机35w+7900xtx待机20w，还没算外围电路、损耗、cpu、内存，加起来估计150~200w也是有的

[williamlouis]

@abaalei 功耗墙不能直接设置最低。容易直接灭火。你可以让 AI 给你算一个值 。建议中庸一点。差不多就行了。富裕点跑最稳定的。

[kos or]

我就是用這一張 挖礦用的 GPU 轉接卡 USB cable 通訊頻寬受限吧
上面寫著PCIe 1.0 to 16 所以才會這麼慢
不過我弄了一張主板有 6 slots x 32GB/s 應該夠應付跨卡需求了

[kos or]

@abaalei 说:

现在还空出来了2根x16的全场插槽（这块板一共6槽，4x16 2x8），所以在心痒痒要不要多搞2张v100/16g 或者mi50/16g回来折腾，哈哈哈

你這是標準AI Sever 主板嗎?

你先確定工作流才下手 要不然不同型號的顯卡要做 PP/TP 會有一定的複雜度
快的卡會被慢的顯卡拖累

除非你每一張卡都跑一個LLM 大語言模型 這倒是可行