Zinc 是什麼？它是 Zig for AMD 和 Apple 系統中的 LLM 推理引擎。

Zinc 是一款大型語言模型 (LLM) 的本地推理引擎，旨在充分利用 AMD 的消費級 GPU（RDNA3 和 RDNA4）以及 Apple Silicon 晶片的性能，它使用 Zig 作為程式語言，Vulkan/Metal 作為圖形後端。如果您擁有現代顯示卡，卻苦於 vLLM、ROCm 或其他優化不佳的解決方案無法有效利用，那麼 Zinc 正是為此而生。

Zinc 的目標非常明確：提供一種簡單、快速且無需依賴項的方式，讓使用者能夠在本機上運行 GGUF 模型。只需一次構建，生成一個二進位文件，並配備一個兼容 OpenAI API 且集成了瀏覽器聊天介面的伺服器。所有這些都得益於為每個平台精心打造的著色器、底層設計以及專為開發者和高級用戶量身定制的用戶體驗。

Zinc（Zig推理引擎）是什麼？它解決了什麼問題？

Zinc 是一款 LLM 推理引擎，主要使用 Zig 編寫，從一開始就旨在充分利用兩大應用廣泛但傳統上未被充分利用的 GPU 系列的硬體性能：AMD 基於 RDNA3/RDNA4 的消費級 GPU 和 Apple Silicon SoC（M1、M2、M3、M4、M5）。它不依賴 ROCm、CUDA 或 MLX，而是基於 Linux 上的 Vulkan 1.3 和 macOS 上的 Metal。

這個專案源自於社群中反覆出現的抱怨：擁有強大 AMD 顯示卡的使用者發現 ROCm 對消費級顯示卡的支援不佳，vLLM 沒有 ROCm 就無法運作，而 llama.cpp 的 Vulkan 方案將 GPU 視為次要角色，使用通用著色器，沒有針對架構進行專門調整，也沒有可靠的伺服器歷史記錄。

Zinc 的前提是硬體已經準備就緒：RDNA3 和 RDNA4 架構的記憶體、運算能力和顯存頻寬都足以運行大型模型，而 Apple Silicon 晶片則具備統一記憶體和強大的運算單元。真正的瓶頸在於軟體，因此 Zinc 為這些平台專門開發了一個引擎，並採用了非常底層的系統方法。

實際上，Zinc 現在能夠加載大型 GGUF 模型（對於 35B 參數模型，大約需要 21 GB 的 VRAM 權重），構建具有數百個節點的計算圖（例如，具有 MoE 和 SSM 層的混合 Transformer），並以具有競爭力的速度生成連貫的文本，尤其是在經過硬體調整的 RDNA4 硬體上。

為什麼選擇 Zig 來創建 Zinc？

Zig 非常適合基於 Vulkan 和 Metal 的 GPU 推理引擎所需的工作：頻繁調用圖形 API、手動管理 GPU 記憶體、記錄命令緩衝區以及整合著色器建立管線。它是純粹的系統程式碼，而 Zig 提供了一套完美契合這種需求的工具集。

`@cImport` 是 Vulkan 的關鍵特性，它允許直接存取 Vulkan 的 C ABI，而無需產生複雜的綁定或額外的層。這使得調用底層 API 函數變得非常容易，可以完全按照定義調用，從而減少與驅動程式和圖形運行時互動時的摩擦和開銷。

在 Zig 中使用編譯時對於按量化類型生成分派表以及在編譯時專門化程式碼路徑非常有用，這可以減少運行時分支，並根據加載的 GGUF 模型更有效地選擇內核和格式，例如 Q4_K、Q5_K、Q6_K、Q8_0 或 F16。

使用 errdefer 進行錯誤和資源管理有助於控制 GPU 資源清理：即使出現中間錯誤，緩衝區、映像、描述符和其他 Vulkan/Metal 物件也會被正確釋放，從而防止在初始化或解碼循環中發生故障後出現 VRAM 洩漏和不一致狀態。

Zig 自帶的建置系統極大地簡化了著色器編譯整合：`zig build` 命令可以將多個步驟串聯起來，在 Linux 系統上呼叫 glslc，將已編譯的 SPIR-V 著色器放置在 `zig-out/share/zinc/shaders/` 目錄下，並在 `zig-out/bin/zig` 下一個目錄的一個包含二進位目錄。在 macOS 系統上，Metal (MSL) 著色器在執行時編譯。

