当前位置：首页 > news >正文

大模型推理框架简介

news 来源：原创 2025/5/6 15:37:32

概述

通常需要大量的计算资源，高效运行LLMs仍然是一个挑战，

推理框架作为LLM高效部署的关键组件，直接关系到应用的性能、成本和开发效率。

高性能框架

vLLM

GitHub，由SKYPILOT构建的推理优化框架，旨在提高在GPU上运行的LLM的效率。

核心优势：

PagedAttention技术：突破传统KV缓存机制，结合动态批处理和异步调度机制，实现显存分页管理，支持超长序列生成（如10万token对话）；
吞吐量领先：在A100 GPU上可达传统框架3倍以上吞吐量，支持动态批处理；
量化优化支持：内置GPTQ、AWQ等量化技术，有效压缩模型体积，进一步提升GPU资源利用率；
多GPU分布式部署：支持在多卡GPU集群上运行，即便面对千亿参数级模型，也能在低延迟下稳定处理海量并发请求；
生态兼容性：原生支持HF模型格式，兼容PyTorch生态。

优势与局限

优势：适用于高并发在线服务，如金融交易、智能客服和文档处理；低首次响应时间（TTFT）表现出色；
局限：依赖高端NVIDIA GPU（如 A100、H100，H20），硬件投入成本较高；代码架构较复杂，对定制开发和维护要求较高。

适用场景

互联网大厂API服务（如OpenAI兼容接口）
高并发在线推理（1000+ QPS）
长文本生成场景（法律文书生成、代码补全）

# Run the container with GPU support
docker run -it \--runtime nvidia \--gpus all \--network="host" \--ipc=host \-v ./models:/vllm-workspace/models \-v ./config:/vllm-workspace/config \vllm/vllm-openai:latest \--model models/Qwen2.5-14B-Instruct/Qwen2.5-14B-Instruct-Q4_K_M.gguf \--tokenizer Qwen/Qwen2.5-14B-Instruct \--host "0.0.0.0" \--port 5000 \--gpu-memory-utilization 1.0 \--served-model-name "VLLMQwen2.5-14B" \--max-num-batched-tokens 24576 \--max-num-seqs 256 \--max-model-len 8192 \--generation-config config

测试：

import requests
import concurrent.futuresBASE_URL = "http://<your_vLLM_server_ip>:5000/v1"
API_TOKEN = "sk-1234"
MODEL = "VLLMQwen2.5-14B"def create_request_body():return {"model": MODEL,"messages": [{"role": "user", "content": "Tell me a story of 1000 words."}]}def make_request(request_body):headers = {"Authorization": f"Bearer {API_TOKEN}","Content-Type": "application/json"}response = requests.post(f"{BASE_URL}/chat/completions", json=request_body, headers=headers, verify=False)return response.json()def parallel_requests(num_requests):request_body = create_request_body()with concurrent.futures.ThreadPoolExecutor(max_workers=num_requests) as executor:futures = [executor.submit(make_request, request_body) for _ in range(num_requests)]results = [future.result() for future in concurrent.futures.as_completed(futures)]return resultsif __name__ == "__main__":num_requests = 50  # Example: Set the number of parallel requestsresponses = parallel_requests(num_requests)for i, response in enumerate(responses):print(f"Response {i+1}: {response}")

SGLang

GitHub，提供前端语言，让你能用更简洁、更符合逻辑的方式去编排复杂的生成任务，比如结构化数据提取、多轮对话管理、函数调用、带约束的生成等等。提供后端引擎（比如RadixAttention）也吸取类似PagedAttention精髓，并针对这种前端语言定义的复杂控制流加以协同优化。

技术特点

