【2026 最新】Hy4 Preview 本機怎麼跑？先算 214 GiB：GGUF、API 與量化品質決策教學

Hy4 Preview 本機部署最容易踩的坑，是把「每個 token 啟用 49B 參數」誤讀成「只要載入 49B」。實際上，路由器下一步可能選到不同專家，770B backbone 的權重仍要放在磁碟，推論時也得由 RAM／VRAM 承接；目前最小的 Hy4 preview GGUF 仍有 213.66 GiB。

這篇不會催你先下載 200 多 GiB。你會先算磁碟、可用記憶體與 KV Cache，再從 API、CPU／GPU partial offload（部分層放顯卡）和多 GPU 全駐留三條路選一條；真的要跑本機，才進入版本鎖定、patch、checksum、chat template 與固定 10 題驗收。本文核對的是 2026 年 8 月 31 日可見版本，不把社群的「98%」標題當成普遍品質保證。

Hy4 Preview 本機先說結論：49B active 不等於 49B resident

• 一般 24GB、48GB 顯卡先走 API。即使選最小 STQ1_0，213.66 GiB 也遠超單卡容量；把剩餘權重丟給一般桌機 RAM，能載入不代表會有可接受速度。
• 要保守比較量化品質，Q4_K_M 才是起點。它有 435.20 GiB，製作者稱之為較安全的 4-bit 預設；STQ1_0 是把 routed expert 混合壓到約 2.38 bpw 的激進版本，不是「Q4 只剩 214 GiB」。
• 容量公式先記住：權重常駐空間＋KV Cache＋runtime／系統餘量。模型設定的 1,048,576 token 上限，不代表你的機器能用同樣長度啟動。
• 「98%」不能替你的工作負載作答。程式、中文長文、工具呼叫與事實問答的失敗型態不同；同一批固定題目、同一 sampling、盲評與失敗紀錄，才是可用的比較。

本機容量 ＝ 全部權重＋KV Cache＋runtime 餘量；active 是每步計算量，不是 resident 權重大小。

770B、49B、BF16、Q4_K_M、STQ1_0 到底差在哪？

Tencent 官方模型卡把 backbone 寫成 770B total、每 token 啟用 49B；另有一層原生 MTP，約 10B total、0.7B active。backbone 共 78 層：第一層是 dense FFN，後面 77 層是 MoE（Mixture of Experts，混合專家），每層有 256 個 routed experts、1 個 shared expert，每步選 8 個 routed experts。

因此「49B active」描述的是一次前向計算會動用多少參數，類似圖書館員每次從少數書架取書；「resident」則問整座館藏放在哪裡。因為下一個 token 可能路由到另一組專家，沒有被這一步選到的權重不能直接刪掉。這也是為什麼 Hy4 preview 發布解析談到的算力節省，不能直接換算成單張消費卡的容量。

BF16 與官方 MXFP8：仍是資料中心等級

本文依 Hugging Face 指定 revision 加總檔案：base checkpoint 的 131 個 safetensors 共 1,559,983,809,380 bytes，也就是 1,452.85 GiB；它以 BF16 為主，但不是每個 tensor 都是 BF16。Tencent 另有以 ModelOpt 產生的官方 MXFP8 checkpoint，共 757.88 GiB。兩者都不是一般桌機「下載後雙擊」的規模，官方 vLLM 配方與 SGLang 配方也以多 GPU 部署為主。

Q4_K_M 與 STQ1_0：兩個不同的品質賭注

AngelSlim 的 GGUF 說明列出兩個單檔產物。Q4_K_M 是 435.20 GiB、平均 4.86 bpw，主要 tensor 採 Q4_K，部分 ffn_down_exps提高到 Q6_K；STQ1_0 是 213.66 GiB、平均 2.38 bpw，只有部分 routed-expert gate／up tensor 用 1.3125 bpw 的稀疏三值格式，另一些層用 IQ2_XXS，其他敏感 tensor 保留更高精度。轉換 patch 會略過原始 MTP layer，因此這兩個 GGUF 不能使用原模型的 MTP speculative decoding。

所以 STQ1_0 不是整顆模型都變成純 1-bit，也不是 Q4_K_M 的另一個檔名。若你還不熟 bpw、K-quant 與品質懸崖，先讀 GGUF 量化選擇教學；這篇只處理 Hy4 preview 的具體決策。

