大模型
- 自动部署开源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 影响因素更直观了？