RadixAttention：通过共享前缀请求和高效缓存策略，SGLang能在理论上实现十万级token/s的超高吞吐量，同时显著降低响应延迟；
分布式调度：支持跨节点自动负载均衡；
高效结构化输出：内置高性能JSON解析模块，便于构建面向结构化数据查询的API服务，适合复杂自动化工作流；
轻量模块化架构：采用灵活的模块化设计，便于快速集成新技术（如FlashInfer内核），不断优化推理效率；
混合精度计算：FP16与FP32智能切换

适用领域

多模态模型推理（文本+图像）
复杂工作流编排（RAG增强生成）
科研机构超大规模模型实验

优势与局限

优势：适用于大批量结构化查询和实时响应要求极高的应用；在高并发场景下表现出色。
局限：当前版本仅支持Linux平台，跨平台兼容性待提升；对多模态任务支持较弱，生态尚在起步阶段。

vLLM和SGLang

区别：

核心出发点不同
vLLM：算力压榨机。出发点是极致优化推理引擎的性能和内存效率，解决KV Cache问题。一切为了吞吐量和低延迟。
SGLang：生成控制大师。出发点是如何更灵活、更高效地控制LLM的生成过程，同时保持高性能。
提供的价值层面不同
vLLM：主要在Runtime/Engine层面发力。给的是一个高性能的底层库，你调API就行，但复杂的生成逻辑你还得自己在外面封装。
SGLang：提供的是Language + Runtime的组合。不仅优化Runtime，还提供一种新的、专门用于控制生成流程的编程语言DSL (Domain-Specific Language)，大大降低实现复杂生成策略的门槛。
解决的问题侧重不同
vLLM：主要解决高并发、变长序列下的推理效率问题。特别适合那些需要大规模部署、处理海量请求的标准生成场景。
SGLang：主要解决复杂生成任务的编程复杂性和执行效率问题。特别适合需要精细控制生成内容、实现高级 Agent 逻辑、做 RAG 中复杂检索与生成协同、或者需要模型输出严格遵守某种格式的场景。它的 Vision Language Model 支持也是一个亮点。
抽象层次不同
vLLM：更底层，关注Attention机制和内存管理优化。
SGLang：更高层，引入控制流概念，并将其与底层优化结合。目标是如何让开发者更爽地调用LLM完成复杂任务。

LMDeploy

GitHub。

技术特点

国产GPU深度适配：针对华为昇腾等国产GPU进行专门优化，充分发挥硬件优势，显著提升推理效率与显存利用率；
多模态融合支持：在视觉-语言混合模型上具备明显优势，能同时处理图像和文本数据，满足复杂业务场景需求；
Turbomind引擎：采用异步流水线并行，延迟降低至50ms级别；
量化部署工具链：支持W4A16量化，模型体积压缩4倍；
动态批处理：智能合并不同长度请求，GPU利用率达90%+。

优势与局限

优势：在国产硬件环境下成本优势明显，适合政府、企业级定制化部署；多模态支持能力强；
局限：更新迭代速度较慢；分布式部署和高并发处理能力有待进一步提升。

适用于国内企业和政府机构在国产 GPU 平台上的大模型部署，特别是多模态交互和视觉语言任务领域。

典型应用

金融实时风控系统
游戏NPC智能对话
工业质检实时报告生成

TGI

Text Generation Inference，HuggingFace开源组件，GitHub。

技术特点

生态系统成熟稳定：作为HF Inference API核心组件，在云端推理服务中已被广泛验证；
标准化API接口：提供RESTful API与OpenAI兼容接口，支持连续批处理和流式输出，便于与现有应用无缝集成；
服务稳定性：内置健康检查、自动故障转移
多GPU扩展：支持Tensor并行和流水线并行
安全合规：符合GDPR和HIPAA标准

优势与局限

优势：文档丰富、生态成熟，易于集成和扩展；适合大规模云端部署和API推理；
局限：在极端高并发场景下，定制化优化能力可能略逊于专用解决方案；部分高级功能依赖云端服务。

部署案例

AWS SageMaker推理服务
银行智能客服系统
医疗报告自动生成平台

