ZINC：不给 ROCm 面子，用 Zig 原生"裸奔"的本地 LLM 推理引擎

想象这样一个场景：你手里有一块 AMD Radeon RX 9070 XT，想在本地跑一个 Qwen 3.5 9B 参数的大模型。翻开主流方案，你会看到 llama.cpp（"支持，但你得自己配 ROCm"）、vLLM（"我们不做 AMD 支持"）、MLX（"不好意思，我们只服务苹果用户"）……

Stepan Zolotukhin 遇到了同样的问题。他的答案是：既然没人给我修路，我就自己修一条——用 Zig 语言，从头写一个 GPU 推理引擎。这就是 ZINC（Zig INferenCe Engine）的由来。

ZINC 对话演示

图1：ZINC 在 AMD RDNA4 GPU 上运行 Qwen 3.5 35B 流式推理的实时截图

背景故事：为什么一个人要重写整个推理栈？

Stepan Zolotukhin 是一名独立的 AI 基础设施工程师。2026 年 3 月，他在搭建家用 AI 工作站时遇到了一块 AMD RDNA4 显卡——没有 ROCm 支持，也就没有任何主流推理框架愿意搭理它。llama.cpp 在 AMD 上能跑，但需要 ROCm 运行时；MLX 压根不涉及非苹果硬件。

他最初尝试在 Linux 上配置 ROCm + llama.cpp，但 ROCm 对 RDNA4 的支持不完整，驱动版本、编译选项、HSA 运行时每个环节都可能出问题。更关键的是，他发现整个推理路径上到处是黑盒——内核是供应商写的，行为不可预测，调优无从下手。

ZINC 的诞生逻辑很简单：绕过所有中间层，直接用 Vulkan/Metal 的 compute shader 写矩阵乘法。 代价是：从零实现 Attention、KV Cache、MoE Routing、量化反量化……但好处也是等价的：完全可控的性能、完全透明的执行路径、以及——不需要任何第三方运行时依赖。

项目于 2026 年 3 月 25 日创建，截止 2026 年 6 月 26 日已积累 410 Stars、17 Forks，涵盖了 Vulkan（AMD/Intel）、Metal（Apple Silicon）和 CUDA（NVIDIA）三套 GPU 后端。

核心功能：它到底能做什么？

多后端 GPU 推理

ZINC 最大的技术亮点是同一套 Zig 代码驱动三套完全不同的 GPU API：

后端	目标硬件	API 层	成熟度
Vulkan	AMD RDNA3/RDNA4、Intel Arc Xe2	SPIR-V Compute Shader	Primary（主推）
Metal	Apple Silicon M1-M5	MSL (Metal Shading Language)	成熟
CUDA	NVIDIA RTX 4090/5090	NVRTC + cuBLAS	开发中

AMD Vulkan 后端是 ZINC 的核心战场。作者用手写的 SPIR-V compute shader 覆盖了从 dmmv（去量化+矩阵向量乘）到 flash_attention（Flash Attention）的全套计算核。其中 RDNA4 的 cooperative matrix 特性（通过 RADV_PERFTEST=coop_matrix 环境变量开启）可将预填充（prefill）速度提升数倍。

Apple Silicon Metal 后端利用统一内存（UMA）架构——CPU 和 GPU 共享同一块内存，彻底消除了显存拷贝开销。同时 Metal 的管线状态缓存（Pipeline State Object）机制被高度优化，冷启动时间显著低于 Vulkan。

NVIDIA CUDA 后端在 2026 年 6 月刚刚完成 M1 阶段——18 个解码内核在 RTX 5090 上全部通过精度验证。核心发现是：ZINC 的 GEMM 路径使用 dotPacked4x8AccSatEXT（AMD）/ __dp4a（NVIDIA）整数点积指令，无需 tensor core，移植是机械性的。

GPU 计算架构

图2：ZINC GPU 计算单元抽象——统一的调度层之下是 Metal/Vulkan/CUDA 三套异构实现

模型格式与量化支持

ZINC 只支持 GGUF 格式（llama.cpp 主导的量化模型容器），支持的量化精度相当全面：

Q4_K_M（4-bit 混合块量化）：平衡质量和体积，最推荐的格式
Q5_K / Q6_K：更高精度量化
Q8_0 / Q5_0 / Q4_0：更高精度但体积大
MXFP4：AMD RDNA4 原生支持的超低精度格式
FP16 / BF16 / FP32：高精度推理（需要更大显存）

当前验证支持的模型家族包括：Qwen 3.5 / Qwen 3.6（dense + MoE）和 Gemma 4（含 MoE 变体）。作者刻意保持模型列表"窄"——不追求 Llama/Mistral 的全面兼容，只聚焦于用户实际在本地跑的模型。

Web UI 与 OpenAI 兼容 API

ZINC 自带两个使用界面：

浏览器聊天 UI：运行 zinc chat 即可在本地启动 Web 界面，支持流式输出和 thinking mode（思维链展示）。聊天模板自动应用 instruct 模型的对话格式。
OpenAI 兼容 REST API：在 /v1 端点暴露完整的 Chat Completions 接口，支持 streaming mode。zinc chat 和 API 服务可同时运行，共享同一模型实例。

技术架构：为什么 Zig 是"秘密武器"？

Stepan 在博客中专门写过一篇《Why Zig is the secret weapon behind ZINC》，核心论点是：Zig 的 comptime 反射 + zero-cost abstraction 让 GPU 后端切换变成了编译期决策——comptime if 在编译时丢弃无用代码，生成的二进制没有 Metal 的 Objective-C runtime 包袱，也没有 Vulkan 的 SPIRV-Tools 依赖链。