Hy4 Preview 本機第 1 步：下載前做三個停損檢查

① 磁碟夠嗎？先看可用空間，不看標稱容量

痛點是「2TB SSD 看起來很大，為什麼還會失敗？」解法是先保留模型檔之外的建置、下載暫存與更新空間。在預定的本機磁碟執行 df -h .；STQ1_0 至少先空出約 250 GiB，Q4_K_M 至少約 500 GiB。這是實務停損線，不是 runtime 的固定硬需求。不要把 GGUF 放在網路磁碟；製作者特別提醒 llama.cpp 會 mmap 權重，遠端隨機讀取可能把載入拖得很慢。

② RAM＋VRAM 夠嗎？先分「能載」與「值得等」

痛點是只拿 GPU 型號對照模型大小。解法是先按 offload placement 分別檢查 RAM 與 VRAM，再用 GPU-resident 比例判斷速度風險。STQ1_0 權重本身就約 214 GiB，Q4 約 435 GiB；還沒算 KV Cache、運算 buffer、CUDA context 與作業系統。RAM 與 VRAM 不是能任意相加的一池，-ngl與 tensor placement 會決定各自負擔。若安排後任一側放不下就停止；若放得下但大部分權重落在一般 CPU RAM，結果是「可能啟動」，不是「互動速度一定可用」。需要先建立通用估算框架，可搭配 本機 LLM 顯存決策樹。

③ Context 要多長？1M 是上限，不是免費額度

痛點是看到 config 的 max_position_embeddings=1048576，就把 -c設成 1M。解法是從 8K context 啟動，再根據實際 buffer log 增加。SGLang 的 BF16 配方以 Hy4 的壓縮 KV 與 indexer cache 估算約 95 KB／token：8K 約 0.76 GB、32K 約 3.04 GB、128K 約 12.16 GB、1M 約 95 GB；patched llama.cpp 的 cache dtype 與 buffer 實作未必相同，啟動 log 才是本機答案。

三條部署路線：API、partial offload、或多 GPU 全駐留

路線 A：先用 API 建立品質基準

如果你只有 24GB／48GB GPU、沒有 256 GiB 以上可用系統記憶體，API 是成本最低的止損點。Tencent 的 Hy4 preview API 文件提供 OpenAI-compatible 介面；先以同一個 system prompt、固定 temperature、固定輸出上限跑完 10 題，把原始 JSON、延遲與錯誤保存。這一步回答「模型值不值得進一步部署」，不需要先承擔數百 GiB 下載。

路線 B：CPU／GPU partial offload 驗證相容性

如果按 placement 分配後 RAM 與 VRAM 都能容納各自的權重與餘量，但 VRAM 不足全駐留，可以降低 llama.cpp 的 -ngl，讓部分 layers 留在 CPU。它適合驗證檔案、template 與輸出是否正確，也能量到你自己的速度；但不要只用「成功產生第一個 token」宣稱部署完成。至少記錄冷啟動時間、prompt processing、decode tokens/s、峰值 RAM／VRAM，以及 10 題總耗時，才能判斷是否有日常價值。

路線 C：多 GPU 全駐留做可用服務

只有當多張 GPU 的可用 VRAM 在加總後覆蓋權重、KV Cache 與 buffer，才進入全駐留路線。STQ1_0 的約 214 GiB 和 Q4 的約 435 GiB 都只是權重下限；還要確認每張卡拓撲、runtime 分片方式與 context 目標。若你的目的是真正提供多人 API，而不是研究 GGUF，優先評估 Tencent 已文件化的 vLLM／SGLang MXFP8 路線；GGUF 的價值在異質硬體與 CPU／GPU 混合，不等於它必然是資料中心吞吐量最高的選擇。

Hy4 Preview 本機第 2 步：鎖定 patched llama.cpp 再下載

截至 2026 年 8 月 31 日，AngelSlim GGUF revision fd6c6d58c8cd1c31f922972f700804ce717ea94f明確要求 patched llama.cpp；我們也核對當日 upstream main commit 9723942adc518b43c4b95dc4dce6906903eb5e09，tree 內尚無 HYV4／STQ1_0 支援，而 STQ1_0 PR #22836仍是 Open。這是日期與 commit 有界的狀態，不代表未來版本永遠不能跑。