DeepSeek AI Open Infra Index

底层优化套件

FlashMLA：基于CUDA的矩阵运算加速库，提升30%计算效率
DeepEP：弹性并行框架，支持动态资源分配
智能缓存：自适应数据预取策略

协同生态

与vLLM结合实现显存利用率提升40%
与SGLang集成优化分布式任务调度

本地部署与轻量化框架

框架	核心特性	硬件要求	典型应用场景
Ollama	一键部署/Web界面	消费级GPU（6GB+）	个人知识管理/快速原型验证
Llama.cpp	GGUF格式支持/纯CPU推理	树莓派4B	工业边缘设备/隐私计算盒子
LocalAI	本地化数据隔离/端到端加密	服务器CPU集群	政务系统/医疗数据解析
KTransformers	能效比优化（<5W）	ARM架构芯片	物联网设备/车载语音助手
GPT4ALL	图形化模型市场/零代码部署	Mac M系列芯片	教育机构/非技术用户实验

Llama.cpp

GitHub，

技术特点

纯CPU推理：完全基于CPU实现，无需高性能GPU，适合在嵌入式设备、边缘计算及资源受限环境下运行；
轻量级与开源：架构简单、易于部署，社区活跃，用户可以根据需求自行定制和优化推理过程。

优势与局限

优势：零硬件门槛，成本极低；适合边缘设备和低负载任务；开源生态丰富，便于快速迭代；
局限：与GPU加速方案相比，推理速度较慢，不适合大规模在线服务；高并发处理能力有限。

适用于边缘计算、物联网和低负载场景，为无GPU环境下的基本推理需求提供可行方案。

Ollama

GitHub，
一个本地LLM运行时，可简化部署和使用开源模型。对于希望在个人机器上试验模型的开发人员来说，Ollama是一个绝佳选择。提供能力：

跨平台一键安装：Ollama 支持 Windows、macOS 与 Linux 平台，提供直观的用户界面，降低使用门槛。
预打包模型：内置超过 1700 款预训练模型，默认提供 int4 量化处理后的权重，大幅降低显存需求，使普通消费级硬件也能流畅运行。如LLaMA、Mistral和Falcon；
优化的CPU和GPU推理：用于在日常硬件上运行模型；
离线推理保障：支持完全离线运行，确保数据安全与隐私，适合对本地数据保护有高要求的应用；
封装llama.cpp：在llama.cpp的基础上提供更高层次抽象，使模型调用与管理更加简单便捷。
简单的API和CLI：允许开发人员以最少的配置启动LLM。

优势与局限

优势：操作简单、易上手，适合个人开发者、学生和快速原型验证；低硬件资源要求及离线数据安全；
局限：在高并发场景下，响应性能可能存在瓶颈；扩展性和插件定制能力较弱，不适合大规模在线部署。

配置文件：