通用架構：AMD 採用 Vulkan，蘋果晶片採用 Metal

Zinc 設計了兩條不同的執行路徑，一條適用於使用 Vulkan 1.3 的 Linux 系統和 AMD GPU，另一條適用於使用 Metal 的 macOS 系統和 Apple Silicon。雖然從使用者的角度來看，體驗幾乎相同：建立二進位文件，選擇一個經過驗證的 GGUF 模型，然後透過 CLI、HTTP 伺服器或 Web 聊天介面啟動推理。

AMD方案充分利用了RDNA3和RDNA4架構的強大功能：它採用手工編寫的GLSL運算著色器，結合Wave64、協作矩陣和架構專屬的平鋪策略，並在Vulkan環境下運作。這並非「也適用於AMD」的通用後端，而是專門針對硬體優化的核心。

在 Apple Silicon 上，Zinc 使用 Metal (MSL) 中的原生著色器和 simdgroup 操作，利用統一記憶體和零拷貝 mmap 直接載入模型，無需耗費資源的中間複製步驟。這與 Apple 的 SoC 理念非常契合，即 CPU 和 GPU 共享相同記憶體空間。

後端選擇在編譯時自動完成：Zig 會偵測建置環境是支援 Vulkan 的 Linux 環境還是支援 Metal 的 macOS，並啟動對應的路徑。從建置指令的角度來看，使用者只需執行 `zig build -Doptimize=ReleaseFast` 即可取得適用於其平台的二進位檔案。

這種設計避免了對特定驅動程式堆疊（例如 ROCm 或 MLX）以及執行時間環境（例如 CUDA 或 Python）的依賴。 Zinc 的設計理念是“一個獨立的二進製文件，無需重量級的機器學習棧”，這對於那些希望在台式機或筆記本電腦上構建本地 LLM 伺服器而無需進行複雜安裝的用戶來說尤其具有吸引力。

支援的平台、GPU 和型號

Zinc 目前主要關注兩大環境：基於 Vulkan 1.3 的 Linux 系統（支援 AMD RDNA3/RDNA4 GPU）和基於 Metal 的 macOS 系統（支援 M1 至 M5 的 Apple Silicon 晶片）。這涵蓋了獨立桌面顯示卡和以 AI 為導向的顯示卡（例如 Radeon AI PRO），以及 Apple 筆記型電腦和桌上型電腦中的整合式顯示卡。

在 Linux 系統上，已驗證 Zinc 相容AMD Radeon AI PRO R9700 (RDNA4，32 GB) 和 RX 7900 XTX 等 RDNA3 顯示卡。對於 RDNA4 顯示卡，建議在執行 Zinc 之前使用環境變數 RADV_PERFTEST=coop_matrix 啟用協同矩陣最佳化，因為這可以提高 RADV 驅動程式的運算效率。

在 macOS 系統上，Zinc 運行於 Apple Silicon 晶片之上，從早期的 M1 到最近的 M4 及後續型號均支持，並使用 Metal 作為後端和自定義的 MSL 著色器。例如，它已在配備 32GB 統一記憶體的 M1 Pro 上進行過測試，足以運行擁有數十億個參數的模型，也適用於某些具有特定記憶體需求的 35GB 版本。

在模型方面，Zinc 僅使用一組經過端對端驗證的特定 GGUF 模型，而非列出龐大的理論模型目錄。這些模型包括具有 2 億和 35 億參數的 Qwen3.5 變體，以及 Q4_K_M 或 Q4_K_XL 等量化方案，旨在平衡顯存消耗和推理表現。

支援的量化格式包括Q4_K、Q5_K、Q6_K、Q8_0 和 F16，可根據可用硬體進行品質和速度調整。例如，在目前的基準測試中，Qwen3.5 2B Q4_K_M 型號在 RDNA4 架構上單流解碼速度約為 27 tok/s，在 Apple Silicon 架構上約為 17 tok/s。

當前績效和專案狀態