GGUF 製作者鎖定 llama.cpp commit 0cea36222fe9bac5ebfc45716c9eef11f37046c4。以下先下載兩個 patch、用 git apply --check預檢，再套用；只跑 Q4_K_M 可以略過第二個 STQ patch。本文在該 base commit 依序做過兩份 patch 的 dry check，均能乾淨套用，但沒有下載 214／435 GiB 權重，也沒有把「patch 可套用」寫成「完整推論已重現」。

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout --detach 0cea36222fe9bac5ebfc45716c9eef11f37046c4

curl -fL -o 0001-hyv4-architecture.patch \
  https://huggingface.co/AngelSlim/Hy4-preview-GGUF/resolve/fd6c6d58c8cd1c31f922972f700804ce717ea94f/hy4-preview-patch/0001-hyv4-architecture.patch
curl -fL -o 0002-stq1_0-quant-and-cuda.patch \
  https://huggingface.co/AngelSlim/Hy4-preview-GGUF/resolve/fd6c6d58c8cd1c31f922972f700804ce717ea94f/hy4-preview-patch/0002-stq1_0-quant-and-cuda.patch

git apply --check 0001-hyv4-architecture.patch
git apply 0001-hyv4-architecture.patch
git apply --check 0002-stq1_0-quant-and-cuda.patch
git apply 0002-stq1_0-quant-and-cuda.patch

CUDA build 的 CMAKE_CUDA_ARCHITECTURES必須對應你的 GPU；AngelSlim 範例中的 90是 H20／H100，不可照抄到所有顯卡。先查 NVIDIA 的 compute capability，再把下方 HY4_CUDA_ARCH換成正確值。作者公開展示的環境只有 Linux、CUDA 13、8×H20 全駐留；這不等於 Metal、AMD、Windows 或純 CPU 已有相同可用性。

export HY4_CUDA_ARCH="90"  # 只適用 H20／H100；其他 GPU 必須更換

cmake -B build-cuda \
  -DGGML_CUDA=ON -DLLAMA_CURL=OFF -DGGML_NATIVE=OFF \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CUDA_ARCHITECTURES="$HY4_CUDA_ARCH" \
  -DLLAMA_BUILD_UI=OFF -DLLAMA_USE_PREBUILT_UI=OFF

cmake --build build-cuda --target llama-cli llama-bench -j 8

若你只是在選模型而非研究 runtime，這裡任何 patch 或編譯錯誤都是回到 API 的合理停損點，不是必須硬解的考題。Q4 只需 HYV4 architecture patch；STQ 才需要兩份 patch。

Hy4 Preview 本機第 3 步：單檔下載、checksum 與啟動

不要把整個 GGUF repo 全抓下來；Q4 與 STQ 加總接近 649 GiB。Hugging Face 官方 CLI 支援指定單一檔案，先在本機磁碟建立專用目錄。下面示範 STQ1_0；要保守品質基準，就把檔名與 checksum 換成 Q4_K_M。

python3 -m pip install --upgrade huggingface_hub
export HY4_MODEL_DIR="/your/local-ssd/hy4-preview"
mkdir -p "$HY4_MODEL_DIR"

hf download AngelSlim/Hy4-preview-GGUF \
  Hy4-preview-STQ1_0.gguf \
  --revision fd6c6d58c8cd1c31f922972f700804ce717ea94f \
  --local-dir "$HY4_MODEL_DIR"

shasum -a 256 "$HY4_MODEL_DIR/Hy4-preview-STQ1_0.gguf"

不可變 LFS pointer 記錄的 content SHA-256：STQ1_0 應為 4d1d2259446e33e25c3e1d8bcb072f026cc69b90a361c5e5a8f6eca50d8d0036；Q4_K_M 應為 58d0703ef860841dd9b605bfe567af89b62fc7bc367cd57303fc742c6386fffb。製作者沒有另附 checksum manifest；本文以 revision 鎖定的 LFS OID 驗檔。結果不一致就停止，不要拿疑似截斷檔繼續測。若是需要離線備份與重抓策略，可延伸讀 Hugging Face 離線備份教學。

啟動先用 8K context、固定 temperature 與短輸出，並保留 --jinja。GGUF 內嵌 template 使用 :6124c78e特殊 token，公開 base checkpoint 則使用 :opensource；兩者內容與 reasoning modes 也不同。不要手動從 base repo 複製 template 蓋掉它，也不要因內嵌 template 有 vision 分支就宣稱 GGUF 已具備可用視覺輸入。-ngl是最多放進 GPU 的 layers 數，從能穩定載入的值開始，觀察實際記憶體 log 再調整。

