<h4 align="center"> <p> <a href="https://github.com/modelscope/dash-infer/blob/main/README_CN.md">中文</a> | <b>English</b> </p> </h4> </div>

简介

DashInfer 是一个用 C++ 编写的运行时，旨在为各种硬件架构（包括 x86 和 ARMv9）提供高度优化的生产级实现。它支持 CPU 的连续批处理和 NUMA 感知功能，并可以充分利用现代服务器级 CPU 的能力来托管大小高达 14B 的大语言模型。

主要特性

轻量级架构：DashInfer 只需要最少的第三方依赖，并使用静态链接依赖库。通过提供 C++ 和 Python 接口，DashInfer 可以轻松集成到您现有的系统中。
高精度：DashInfer 经过严格的精度测试，能够提供与 PyTorch 和其他 GPU 引擎（如 vLLM）一致的推理精度。
标准 LLM 推理技术：DashInfer 采用标准的 LLM 推理技术，例如：
- 连续批处理允许立即插入新请求并支持流式输出。
- 基于请求的异步接口为每个请求提供独立的生成参数和请求状态控制。
支持主流开源 LLM：DashInfer 支持主流开源 LLM，包括 Qwen、LLaMA、ChatGLM 等，并支持加载 Huggingface 格式的模型。
训练后量化（PTQ）：使用 DashInfer 的即时量化（IQ），可以在不进行微调的情况下实现仅权重量化加速，提高部署效率。精度评估显示 IQ 对模型精度没有影响。当前版本支持 ARM CPU 上的仅权重 8 位量化。
优化的计算核心：通过 OneDNN 和自研汇编核心，DashInfer 能够在 ARM 和 x86 上最大化硬件性能。
支持 Flash Attention：显著加速长序列的注意力计算，大幅降低首个 token 的延迟。
NUMA 感知设计：DashInfer 支持跨多个 NUMA 节点的张量并行推理，充分利用服务器 CPU 的计算能力。通过 numactl 和多进程架构，准确控制线程的 NUMA 亲和性，最大化多节点 CPU 的性能，避免跨 NUMA 访问导致的性能下降。有关 NUMA 的更多信息，请参见：为 NUMA 优化应用程序 - 英特尔，什么是 NUMA？。
上下文长度：当前版本支持最大 32k 的上下文长度，未来计划扩展到更长的上下文长度。
多语言 API 接口：支持 C++ 和 Python 接口。可以通过标准跨语言接口将 C++ 接口扩展到 Java、Rust 等其他编程语言。
操作系统支持：DashInfer 支持主流 Linux 服务器操作系统，如 Centos7 和 Ubuntu22.04，并提供相应的 Docker 镜像。

DashInfer 演示

ModelScope 上的 DashInfer 演示

演示信息：

模型：Qwen1.5-7B-Chat
引擎：DashInfer
硬件：x86，Emerald Rapids，96 vCPU @ 3.2GHz，16GBx24 DDR
阿里云实例：ecs.g8i.24xlarge

文档

支持的硬件和数据类型

硬件

x86 CPU：需要硬件支持 AVX2 指令集。对于英特尔第 5 代至强处理器（Emerald Rapids）、第 4 代至强处理器（Sapphire Rapids），对应阿里云第 8 代 ECS 实例（如 g8i），使用 AMX 指令加速计算。
ARMv9 CPU：需要硬件支持 SVE 指令集。DashInfer 支持包括倚天710在内的 ARMv9 架构处理器，对应阿里云第 8 代 ECS 实例（如 g8y），采用 SVE 指令加速计算。

数据类型

x86 CPU：FP32，BF16
ARM 倚天710 CPU：FP32，BF16，InstantQuant

InstantQuant

InstantQuant 是一种仅权重量化技术。

在倚天710 CPU（ARMv9）上，DashInfer 支持仅权重量化。

要执行仅权重量化，需要修改模型配置文件中的 do_dynamic_quantize_convert 和 quantization_config 字段。参考文档以了解参数的详细说明。

仅权重量化会在 GroupSize 范围内找到权重的最大值和最小值，并将权重值映射到 uint8 范围，计算如下：

$$ scale = \frac {x_{fp32_{max}} - x_{fp32_{min}}} {255 - 0} $$ $$ zeropoint = 0 - \frac {x_{fp32_{min}}} {scale} $$ $$ x_{u8} = x_{fp32} / scale + zeropoint $$

在推理过程中，量化后的权重会恢复为 bfloat16 进行矩阵乘法。

支持的模型