具体来说，ZINC 的代码结构是：

src/
  model/         # GGUF 解析、tokenizer、模型配置
  gpu/           # GPU 抽象层（interface.zig）
  metal/         # Metal 后端（MSL shader + API wrapper）
  vulkan/        # Vulkan 后端（SPIR-V shader + API wrapper）
  cuda/          # CUDA 后端（C shim + Zig wrapper）
  zinc_rt/       # 从零实现的 AMD GPU 运行时（绕过 Vulkan）
  compute/       # forward pass 调度
  scheduler/     # KV cache 管理、请求调度
  server/        # HTTP server、routes、model manager

值得注意的是 src/zinc_rt/ 目录——这是一个完全从头实现的 AMD GPU 运行时，绕过 Vulkan，通过 AMDGPU 内核驱动（KFD）和 UMQ（User Mode Queue）直接向 GPU 提交命令。这是对"Vulkan 也不够底层"这一认知的直接回应——目前仍处于 tier 2 阶段（t2_umq），未来计划替代 Vulkan 成为 AMD 的首选后端。

src/shaders/ 目录下有超过 300 个 Metal/Vulkan SPIR-V/CUDA .metal / .comp / .cu shader 文件，每个都针对特定量化格式 × 特定模型架构 × 特定 GPU 型号进行手工调优。

上手体验：装起来麻烦吗？

坦率地说，ZINC 不适合追求"一键部署"的用户。

优点

零运行时依赖：编译完成后是单一二进制文件，不需要 conda、ROCm、MLX。
Nix flakes 支持：Linux 用户可用 nix develop 自动获取 Zig + shaderc + Vulkan SDK。
GPU 自检工具：运行 zinc --check 自动检测 GPU 型号、shader 可用性和运行时状态。
模型自动下载：内置 zinc model pull 命令直接从 HuggingFace 下载 GGUF 模型权重。

缺点

Zig 0.15.2 必需：Zig 生态仍在快速发展，版本不兼容很常见。
Windows 不支持：WSL2 上 NVIDIA 机器因 Vulkan ICD 不可用，只能等 CUDA 后端成熟。
Intel Arc 仍在 bring-up：Xe2/Battlemage 架构属于实验性支持。

构建命令（以 Linux AMD 为例）

git clone https://github.com/zolotukhin/zinc.git
cd zinc
zig build -Doptimize=ReleaseFast
export RADV_PERFTEST=coop_matrix   # RDNA4 必开，Mac跳过
./zig-out/bin/zinc --check
./zig-out/bin/zinc model pull qwen35-9b-q4k-m
./zig-out/bin/zinc chat

构建界面

图3：ZINC 编译输出——Zig 编译器输出最终可执行文件路径

构建配置

图4：ZINC 在 AMD GPU 上的构建验证输出

性能表现：和 llama.cpp 比怎么样？

根据项目 README 中的官方 benchmark 数据（同一机器、同一权重、同一 prompt）：

平台	对比模型数	Decode vs llama.cpp	Prefill vs llama.cpp
AMD RDNA4 / Vulkan	5	99% 平均（2款胜出）	24% 平均（差距在追赶中）
Apple Silicon / Metal	5	62% 平均（1款胜出）	58% 平均（2款胜出）
Intel Arc / Vulkan	1	84%	152%（预填充翻倍）

解码（decode）性能是关键战场——AMD RDNA4 上已接近 llama.cpp 水平；Intel Arc 的预填充甚至实现了 1.5 倍超越。预填充差距主要来自 attention kernel 的迭代优化，作者的博客文章完整记录了从 7 tok/s 爬升到 33 tok/s 的调试全过程。

争议与局限

1. 为什么不用 llama.cpp？

llama.cpp 是本地推理的事实标准，AMD Vulkan 支持也一直在推进。Stepan 的解释是：llama.cpp 的 GPU 路径依赖 ROCm，而 ZINC 想要"完全控制 shader 行为"以便做迭代优化。这个选择牺牲了 Broad model support，换来的是针对特定型号的极致调优。

2. 维护者风险

目前 ZINC 由 Stepan 独立维护。没有 CI/CD 流水线测试集，没有公司赞助商，所有 benchmark 数据都来自他个人的机器。如果 Stepan 停止更新，这个项目将面临较大的持续维护压力。

3. 快速迭代的代价

项目目前版本号 0.1.0，README 明确标注"实验性软件"。API、命令行参数、shader 优化策略在快速变化，生产环境使用需要谨慎评估。

行业意义

ZINC 代表了一种本地 AI 推理的新路径：不是做一个"更大的 llama.cpp"，而是利用 Zig 语言的优势，从底层重新审视 GPU 推理的每一个计算路径。

其技术博客的价值同样不可忽视——60+ 篇图文并茂的调试记录，覆盖从 GPU 微架构特性（Wave32 vs Wave64、cooperative matrix 分区）到算法实现（MoE expert routing、prefix KV cache、speculative decoding），几乎可以当作一本 RDNA4 GPU 编程的实战手册。

从行业视角看，ZINC 的出现呼应了一个趋势：GPU 推理框架正在从"通用"走向"垂直"。vLLM 吃掉了数据中心市场，llama.cpp 覆盖了通用爱好者，而 ZINC 正在填补"特定 GPU 架构 + 极致性能调优"的细分需求。

本报告基于 2026-06-26 的 GitHub 仓库状态生成。性能数据引用自项目 README 及官方 benchmark dashboard。