1. 首页
  2. 云计算与数据挖掘
  3. 大模型
大模型

大模型

  1. 自动部署开源AI模型到生产环境：Scikit-learn、XGBoost、LightGBM、和PySpark
    2.
  2. 阿里云测试模型
    3.
  3. huggingface模型下载
    4.
  4. Ollama
    5.
  5. Llama2
    6.
  6. ChatGML
    7.
  7. pro-chat
    8.
  8. Scaling Laws
    9.
  9. 如何解决llm的并发问题?
    10.
  10. 如何理解llm的并发?
    11.
  11. 流式输出
    12.
  12. OpenAI api使用介绍
    13.
  13. 使用ollama快速部署开源大模型
    14.
  14. jupyter中使用Ollama+langchain构建RAG
    15.
  15. GraphRAG实战(openai+langchain+neo4j)
    16.
  16. 从零搭建大模型(一): 架构(architecture)
    17.
  17. 从零搭建大模型(二): 预训练(pretraining)
    18.
  18. 基因组大模型概述
    19.

思考

  • 如何解决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

视频

学习资料

生信小木屋

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 影响因素更直观了？