Zinc 目前仍處於實驗階段，仍在積極開發中，但其效能已相當出色，並擁有穩定的 CLI 和 HTTP 伺服器推理流程。在配備 Radeon AI PRO R9700（RDNA4 架構，32 GB 顯存，576 GB/s 頻寬）的測試環境中，對量化為 Q4_K_XL 的 Qwen3.5 35B-A3B UD 模型進行了測試，速度約為 38 tok/s。

在簡單的命令列解碼測試中，一個典型的例子是發出類似「法國的首都是」這樣的簡短提示，並產生 128 個令牌。在這些條件下，在 35B 模型中觀察到接近 37,95 tok/s 的速率（每個令牌的延遲約為 26,3 ms），而在同一個 RDNA4 節點上的 2B Q4_K_M 模型中觀察到約為 26,71 tok/s（每個令牌的延遲約為 37,4 ms）。

值得注意的是，35B 模型在此硬體上的效能優於 2B 模型，這表明瓶頸並非僅在於參數數量，而是曲線形狀、所用核心類型以及解碼路徑的效率。該引擎在完整令牌路徑上實現了約 112,5 GB/s 的建模頻寬，約為晶片理論峰值的 19,5%。

這種看似「記憶體利用不足」的現象本身並不是問題，因為單一解碼流的設計目的並非完全佔用DRAM頻寬。剩餘的時間用於處理中小型內核，以及計算圖的更深層。為了提高整體利用率，正確的做法並非要求單一流完成所有任務，而是實現批次和並發。

與其他引擎（例如 llama.cpp）相比，Zinc 目前在 RDNA4 架構上針對 35B 模型和基本解碼的基準速度約為 40 tok/s，而 llama.cpp 在相同的節點和模型上可以超過 100 tok/s。 Zinc 的路線圖包括透過優化熱點核心、降低 Vulkan 開銷以及改進推理聊天路由（/v1/chat/completions）來縮小這一差距，使其效能更接近純解碼路由。

優化的內部結構和著色器

Zinc 引擎由幾個已完成的基本建置模組組成：Vulkan 基礎架構、GGUF 解析器和模型載入器、RDNA3/RDNA4 GPU 偵測、原生 BPE 分詞器（來自 GGUF 元資料）、一組 16 個 GLSL 計算著色器、計算圖建構器和架構，以及用於解碼的前向傳遞循環。

AMD 的著色器是專門為 RDNA 架構編寫的，採用 wave64、協作矩陣和分塊方案，並針對此架構的記憶體層次結構和運算單元進行了最佳化。這與通用解決方案截然不同，通用解決方案通常使用相同的著色器處理所有任務，導致效能遠低於顯示卡的潛力。

在蘋果晶片中，這些路徑由原生 MSL 核心支持，這些核心利用 simdgroup 操作和對統一記憶體中映射模型的直接訪問，最大限度地減少複製並充分利用晶片的整合特性。該路徑的優化略遜於 RDNA4，但目前仍在積極開發中。

Zinc 為像 Qwen3.5 35B-A3B-UD 這樣的複雜模型所建構的計算圖可以達到 700 多個節點，包括混合專家（MoE）層、SSM 和詞彙投影。整個計算圖正朝著一種策略發展，即每個 token 的解碼過程都記錄為一條 Vulkan 命令，從而減少目前每個 token 120 次 GPU-CPU 交互帶來的效能損失。

除了推理核心之外，Zinc 還整合了一個 HTTP 伺服器，其 /v1 提供與 OpenAI 相容的 API，以及一個位於 / 的基於瀏覽器的聊天介面。該 API 支援令牌串流傳輸，並且 /health 提供了一個健康狀態端點，用於與編排器和監控系統整合。

安裝相依性並編譯 Zinc

使用 Zinc 幾乎不需要任何外部工具，尤其是在 macOS 系統（搭載 Apple Silicon 晶片）上。在這種環境下，只需安裝 Zig（版本 0.15.2 或更高版本）以及使用 `xcode-select --install` 命令安裝 Xcode 命令列工具。 Vulkan、glslc、Python 和 MLX 都是不必要的，因為整個過程都依賴 Metal 和 Zig 的建置系統。

