大模型
- 自动部署开源AI模型到生产环境:Scikit-learn、XGBoost、LightGBM、和PySpark
- 阿里云测试模型
- huggingface模型下载
- Ollama
- Llama2
- ChatGML
- pro-chat
- Scaling Laws
- 如何解决llm的并发问题?
- 如何理解llm的并发?
- 流式输出
- OpenAI api使用介绍
- 使用ollama快速部署开源大模型
- jupyter中使用Ollama+langchain构建RAG
- GraphRAG实战(openai+langchain+neo4j)
- 从零搭建大模型(一): 架构(architecture)
- 从零搭建大模型(二): 预训练(pretraining)
- 基因组大模型概述
思考
- 如何解决llm的并发问题?
- 24G显存的3090显卡部署7b的模型,每秒的最大的请求数是多少(QPS)?
- NVIDIA TensorRT、DeepSpeed、HuggingFace Accelerate?
采用 Continous batching 来优化请求,提高 throughput,这个在 VLLM 和 TGI 中都有支持。
用 flash attention 和 page attention 来优化 GPU 中 attention 的计算效率。目前部分主流的 inference 的仓库都会集成这两种 attention 优化方式。
对于部分设备来说,可以考虑采用 GPTQ 提速。比如对于 4090,如果采用 fp16,在推理时batch size 仅能够达到 4(max_tokens=2048)。但 GPTQ 能够支持 batch size 8 + max_tokens=2048。尽管batch inference 情况下,FP16 的速度会快于 GPTQ,但更大的 batch size 支持还是能让 GPTQ 的 throughput 优于 fp16。
部署超大模型时,采用 Tensor Parallelism 加速,这个在 TGI , deepspeed 或者 vllm 都有支持。
服务速度实在不理想的话,考虑多买几台 GPU,然后用 Load balancer 做请求转发。
资源
https://github.com/vanna-ai
Chat with your SQL database . Accurate Text-to-SQL Generation via LLMs using RAG
https://github.com/instructor-ai/instructor
structured outputs for llms
https://github.com/steven-tey/novel
Notion-style WYSIWYG editor with AI-powered autocompletion.
https://github.com/microsoft/graphrag
https://ragflow.io/docs/dev/
https://github.com/whyhow-ai/knowledge-graph-studio
https://github.com/OpenSPG/KAG/blob/master/kag/examples/medicine/README_cn.md
https://huggingface.co/autotrain
https://github.com/jingyaogong/minimind Dense+MoE模型 Pytorch
LLaMA 做微调的工具: https://github.com/hiyouga/LLaMA-Factory
视频
学习资料
- LLMBook github
- llm-viz github
- llm-universe github
- llama3-from-scratch llms-from-scratch-cn Build a Large Language Model (From Scratch)
- Understanding Deep Learning
- 3小时完全从0训练26M的小参数GPT
- 21 Lessons teaching everything you need to know to start building Generative AI applications
- https://github.com/mlabonne/llm-course
https://github.com/rasbt/LLMs-from-scratch
**影响 LLM QPS(每秒请求数)的因素 - 形象化描述 **
想象你在一个 餐厅,AI 模型(LLM)就像是 厨师团队,处理用户的 点餐请求。QPS(每秒请求数)就类似于 厨师每秒能完成的菜品数量。影响 QPS 的关键因素,就像影响餐厅出菜速度的因素!
** 1. 厨师(GPU 计算能力)**
- 比喻:厨师的技能和速度决定了做菜的快慢。GPU 的计算能力(TFLOPS)影响 LLM 处理请求的快慢。
- 影响 QPS:
- 低端显卡(3060):像新手厨师,处理一单要很久,QPS 低。
- 高端显卡(A100、H100):像米其林大厨,做菜快,QPS 高。
- 多张 GPU 并行:多个厨师一起做菜,QPS 提升。
** 2. 厨房空间(显存容量)**
- 比喻:厨房越大(显存越大),可以同时做的菜(并行处理的请求)就越多。
- 影响 QPS:
- 显存不足(<16GB):只能做小量任务,处理长文本或大批量请求容易爆显存,导致 QPS 下降。
- 显存充足(80GB H100):可以同时处理多个请求,QPS 高。
- 量化(INT4, INT8):相当于减少厨具占用空间,让更多菜能同时做,提高 QPS。
3. 订单处理方式(推理模式:同步、异步、批处理)
比喻:
同步处理(单点做菜):一个厨师接一单,做完再接下一单(QPS 低)。
异步处理(多任务并行):一个厨师可以同时处理多个菜品,提高 QPS。
批处理(多个订单一起做):类似于一次性炒 10 份蛋炒饭,比单做 10 份快很多!
影响 QPS:
Continuous Batching(持续批处理) = 多张 GPU 共享订单池,提高 QPS(TGI/vLLM)。
流式推理 = 边做菜边上菜,减少等待时间,提高吞吐量。
** 4. 厨房流水线(Tensor/数据并行)**
比喻:
Tensor 并行 = 一个菜分成多个部分,每个厨师负责一部分,提高效率(vLLM)。
数据并行 = 每个厨师独立做完整的菜,提高吞吐量(DeepSpeed ZeRO)。
Pipeline 并行 = 类似流水线,每个人做一道工序,效率更高(Megatron-LM)。
影响 QPS:
单 GPU 处理完整请求(单人独立做菜)→ 速度慢,QPS 低。
多 GPU 并行(3 张 3090) → 每人分工,提高吞吐量,QPS 高。
** 5. 顾客点菜复杂度(模型大小 & Token 长度)**
- 比喻:点菜越复杂(模型越大、输入文本越长),做菜时间越长,QPS 就越低!
- 影响 QPS:
- 短文本(10 个 Token) → 类似炒个蛋,秒出菜,QPS 高。
- 长文本(2000+ Token) → 像是做满汉全席,需要时间长,QPS 低。
- 7B vs. 70B 模型 → 7B 像是快餐店(处理快),70B 像是豪华大厨(处理慢)。
** 6. 网络 & 数据传输(API 调用开销)**
比喻:
网络慢(延迟高) = 送餐员骑自行车送外卖,整体速度受影响,QPS 低。
高效 API 设计(流式传输) = 像跑腿小哥用电动车送外卖,减少等待时间,提高 QPS。
影响 QPS:
API 调用开销(FastAPI vs. gRPC) → 影响请求处理速度。
HTTP vs. WebSocket → WebSocket 更快,QPS 更高。
** 总结:如何提升 QPS?**
影响因素 | 低 QPS 情况 | 高 QPS 方案 |
---|---|---|
GPU 计算能力 | 低端显卡(如 3060) | 高端显卡(A100/H100),多 GPU 并行 |
显存容量 | 显存不足,频繁交换数据 | 增大显存、使用量化(INT4/INT8) |
推理模式 | 单请求同步处理 | 批量推理(Batching)、异步推理 |
并行策略 | 单 GPU 处理整个模型 | Tensor 并行、数据并行、流水线并行 |
Token 长度 | 处理超长文本 | 限制最大 Token 数,提高吞吐量 |
API 设计 | API 响应慢 | 使用 WebSocket、优化 HTTP 请求 |
** 形象化 QPS 提升**
低 QPS(无优化)
单人厨师,一份菜做完再做下一份,顾客等待时间长,QPS 低。
中等 QPS(多 GPU 并行)
3 个厨师,每人独立做菜,三倍 QPS,响应速度提高。
高 QPS(批量推理 + 并行)
流水线炒饭工厂,10 个厨师批量出菜,QPS 爆炸增长!
这样一讲,是不是对 LLM QPS 影响因素更直观了?