./build-cuda/bin/llama-cli \
  -m "$HY4_MODEL_DIR/Hy4-preview-STQ1_0.gguf" \
  -ngl 20 -c 8192 --temp 0 -n 512 \
  --no-warmup --jinja -st -f prompt.txt

如果 error 提到未知 architecture、未知 quant type 或 template，先核對四件事：llama.cpp 是否真的停在指定 commit、兩個 patch 是否按順序套用、binary 是否由該 worktree 重建、GGUF checksum 是否一致。若只是 out of memory，降低 -ngl或 -c；若能載入但慢到無法使用，這就是 partial offload 路線的有效實驗結果。

「保留約 98%」怎麼驗？用固定 10 題，不用一個平均數

Reddit 標題把 STQ1_0 描述成「約 98% 表現」，但 AngelSlim GGUF card 沒有提供一個涵蓋所有任務、API、Q4、STQ 的對等整體 benchmark。Tencent 公開圖只列六個所選 benchmark 的 BF16→STQ 分數，顯示差距 0.2～2.4 分；不同量尺的比值不能直接變成「你的中文工作流保留 98%」。這批第一方結果也未附逐題輸出、eval revision 與可重跑紀錄。正確問題不是少了幾個百分點，而是哪一種錯誤會讓你的任務不能交付。

建立一份不含答案提示的 10 題集：中文長文 2 題、程式修改 2 題、工具／JSON schema 2 題、長 context 擷取 2 題、你自己的高價值任務 2 題。API、Q4_K_M、STQ1_0 三組都用同一 system prompt、temperature=0、相同 max tokens；隨機化輸出標籤後，由不知道版本的人依「正確、格式遵循、關鍵遺漏、不可恢復失敗」評分。這是 本機 LLM A/B Test的縮小版。

每組至少保存四類可觀察結果

• 品質：10 題逐題 pass／partial／fail，不只留總平均；把 JSON 破格式、漏引用、程式不可執行列成獨立失敗。
• 速度：首 token 延遲、prompt processing、decode tokens/s 和整批完成時間；不要把 prompt throughput 當 decode 體感。
• 資源：峰值 RAM、每張 GPU 峰值 VRAM、context 長度、-ngl與 runtime commit。
• 失敗：OOM、載入錯誤、template 異常、無限續寫、schema 破壞與 timeout，連零分樣本一起保存。

決策規則要在跑測試前寫：例如「任一工具呼叫題出現不可解析 JSON 就淘汰」、「STQ 若節省的硬體能讓整批時限達標，且沒有新增 critical fail，才接受」。這樣你比較的是可部署性，不是跑完後替喜歡的版本找理由。需要把服務端引擎差異納入，可再看 LLM inference engine 選擇指南。

常見失敗：看到哪一行就回哪一關

• 下載前就沒有 250／500 GiB 可用本機 SSD：停，不下載；先走 API。
• 依 placement 分配後，任一側放不下權重、KV 與餘量：停，不靠 swap 假裝成功；縮短 context 只會減 KV，不會把 214 GiB 權重變小。
• unknown model architecture：回到 pinned commit 與第一份 HYV4 patch。
• unknown quant type：STQ 路線回查第二份 patch 與重建 binary；Q4 不需該 patch。
• 輸出角色、特殊 token 或工具格式怪異：確認有 --jinja且使用 GGUF 內嵌 template，不要混用 base template。
• 能跑但互動太慢：這不是「再調一個 flag」必然能救；記下可重跑數據，改用 API 或提高 GPU-resident 比例。

Hy4 Preview 本機部署，誰適合真的下載？

適合：你有 256 GiB 以上可用記憶體與本機高速 SSD，願意接受 partial offload 的不確定速度；或有數百 GiB 多 GPU VRAM，目的是研究量化、離線性、資料控制與 runtime。你也已經有一批自己的驗收題，知道省下容量後不能犧牲哪種錯誤。

不適合：你只有一般 24GB GPU，只想試聊天品質；或還沒證明 Hy4 比現有 API／較小本機模型更適合任務。此時最好的「本機部署」決策，是不下載：先用 API 跑固定 10 題，拿到品質基準，再決定是否值得搬動 214 GiB 以上權重。