在配備 AMD GPU 的 Linux 系統上，設定同樣簡單：建議使用 `apt update` 更新軟體包，並安裝 `libvulkan-dev`、`vulkan-tools` 和 `glslc`，以及用於複製程式碼倉庫的 `git`。必須從官方網站下載 Zig 0.15.2 或更高版本，並將其新增至 PATH 環境變數中，才能順利執行 `zig build` 指令。

安裝完依賴項後，兩個平台上的建置流程完全相同：使用 `git clone https://github.com/zolotukhin/zinc.git` 複製官方 GitHub 倉庫，進入倉庫目錄，然後執行 `zig build -Doptimize=ReleaseFast`。 `ReleaseFast` 選項對於獲得最佳化後的二進位檔案至關重要，可以避免效能測量結果出現偏差。

產生的二進位檔案保存在 ./zig-out/bin/zinc 目錄下。在 Linux 系統上，建置過程也會將 GLSL 著色器編譯為 SPIR-V 格式，並將其放置在 zig-out/share/zinc/shaders/ 目錄下。但在 macOS 系統上，Metal 著色器會在執行時根據專案中包含的 MSL 程式碼進行編譯。

需要注意的是，Linux RDNA4 中存在一個關鍵細節：某些較新版本的 glslc 在編譯著色器時可能會導致顯著的效能下降。該專案建議使用系統倉庫中提供的 glslc 版本，而不是透過其他途徑取得的較新版本。

初步檢查和鋅的第一步

在發出任何提示之前，建議先執行指令 `./zig-out/bin/zinc --check` 進行初步檢查。此指令會驗證主機環境、GPU 和必要的資源是否正常，以及是否有缺少的著色器、Vulkan/Metal 功能或模型元資料。

在執行 RDNA4 架構的機器上，建議在檢查和推理會話之前匯出 RADV_PERFTEST=coop_matrix 變量，然後再次呼叫 ./zig-out/bin/zinc --check 指令。這樣做的目的是確認 GPU 已被正確檢測到，協同矩陣優化已激活，並且沒有出現任何嚴重警告。

如果檢查結束時顯示「READY [OK]」，則表示環境已處於適合進行推理測試的狀態。如果出現警告，建議先解決這些問題（例如驅動程式、Vulkan 版本、未編譯的著色器、所選模型的顯存不足等），然後再評估引擎的效能或穩定性。

該檢查還會驗證諸如Vulkan 設備的發現、活動 GPU 的選擇、傳遞 –model-id 時託管模型的兼容性、GGUF 元數據以及模型是否適合所選 GPU 上的可用 VRAM 的估計等方面。

該階段完成後，建議的工作流程非常簡單：列出與機器相容的模型目錄，下載已針對您的 GPU 配置進行驗證的模型，然後執行一次帶有簡短提示的初始 CLI 推理。這樣可以驗證整個流程（分詞、前向傳播、文字輸出）是否正常運作。

模型目錄、下載與管理

Zinc 整合了一個管理模型系統，可以偵測 GPU 配置（例如 amd-rdna4-32gb 或 apple-silicon），並顯示哪些經過驗證的模型與該記憶體和容量配置最匹配。可以使用指令 `./zig-out/bin/zinc model list` 瀏覽此目錄。

若要下載模型，可以使用指令 `model pull`，例如 `./zig-out/bin/zinc model pull qwen35-2b-q4k-m`。此指令會下載與 Qwen3.5 2B 模型對應的、量化等級為 Q4_K_M 的 GGUF 文件，並將其儲存到本機快取中，同時驗證 SHA-256 雜湊值以確保下載的完整性。

下載完成後，您可以使用 `./zig-out/bin/zinc model use qwen35-2b-q4k-m` 設定預設模型以供後續運行，並使用 `./zig-out/bin/zinc model active` 查看當前啟動的模型。這樣，後續多次呼叫就不需要明確指定 `--model-id` 參數了。

當您不再需要某個模型時，可以使用./zig-out/bin/zinc model rm qwen35-2b-q4k-m 將其從快取中釋放，這有助於管理磁碟空間，如果您嘗試多個量化版本或替代模型。

該目錄有意保持精簡，專注於專案團隊已完成端到端驗證的模型，而非承諾與數百種 GGUF 變體在理論上相容。有關模型工作流程和快取選項的更多詳細信息，請參閱 Zinc 的專用 Web 文件。