[Unit]
Description=Ollama Service
After=network-online.target[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=/home/henry/.local/bin:/usr/local/cuda/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OPENAI_BASE_URL=http://0.0.0.0:11434/api"[Install]
WantedBy=multi-user.target

vLLM和Ollama

对比项	vLLM	Ollama
推理速度	非常快	快，但依赖于部署的硬件
内存效率	非常高	尚可，受限于硬件
可扩展性	可大规模部署到企业级云服务器	本地小规模部署
安装便捷性	麻烦，需Python和CUDA环境；提供更多定制选项	一行代码，易于安装；简单，可快速实验LLM；
API支持	PyTorch、TensorFlow，REST API	CLI和API
适用场景	企业级应用，高端GPU，微调和运行自定义模型，超长上下文窗口	无需复杂设置，边缘计算，使用简单API，试验模型
适用人群	需要深度定制的开发人员	初学者，快速原型设计、测试想法
生产就绪性	为生产环境而设计	本地部署和验证
安全	支持APIKEY授权	-
文档	提供全面的技术文档	文档简单且适合初学者，但缺乏技术深度，特别是在性能和并行处理方面

KTransformers

清华大学KVCache.AI团队与趋境科技开源项目，地址GitHub。旨在通过先进的内核优化、设备放置及并行策略，为Transformers体验提供增强支持。其核心设计强调可扩展性；用户仅需一行代码即可实现并注入优化模块，便可获得与Transformers兼容的接口。核心之一在于应用异构计算策略，利用DeepSeek混合专家架构(MoE)的稀疏性和计算复杂度低的特点，将MoE部分放在内存并由CPU完成计算，而计算复杂度较高但相对更省显存的MLA部分继续留在GPU显存并由GPU完成计算，大幅降低显存需求。

此外，采用4bit量化技术和Marlin GPU算子配合，也使得推理效率得到显著提升，推理速度提高近四倍。CUDA Graph加速技术通过优化CPU/GPU的通信效率，显著减少延迟和资源消耗。

特性：

显存砍到十分之一，性能反升28倍
DeepSeek-R1作为全球顶尖的MoE架构模型，原本需要8卡A100才能勉强运行，而KTransformers通过异构计算划分策略，将稀疏MoE矩阵卸载到CPU内存，仅保留稠密部分在GPU显存中。配合4bit量化和Marlin算子优化，显存需求从200GB+骤降至24GB，同时预处理速度飙升至286 tokens/s，生成速度达14 tokens/s，比传统方案（如llama.cpp）快28倍。
专家卸载：榨干硬件每一滴算力
团队独创的计算强度导向卸载策略，将高计算强度的算子（如MLA注意力核心）优先分配至GPU，低强度部分（如稀疏专家模块）转移至CPU。通过llamafile高速CPU算子和CUDA Graph加速，CPU与GPU协同作战，彻底释放异构计算潜力，连老旧的3090显卡都能跑出9.1 tokens/s的生成速度。
一键兼容，小白也能玩转千亿模型
KTransformers不仅提供HF无缝接口和ChatGPT式Web界面，还支持通过YAML配置文件灵活切换量化策略与优化内核。开发者甚至能直接用Windows系统部署，搭配200GB内存的消费级设备即可体验千亿模型的魅力。

核心技术：

稀疏性革命：MoE架构的稀疏特性被发挥到极致，每次推理仅激活部分专家模块，结合CPU/GPU协同计算，显存占用大幅降低；
量化黑科技：4bit量化下，模型精度损失微乎其微，但显存占用压缩至原版的1/4。通过Marlin算子优化，GPU计算效率提升3.87倍，彻底告别量化即减速的魔咒；
长文本秒级响应：针对万级Token的上下文任务（如代码分析），KTransformers的Intel AMX指令集优化让CPU预填充速度冲上286 tokens/s，从分钟级等待跃进至秒级响应。

灵活部署框架

XInference

核心能力

多模型并行服务（同时加载10+模型）
动态扩缩容：根据负载自动调整实例数
兼容性：100% OpenAI API协议支持

推荐场景

中小型企业多模型服务中台
科研机构对比实验平台

OpenLLM

技术优势

异构硬件支持（TPU/GPU/CPU混合部署）
自定义适配器（LoRA插件热加载）
服务监控：Prometheus集成

典型用户

云服务提供商（混合云部署）
自动驾驶模型服务集群

HF Transformers

生态优势

支持模型数量：20w+
社区贡献机制：日均更新50+模型
部署方式：支持Triton/ONNX Runtime

首选场景

学术研究快速实验
创业公司MVP开发

LiteLLM

统一接口方案

支持模型：30+主流LLM
流量控制：智能路由与负载均衡
成本监控：按token计费分析

适用对象

多模型SaaS平台
企业混合云成本优化

TensorRT-LLM

GitHub，

技术特点

深度链路优化：借助NVIDIA TensorRT，对大模型进行全链路优化，确保在推理过程中极低延迟和超高吞吐量；
量化与预编译支持：通过预编译和多种量化方案（如FP8/INT4），最大化利用NVIDIA GPU的计算潜力，进一步提升性能。

优势与局限

优势：在NVIDIA GPU环境下表现出色，极大缩短响应时间，适合对推理速度要求苛刻的生产级应用；
局限：预编译过程可能会带来冷启动延迟；仅限于NVIDIA CUDA平台，跨平台部署存在局限。

MLC-LLM

GitHub，

技术特点

基于Apache TVM的编译优化：MLC-LLM利用ML编译技术对大模型进行全链路优化，有效降低TTFT，为快速原型验证提供支持；
实验性与前沿探索：在低并发场景下表现优异，展示编译优化技术在推理领域的巨大潜力。

优势与局限

优势：在小规模、低延迟需求场景中表现突出，适合研发初期和实验性应用；
局限：当前版本多为nightly构建，稳定性和文档支持仍有待完善；部署流程相对复杂，对编译与配置要求较高。

选型

需综合考虑，吞吐量需求、硬件预算、合规要求和技术栈适配性。建议通过压力测试验证框架在实际业务场景中的表现，同时关注社区活跃度（GitHub Star增长趋势）和商业支持选项。

平台/引擎	核心技术/亮点优势	局限	适用场景
vLLM	PagedAttention、动态批处理、异步调度、多GPU分布式	高并发、低延迟，适合大规模在线服务	依赖高端GPU、代码复杂，二次开发门槛较高
Ollama	基于llama.cpp封装，跨平台支持、内置1700+ 模型、int4量化	安装便捷、易上手、低硬件要求、数据离线保障	并发处理能力较弱，扩展性和插件定制能力有限
SGLang	RadixAttention、高效缓存、结构化输出、轻量模块化架构	超高吞吐量、极低响应延迟、适合高并发结构化查询	目前仅支持Linux、对多模态任务支持能力有限
LMDeploy	国产GPU深度适配、显存优化、多模态融合支持	在国产硬件上性能优异、成本优势明显，适合多模态复杂场景	更新迭代较慢、分布式部署和高并发处理能力待加强
Llama.cpp	纯CPU推理、轻量级设计、开源社区支持	零硬件门槛、低成本、适合边缘和嵌入式设备	推理速度较慢，高并发能力有限
TensorRT-LLM	基于NVIDIA TensorRT深度优化、量化与预编译支持	极低延迟、高吞吐量、充分发挥NVIDIA GPU优势	预编译过程可能带来冷启动延迟，仅限 NVIDIA CUDA平台
Hugging Face TGI	生产级推理服务、标准化REST API、OpenAI兼容接口	生态成熟、稳定可靠、易于云端集成	高并发定制化优化能力稍弱，部分功能依赖云端服务
MLC-LLM	基于Apache TVM的编译优化、低TTFT、实验性原型验证	在低并发、低延迟场景下表现突出，展示编译优化潜力	当前版本稳定性待提高，部署流程较复杂

综合建议

企业级高并发应用：对于对延迟与吞吐量要求极高的场景，推荐选择vLLM、TensorRT-LLM或HuggingFace TGI，它们在多GPU部署和低延迟响应方面表现尤为突出。
个人开发与本地原型：Ollama凭借其跨平台、易上手的特性，非常适合个人原型验证和离线本地部署，而Llama.cpp则满足无GPU环境下的基本推理需求；
国产硬件部署：LMDeploy针对国产GPU进行深度优化，具备多模态处理优势，适合国内企业和政府机构在特定硬件环境下部署；
新兴技术探索：SGLang与MLC-LLM分别在高吞吐量和编译优化上展示了前沿技术潜力，虽然当前还存在一定局限，但未来发展前景值得期待。

随着硬件升级、算法革新和产业生态不断完善，大模型推理技术正朝着以下方向发展：