架构	模型	DashInfer model_type	HuggingFace 模型	ModelScope 模型	DashInfer 模型
QWenLMHeadModel	Qwen	Qwen_v10	Qwen/Qwen-1_8B-Chat,<br>Qwen/Qwen-7B-Chat,<br>Qwen/Qwen-14B-Chat, 等	qwen/Qwen-1_8B-Chat,<br>qwen/Qwen-7B-Chat,<br>qwen/Qwen-14B-Chat, 等	/
Qwen2ForCausalLM	Qwen1.5	Qwen_v15	Qwen/Qwen1.5-0.5B-Chat,<br>Qwen/Qwen1.5-1.8B-Chat,<br>Qwen/Qwen1.5-4B-Chat,<br>Qwen/Qwen1.5-7B-Chat,<br>Qwen/Qwen1.5-14B-Chat, 等	qwen/Qwen1.5-0.5B-Chat,<br>qwen/Qwen1.5-1.8B-Chat,<br>qwen/Qwen1.5-4B-Chat,<br>qwen/Qwen1.5-7B-Chat,<br>qwen/Qwen1.5-14B-Chat, 等	/
ChatGLMModel	ChatGLM	ChatGLM_v2	THUDM/chatglm2-6b,<br>THUDM/chatglm2-6b-32k	ZhipuAI/chatglm2-6b,<br>ZhipuAI/chatglm2-6b-32k	/
ChatGLMModel	ChatGLM	ChatGLM_v3	THUDM/chatglm3-6b,<br>THUDM/chatglm3-6b-32k	ZhipuAI/chatglm3-6b,<br>ZhipuAI/chatglm3-6b-32k	/
ChatGLMModel	ChatGLM	ChatGLM_v4	THUDM/glm-4-9b-chat	ZhipuAI/glm-4-9b-chat	dash-infer/glm-4-9b-chat-DI
LlamaForCausalLM	LLaMA-2	LLaMA_v2	meta-llama/Llama-2-7b-chat-hf,<br>meta-llama/Llama-2-13b-chat-hf	modelscope/Llama-2-7b-chat-ms,<br>modelscope/Llama-2-13b-chat-ms	/
LlamaForCausalLM	LLaMA-3	LLaMA_v3	meta-llama/Meta-Llama-3-8B-Instruct	modelscope/Meta-Llama-3-8B-Instruct	/

软件架构

工作流程

工作流程和依赖

模型加载和序列化：这个过程包括加载模型权重、设置转换参数和量化设置。基于这些信息，模型被序列化并转换为DashInfer格式（.dimodel, .ditensors）。这个功能只能通过Python接口访问，并依赖PyTorch和transformers库来访问权重。PyTorch和transformers的版本要求可能因模型而异。DashInfer本身不对版本有特定限制。
模型推理：这一步负责使用DashInfer序列化后的模型执行推理，不依赖PyTorch等组件。DashInfer使用DLPack格式的张量来与外部框架（如PyTorch）交互。DLPack格式的张量可以手动创建，或通过深度学习框架提供的张量转换函数生成。对于C++接口，由于大多数依赖已被静态链接，它主要依赖OpenMP运行时库和C++系统库。我们应用了符号导出控制，确保只有DashInfer的API接口符号可见，从而防止与用户系统中现有库（如protobuf）的版本冲突。

注意：

.dimodel、.ditensors 是由 DashInfer 内核定义的特殊模型格式。

在使用 Python 接口时，可以将步骤 1 和 2 的代码合并。然而，由于 C++ 层面缺乏加载 Huggingface 模型的功能，C++ 接口仅限于使用 DashInfer 格式的模型进行推理。因此，在使用 C++ 接口之前，必须先使用 Python 接口序列化模型。

单 NUMA 架构

在模型推理阶段，可以通过传入输入标记和生成参数来通过 StartRequest 发起推理请求。当请求成功时，DashInfer 引擎将返回一个输出队列 ResultQueue 和一个控制句柄 RequestHandle。

ResultQueue 用于获取输出标记和生成状态。DashInfer 会异步地将生成的标记放入队列，可以通过阻塞（ResultQueue.Get()）或非阻塞（ResultQueue.GetNoWait()）方式从队列中获取标记。
RequestHandle 是用于管理请求的句柄。DashInfer engine 为 RequestHandle 指定的请求提供了同步、停止和释放等基本操作。SyncRequest 操作在生成结束时返回（当生成的标记数量达到限制，或生成了 EOS 标记），用于模拟同步接口的行为。

在单 NUMA 模式下，DashInfer Runtime 使用多线程和线程池进行调度。

多 NUMA 架构

由于某些 Linux 内核无法在线程级别控制 CPU 亲和性，在多 NUMA CPU 上运行引擎可能会导致远程内存节点访问，从而造成性能下降。为了精确控制线程的 CPU 亲和性，DashInfer 多 NUMA 解决方案采用多进程客户端-服务器架构来实现张量并行模型推理。在每个 NUMA 节点上，独立进程运行服务器，每个服务器处理张量并行推理的一部分，进程间使用 OpenMPI 进行协作（例如，通过 allreduce 操作）。客户端通过 gRPC 与服务器交互，提供统一的外部接口，避免在调用 DashInfer 接口时需要管理多个进程。

在 API 方面，多 NUMA 和单 NUMA 推理需要使用不同的头文件和 .so 库（或调用不同的 Python 接口）。除了头文件和库文件外，其他接口保持一致，无需更改代码。详细信息可以参考示例。

单 NUMA
- 头文件：allspark/allspark.h
- .so 库：liballspark_framework.so
- Python API：allspark.Engine()
多 NUMA
- 头文件：allspark/allspark_client.h
- .so 库：liballspark_client.so
- Python API：allspark.ClientEngine()