CLI 推理、HTTP 伺服器和 Web 聊天

測試 Zinc 最直接的方法是使用命令列介面 (CLI)。編譯二進位檔案、下載模型並通過檢查後，您可以使用類似 `./zig-out/bin/zinc --model-id qwen35-2b-q4k-m --prompt "法國的首都是"` 的命令執行一個簡單的初始測試。在 Linux RDNA4 系統上，請記得啟用 `export RADV_PERFTEST=coop_matrix` 以利用協作矩陣。

如果配置正確，日誌應該顯示模型載入器的訊息、預先填入完成的資訊、產生的詞元數量以及產生速率（單位為 tok/s），最後以一條連貫的輸出訊息結束，通常是上例中的單字「Paris」。看到此序列表明主推理路徑正在運行。

除了純命令列模式外，Zinc 還整合了一個伺服器模式，可透過 `./zig-out/bin/zinc chat` 命令存取。此指令會啟動一個 HTTP 伺服器（預設連接埠為 9090），並在瀏覽器中開啟內建的聊天介面。之後，您可以像在線聊天一樣與模型進行交互，包括支援更長時間的“推理”模式。

您也可以使用 `./zig-out/bin/zinc --model-id qwen35-2b-q4k-m -p 8080` 手動啟動伺服器，並根據需要選擇合適的連接埠。然後，只需在瀏覽器中開啟 `http://localhost:8080/` 即可存取內建在程式中的聊天介面。

Zinc 公開的 HTTP API透過 /v1 路由支援 OpenAI，讓您可以將已與 OpenAI API 相容的用戶端或 SDK 直接指向您的 Zinc 執行個體。此外，還包含一個 /health 端點，用於在生產部署或編排環境中進行健康檢查。

目前的限制和路線圖

儘管 Zinc 目前已具備基本功能，但該專案公開聲明仍處於實驗階段，部分功能仍在開發中。命令列介面 (CLI) 模式是目前最完善的入門方式；伺服器端、模型覆蓋範圍以及效能微調等功能正在透過頻繁的迭代不斷改進。

存在一些公認的限制：支援的型號清單有意控制在較窄的範圍內；蘋果晶片的路線圖仍在不斷調整，以接近 RDNA4 的效率；以及實現連續多進程批處理以同時服務多個客戶端的功能已列入路線圖，但尚未最終確定。

開發團隊正在致力於幾個關鍵領域的工作，以期從「原始解碼速度超過 30 tok/s」過渡到支援長時間推理工作負載，同時保持該速度並提高整體 GPU 利用率。這包括彌合 /v1/completions 和 /v1/chat/completions 之間的差距，因為聊天模板和首次詞元到達時間 (TTFT) 會增加額外的開銷。

另一個正在改進的領域是減少 Vulkan 熱路徑中的描述符變更：其理念是重複使用綁定並最大限度地減少解碼循環中每個標記的工作量，從而使每次 Vulkan 操作的 CPU 時間和延遲盡可能低。

計劃中的高級階段包括 TurboQuant KV 壓縮，這是一種 KV（鍵值）狀態壓縮技術，可幫助減少內存消耗並提高長序列的速度，以及實現連續批處理，以在聚合級別上提高多個並發流的每秒令牌速率。

想要深入了解程式碼的人有一個相對容易管理的基礎：大約 5.000 行 Zig 程式碼和大約 2.000 行 GLSL 程式碼，以及適用於 Apple 的 MSL 著色器、效能分析工具（--profile，仍在調整中，以免扭曲測量結果）和 Web 文件中的詳細開發指南。

總而言之，對於擁有現代 AMD GPU 或 Apple Silicon 系統，並希望充分利用硬體進行本地 LLM 開發，而無需借助 ROCm、CUDA 或重量級 Python 運行時環境的用戶而言，Zinc 展現出令人眼前一亮的前景。它結合了 Zig、Vulkan 和 Metal，並針對每種架構量身定制了一套著色器，使其成為在自有機器上建立高效推理環境的理想選擇，無論您是想進行實驗、提供 OpenAI 相容的 API，還是深入了解如何建立底層推理引擎。