ZhiLight
zhihu/ZhiLight加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：ZhiLight 在 A800*8 + DeepSeek-R1 AWQ 场景下与 vLLM 的 QPS 性能对比（来源：ZhiLight 官方 Benchmark）
想象一下这个场景：你在凌晨两点调试 DeepSeek-R1 模型，vLLM 推理引擎吭哧吭哧往外蹦 token，旁边同事的卡跑着同样的模型却比你快近一倍。你开始怀疑是不是参数配置有问题，翻遍文档、调参、再跑——还是慢。最后才发现，不是配置问题，是底层推理引擎本身就差了那么一口气。
这就是 ZhiLight 诞生的背景。知乎作为国内最大的知识社区，每天要处理海量大模型推理请求。在实际生产环境中，团队发现主流开源推理引擎（如 vLLM）在 PCIe 架构 GPU 上的表现存在明显瓶颈。于是知乎联手模型底层优化厂商 ModelBest，从 CUDA kernel 级别动刀，自研了一套极致优化的推理框架——ZhiLight。该项目在 GitHub 迅速获得 900+ Stars，成为国内少有的具有实际生产级性能优化的 LLM 推理引擎开源项目。
在张量并行（Tensor Parallelism, TP）场景下，GPU 之间需要进行频繁的 all-reduce 通信操作。传统实现中，通信操作必须等待计算完成后才能执行，形成通信墙——GPU 大段时间处于等待状态，利用率低下。
ZhiLight 创造性地引入了**双流（Dual Streams）**机制：将通信操作和计算操作分配到不同的 CUDA Stream 上执行，实现计算与通信的真正并行。当一个 Stream 正在执行通信时，另一个 Stream 可以同时进行矩阵运算，两者充分重叠，隐藏了通信延迟。这一设计在 PCIe 带宽受限的场景下效果尤为显著。
更进一步，ZhiLight 还支持 INT8 量化的 all-reduce 操作，进一步压缩通信数据量，在保证精度的前提下减少跨 GPU 带宽压力。
除了 GPU 间通信，ZhiLight 还将 Host（CPU）端的 All-Reduce 操作进行了 SIMD 指令优化，充分利用 AVX2/AVX512 等向量指令，大幅提升了小 batch 场景下的聚合效率，避免 CPU 成为瓶颈。
LLM 推理中充满了大量逐元素操作：残差加法、LayerNorm、SwiGLU 激活……传统实现中每个操作都要单独读写 HBM（High Bandwidth Memory），而 HBM 读写恰恰是 GPU 上最耗时的操作之一。
ZhiLight 通过精心设计的 Fused Kernel，将多个逐元素操作合并为单一 CUDA Kernel，大幅减少显存读写次数。实测中，仅 QKV 融合一项就能节省约 30% 的显存带宽消耗。目前已实现：QKV Fusion（Q、K、V 投影合并为一次 kernel）、Residual + LayerNorm Fusion（残差连接与归一化融合）、SwiGLU / FFN Fusion（前馈网络的门控激活融合）。
ZhiLight 在 Prefill 阶段使用 Flash Attention 加速 attention 计算，而在 Decode 阶段则实现了基于 Tensor Core 的 Fused Batch Attention，这是与 vLLM/SGLang 等主流引擎最核心的差异之一。Decode 阶段每次只生成一个 token，batch size 通常较小，Tensor Core 的矩阵乘法在这个粒度下效率更高，ZhiLight 正是抓住了这一特点进行了专项优化。
ZhiLight 支持多种量化方案，特别是对 DeepSeek-V3/R1 FP8 块量化 的支持，使得在有限显存下运行超大规模模型成为可能。对于生产环境而言，AWQ/GPTQ 量化是降低推理成本的利器，ZhiLight 还引入了 Marlin kernel 进一步加速 GPTQ 模型的矩阵运算。
ZhiLight 的代码组织清晰，分为五个核心层次：
| 层级 | 目录 | 职责 |
|---|---|---|
| 接口层 | zhilight/server/ | OpenAI 兼容 API 服务（vLLM 接口适配） |
| 模型层 | zhilight/llama.py + zhilight/loader.py | 模型配置解析、权重加载、量化参数管理 |
| C++ Runtime | src/generator/ | Batch 生成器、Beam Search、Prefix Cache |
| 计算层 | src/nn/ | Attention、Linear、LayerNorm 等神经网络算子（CUDA/C++） |
| 第三方优化库 | 3rd/bmengine/ + 3rd/deep_gemm/ | BMEngine 计算引擎、DeepSeek 专用 GEMM 优化 |
核心推理循环由 Python 层（zhilight/llama.py）调度，C++ 层（src/generator/）执行高效 batch 调度和 CUDA kernel 调用。通过 pybind11 暴露 Python 接口，用户可以像使用 transformers 一样方便地调用 ZhiLight。
特别值得一提的是 3rd/ 目录下集成的自研或深度定制的底层库：BMEngine（知乎自研 CUDA 计算引擎）、deep_gemm（针对 DeepSeek 架构的 GEMM 专用优化）、flash_decoding / flash_mla（DeepSeek-V2 MLA 机制的 Flash Attention 实现）。
ZhiLight 的功能矩阵相当完整，覆盖了当前主流 LLM 推理的几乎所有需求：
通过 OpenAI 兼容接口，现有基于 vLLM 的应用可以零成本迁移到 ZhiLight，只需修改服务启动命令中的引擎参数即可。
根据官方 Benchmark 文档，ZhiLight 在 A8008 + DeepSeek-R1 AWQ 场景下：QPS 达到 0.16，相比 vLLM 0.08 提升约 100%；TTFT P95 为 2214ms，相比 vLLM 2556ms 降低约 13%。在 H208 配置下，ZhiLight 对比 SGLang 同样有显著优势。
但需要注意的是，这些对比数据来自官方测试，其测试配置（如 ZhiLight 启用了 INT8 AllReduce、环境变量调优等）对最终性能有显著影响。实际部署时需要针对具体模型和硬件环境进行参数调优，官方 wiki 中提供了部分调优参数参考（如 REDUCE_TP_INT8_THRES、RESERVE_MEM_MB 等）。
ZhiLight 定位明确——面向有 GPU 服务器和 CUDA 经验的团队。虽然提供了 Dockerfile，但推理服务本身需要从源码编译，依赖链较长：CUDA 12.x + cuDNN + CMake >= 3.26 + Python >= 3.8 + PyTorch >= 2.0 + GCC >= 9。编译过程本身需要高性能 CPU（官方建议 CMAKE_BUILD_PARALLEL_LEVEL=32）和充足磁盘空间。
不过，官方提供了预编译的 Benchmark Docker 镜像（ghcr.io/zhihu/zhilight/benchmark:1.0.1），可以快速验证性能，无需从源码构建。推理服务的编译则无法绕过。
ZhiLight 的出现填补了国内开源高性能 LLM 推理引擎的空白。在 vLLM 和 SGLang 主导的市场中，ZhiLight 以 PCIe 场景为突破口，通过底层 kernel 优化实现了显著的性能提升。其双流并行、INT8 AllReduce 等技术思路对整个推理优化领域都有参考价值。
知乎作为一家拥有实际大模型推理需求的互联网公司，将内部优化成果开源，不仅展示了技术实力，也体现了对开源社区的回馈。随着 AI 应用加速落地，高效推理引擎的需求会越来越迫切——ZhiLight 的价值，正在于此。
图2：ZhiLight 由知乎（Zhihu）与 ModelBest 联合开发维护