性能优化实战从能用到好用的调优之路标签性能优化 | 并发 | 显存 | 缓存 | 监控 | 调优一、性能问题的众生相你的 Chatchat 系统是不是遇到过这些情况一个人用挺快三个人同时问就卡死模型加载完显存直接爆了啥也干不了第一次问答要等10 秒后面才快一点知识库文档一多检索慢得像蜗牛服务跑一晚上内存蹭蹭涨最后 OOM这些问题不解决系统永远只是玩具上不了生产环境。今天这篇咱们系统性地做性能优化。二、性能瓶颈分析2.1 先定位再优化性能优化最怕瞎调。先用工具找到瓶颈在哪# 1. 看系统资源nvidia-smi# GPU 显存和利用率top/htop# CPU 和内存iotop# IO 情况# 2. Python 性能分析python-mcProfile-oprofile.stats your_script.py snakeviz profile.stats# 可视化查看# 3. API 接口耗时# 在 Chatchat 日志里看各阶段耗时2.2 Chatchat 的典型瓶颈用户请求 ↓ [API 接收] ──→ 通常不是瓶颈FastAPI 很快 ↓ [文档检索] ──→ 瓶颈 1向量检索慢大数据量 ↓ [Rerank] ──→ 瓶颈 2精排计算量大 ↓ [LLM 调用] ──→ 瓶颈 3模型推理慢主要瓶颈 ↓ [流式返回] ──→ 瓶颈 4网络传输结论LLM 推理是最大瓶颈其次是向量检索。三、LLM 推理优化3.1 模型量化用精度换速度量化就是把模型的权重从 32bit 浮点数变成 8bit、4bit 整数大幅减少显存占用和计算量。量化级别显存占用速度提升精度损失推荐场景FP16基准基准无显存充足INT8~50%1.5x极小通用推荐Q4_K_M~25%2x小资源紧张Q2_K~15%3x明显仅演示Xinference 中加载量化模型# 4bit 量化性价比最高xinference launch\--model-name qwen2-instruct\--model-format ggufv2\--size-in-billions7\--quantizationq4_K_M3.2 vLLM 加速推理引擎升级vLLM 是一个高性能推理引擎核心优化是PagedAttention传统推理每个请求预分配一大块显存利用率低 PagedAttention把显存分成小块page按需分配类似操作系统的虚拟内存 效果同样显存支持更多并发Xinference 使用 vLLMxinference launch\--model-name qwen2-instruct\--model-format pytorch\--size-in-billions7\--model-engine vllm\--gpu_memory_utilization0.853.3 动态批处理Continuous Batching传统批处理等一组请求凑齐了再一起处理。动态批处理请求来了就处理随时把新请求插进正在进行的批次里。传统请求 A ──→ 等 B 来 ──→ [A, B] 一起处理 ──→ 等 C 来 ──→ [C, D] 一起处理 动态请求 A ──→ 开始处理 ──→ B 来了插进来 ──→ C 来了插进来 ──→ 一起输出vLLM 内置了动态批处理不需要额外配置。3.4 多实例负载均衡单实例撑不住多开几个# docker-compose.ymlservices:llm-1:image:xinference:latestenvironment:-XINFERENCE_MODEL_UIDqwen2-1deploy:resources:reservations:devices:-driver:nvidiacount:1capabilities:[gpu]llm-2:image:xinference:latestenvironment:-XINFERENCE_MODEL_UIDqwen2-2deploy:resources:reservations:devices:-driver:nvidiacount:1capabilities:[gpu]Chatchat 配置多个模型实例# model_settings.yamlMODEL_PLATFORMS:-platform_name:xinference-clusterplatform_type:xinferenceapi_base_url:http://llm-load-balancer:9997/v1前面加一层 Nginx 或 HAProxy 做负载均衡。四、向量检索优化4.1 索引类型选择FAISS 支持多种索引类型根据数据量选择importfaiss# 小数据量 10万暴力搜索精确indexfaiss.IndexFlatIP(dimensions)# 中数据量10万 ~ 100万IVF 倒排索引nlist100# 聚类中心数quantizerfaiss.IndexFlatIP(dimensions)indexfaiss.IndexIVFFlat(quantizer,dimensions,nlist)index.train(vectors)# 需要训练index.add(vectors)# 大数据量 100万HNSW 图索引indexfaiss.IndexHNSWFlat(dimensions,M32)index.hnsw.efConstruction200index.add(vectors)# 查询时调整搜索深度index.hnsw.efSearch128# 越大越精确越慢4.2 索引预热和持久化# 启动时加载已有索引避免重建importfaissimportos INDEX_PATHdata/knowledge_base/index.faissdefload_or_create_index(dimensions):ifos.path.exists(INDEX_PATH):# 加载已有索引快returnfaiss.read_index(INDEX_PATH)else:# 创建新索引returnfaiss.IndexFlatIP(dimensions)defsave_index(index):# 定期保存索引faiss.write_index(index,INDEX_PATH)4.3 检索缓存热门问题的检索结果可以缓存fromfunctoolsimportlru_cacheimporthashlib# 简单的 LRU 缓存lru_cache(maxsize1000)defcached_search(query_hash,kb_name,top_k):缓存向量检索结果# 实际检索逻辑passdefsearch_with_cache(query,kb_name,top_k5):# 用查询的哈希作为缓存 keyquery_hashhashlib.md5(query.encode()).hexdigest()returncached_search(query_hash,kb_name,top_k)4.4 向量数据库升级如果 FAISS 不够用了升级到 Milvus# kb_settings.yamlDEFAULT_VS_TYPE:milvuskbs_config:milvus:host:localhostport:19530user:password:secure:falseMilvus 的优势分布式支持海量数据GPU 加速索引构建多副本高可用五、系统级优化5.1 异步处理Chatchat 已经用了异步但确保你的调用也是异步的# ✅ 异步调用asyncdefchat_async():responseawaitasync_client.chat.completions.create(...)returnresponse# ❌ 同步调用会阻塞defchat_sync():responseclient.chat.completions.create(...)returnresponse5.2 连接池# 复用 HTTP 连接减少握手开销importhttpx# 全局客户端async_clienthttpx.AsyncClient(limitshttpx.Limits(max_connections100,max_keepalive_connections20),timeouthttpx.Timeout(30.0))# 使用时responseawaitasync_client.post(url,jsondata)5.3 数据库连接池# SQLAlchemy 连接池配置fromsqlalchemyimportcreate_engine enginecreate_engine(sqlite:///data.db,pool_size10,# 连接池大小max_overflow20,# 超出池大小的连接数pool_timeout30,# 获取连接的超时时间pool_recycle3600,# 连接回收时间)5.4 内存管理# 定期清理缓存importgcimporttorchdefcleanup():清理 GPU 和 CPU 内存# 清理 PyTorch 缓存iftorch.cuda.is_available():torch.cuda.empty_cache()# Python 垃圾回收gc.collect()# 定时任务每小时执行一次fromapscheduler.schedulers.backgroundimportBackgroundScheduler schedulerBackgroundScheduler()scheduler.add_job(cleanup,interval,hours1)scheduler.start()六、监控和日志6.1 关键指标指标说明告警阈值API 响应时间端到端耗时 5sLLM 推理时间模型生成耗时 3s向量检索时间检索耗时 500msGPU 显存占用nvidia-smi 90%GPU 利用率计算利用率 10%可能挂了内存占用系统内存 85%并发请求数同时处理的请求看容量规划6.2 Prometheus Grafana 监控# 接入 Prometheus 监控fromprometheus_clientimportCounter,Histogram,start_http_server# 定义指标request_countCounter(chatchat_requests_total,Total requests,[endpoint])request_durationHistogram(chatchat_request_duration_seconds,Request duration,[endpoint])# 在 API 中埋点chat_router.post(/chat/completions)asyncdefchat_completions(request:Request):withrequest_duration.labels(endpoint/chat/completions).time():request_count.labels(endpoint/chat/completions).inc()# ... 处理逻辑# 启动指标服务start_http_server(9090)# Prometheus 来这拉数据6.3 结构化日志importloggingimportjsonfrompythonjsonloggerimportjsonlogger# JSON 格式日志logHandlerlogging.StreamHandler()formatterjsonlogger.JsonFormatter(%(timestamp)s %(level)s %(name)s %(message)s %(request_id)s %(duration_ms)s)logHandler.setFormatter(formatter)loggerlogging.getLogger(chatchat)logger.addHandler(logHandler)logger.setLevel(logging.INFO)# 使用logger.info(Chat completion,extra{request_id:req-123,model:qwen2-instruct,duration_ms:1200,tokens_in:100,tokens_out:200})七、优化效果对比7.1 优化前后的指标指标优化前优化后提升首 token 延迟3s0.5s6x并发用户数3206x显存占用 (7B)16GB4GB4x检索耗时 (10万条)200ms20ms10x服务稳定性经常 OOM7x24 稳定-7.2 优化投入产出优化项投入效果模型量化5 分钟显存降 75%vLLM 加速10 分钟并发翻倍索引优化30 分钟检索快 10x缓存1 小时热门查询几乎零延迟监控2 小时问题可观测八、小结这篇咱们做了系统性的性能优化✅ 瓶颈分析定位 LLM 推理和向量检索是主要瓶颈✅ LLM 优化量化、vLLM、动态批处理、多实例✅ 检索优化索引选型、预热持久化、缓存、Milvus 升级✅ 系统优化异步、连接池、内存管理✅ 监控体系Prometheus Grafana 结构化日志性能优化的核心原则先测量再优化别凭感觉抓主要矛盾LLM 推理是最大头量化收益记录优化前后的数据监控先行没监控等于没优化你在性能优化过程中遇到过什么反直觉的问题比如某个优化反而变慢了欢迎分享踩坑经历
LangChain-Chatchat 开发与应用(九) 性能优化实战-从能用到好用的调优之路
性能优化实战从能用到好用的调优之路标签性能优化 | 并发 | 显存 | 缓存 | 监控 | 调优一、性能问题的众生相你的 Chatchat 系统是不是遇到过这些情况一个人用挺快三个人同时问就卡死模型加载完显存直接爆了啥也干不了第一次问答要等10 秒后面才快一点知识库文档一多检索慢得像蜗牛服务跑一晚上内存蹭蹭涨最后 OOM这些问题不解决系统永远只是玩具上不了生产环境。今天这篇咱们系统性地做性能优化。二、性能瓶颈分析2.1 先定位再优化性能优化最怕瞎调。先用工具找到瓶颈在哪# 1. 看系统资源nvidia-smi# GPU 显存和利用率top/htop# CPU 和内存iotop# IO 情况# 2. Python 性能分析python-mcProfile-oprofile.stats your_script.py snakeviz profile.stats# 可视化查看# 3. API 接口耗时# 在 Chatchat 日志里看各阶段耗时2.2 Chatchat 的典型瓶颈用户请求 ↓ [API 接收] ──→ 通常不是瓶颈FastAPI 很快 ↓ [文档检索] ──→ 瓶颈 1向量检索慢大数据量 ↓ [Rerank] ──→ 瓶颈 2精排计算量大 ↓ [LLM 调用] ──→ 瓶颈 3模型推理慢主要瓶颈 ↓ [流式返回] ──→ 瓶颈 4网络传输结论LLM 推理是最大瓶颈其次是向量检索。三、LLM 推理优化3.1 模型量化用精度换速度量化就是把模型的权重从 32bit 浮点数变成 8bit、4bit 整数大幅减少显存占用和计算量。量化级别显存占用速度提升精度损失推荐场景FP16基准基准无显存充足INT8~50%1.5x极小通用推荐Q4_K_M~25%2x小资源紧张Q2_K~15%3x明显仅演示Xinference 中加载量化模型# 4bit 量化性价比最高xinference launch\--model-name qwen2-instruct\--model-format ggufv2\--size-in-billions7\--quantizationq4_K_M3.2 vLLM 加速推理引擎升级vLLM 是一个高性能推理引擎核心优化是PagedAttention传统推理每个请求预分配一大块显存利用率低 PagedAttention把显存分成小块page按需分配类似操作系统的虚拟内存 效果同样显存支持更多并发Xinference 使用 vLLMxinference launch\--model-name qwen2-instruct\--model-format pytorch\--size-in-billions7\--model-engine vllm\--gpu_memory_utilization0.853.3 动态批处理Continuous Batching传统批处理等一组请求凑齐了再一起处理。动态批处理请求来了就处理随时把新请求插进正在进行的批次里。传统请求 A ──→ 等 B 来 ──→ [A, B] 一起处理 ──→ 等 C 来 ──→ [C, D] 一起处理 动态请求 A ──→ 开始处理 ──→ B 来了插进来 ──→ C 来了插进来 ──→ 一起输出vLLM 内置了动态批处理不需要额外配置。3.4 多实例负载均衡单实例撑不住多开几个# docker-compose.ymlservices:llm-1:image:xinference:latestenvironment:-XINFERENCE_MODEL_UIDqwen2-1deploy:resources:reservations:devices:-driver:nvidiacount:1capabilities:[gpu]llm-2:image:xinference:latestenvironment:-XINFERENCE_MODEL_UIDqwen2-2deploy:resources:reservations:devices:-driver:nvidiacount:1capabilities:[gpu]Chatchat 配置多个模型实例# model_settings.yamlMODEL_PLATFORMS:-platform_name:xinference-clusterplatform_type:xinferenceapi_base_url:http://llm-load-balancer:9997/v1前面加一层 Nginx 或 HAProxy 做负载均衡。四、向量检索优化4.1 索引类型选择FAISS 支持多种索引类型根据数据量选择importfaiss# 小数据量 10万暴力搜索精确indexfaiss.IndexFlatIP(dimensions)# 中数据量10万 ~ 100万IVF 倒排索引nlist100# 聚类中心数quantizerfaiss.IndexFlatIP(dimensions)indexfaiss.IndexIVFFlat(quantizer,dimensions,nlist)index.train(vectors)# 需要训练index.add(vectors)# 大数据量 100万HNSW 图索引indexfaiss.IndexHNSWFlat(dimensions,M32)index.hnsw.efConstruction200index.add(vectors)# 查询时调整搜索深度index.hnsw.efSearch128# 越大越精确越慢4.2 索引预热和持久化# 启动时加载已有索引避免重建importfaissimportos INDEX_PATHdata/knowledge_base/index.faissdefload_or_create_index(dimensions):ifos.path.exists(INDEX_PATH):# 加载已有索引快returnfaiss.read_index(INDEX_PATH)else:# 创建新索引returnfaiss.IndexFlatIP(dimensions)defsave_index(index):# 定期保存索引faiss.write_index(index,INDEX_PATH)4.3 检索缓存热门问题的检索结果可以缓存fromfunctoolsimportlru_cacheimporthashlib# 简单的 LRU 缓存lru_cache(maxsize1000)defcached_search(query_hash,kb_name,top_k):缓存向量检索结果# 实际检索逻辑passdefsearch_with_cache(query,kb_name,top_k5):# 用查询的哈希作为缓存 keyquery_hashhashlib.md5(query.encode()).hexdigest()returncached_search(query_hash,kb_name,top_k)4.4 向量数据库升级如果 FAISS 不够用了升级到 Milvus# kb_settings.yamlDEFAULT_VS_TYPE:milvuskbs_config:milvus:host:localhostport:19530user:password:secure:falseMilvus 的优势分布式支持海量数据GPU 加速索引构建多副本高可用五、系统级优化5.1 异步处理Chatchat 已经用了异步但确保你的调用也是异步的# ✅ 异步调用asyncdefchat_async():responseawaitasync_client.chat.completions.create(...)returnresponse# ❌ 同步调用会阻塞defchat_sync():responseclient.chat.completions.create(...)returnresponse5.2 连接池# 复用 HTTP 连接减少握手开销importhttpx# 全局客户端async_clienthttpx.AsyncClient(limitshttpx.Limits(max_connections100,max_keepalive_connections20),timeouthttpx.Timeout(30.0))# 使用时responseawaitasync_client.post(url,jsondata)5.3 数据库连接池# SQLAlchemy 连接池配置fromsqlalchemyimportcreate_engine enginecreate_engine(sqlite:///data.db,pool_size10,# 连接池大小max_overflow20,# 超出池大小的连接数pool_timeout30,# 获取连接的超时时间pool_recycle3600,# 连接回收时间)5.4 内存管理# 定期清理缓存importgcimporttorchdefcleanup():清理 GPU 和 CPU 内存# 清理 PyTorch 缓存iftorch.cuda.is_available():torch.cuda.empty_cache()# Python 垃圾回收gc.collect()# 定时任务每小时执行一次fromapscheduler.schedulers.backgroundimportBackgroundScheduler schedulerBackgroundScheduler()scheduler.add_job(cleanup,interval,hours1)scheduler.start()六、监控和日志6.1 关键指标指标说明告警阈值API 响应时间端到端耗时 5sLLM 推理时间模型生成耗时 3s向量检索时间检索耗时 500msGPU 显存占用nvidia-smi 90%GPU 利用率计算利用率 10%可能挂了内存占用系统内存 85%并发请求数同时处理的请求看容量规划6.2 Prometheus Grafana 监控# 接入 Prometheus 监控fromprometheus_clientimportCounter,Histogram,start_http_server# 定义指标request_countCounter(chatchat_requests_total,Total requests,[endpoint])request_durationHistogram(chatchat_request_duration_seconds,Request duration,[endpoint])# 在 API 中埋点chat_router.post(/chat/completions)asyncdefchat_completions(request:Request):withrequest_duration.labels(endpoint/chat/completions).time():request_count.labels(endpoint/chat/completions).inc()# ... 处理逻辑# 启动指标服务start_http_server(9090)# Prometheus 来这拉数据6.3 结构化日志importloggingimportjsonfrompythonjsonloggerimportjsonlogger# JSON 格式日志logHandlerlogging.StreamHandler()formatterjsonlogger.JsonFormatter(%(timestamp)s %(level)s %(name)s %(message)s %(request_id)s %(duration_ms)s)logHandler.setFormatter(formatter)loggerlogging.getLogger(chatchat)logger.addHandler(logHandler)logger.setLevel(logging.INFO)# 使用logger.info(Chat completion,extra{request_id:req-123,model:qwen2-instruct,duration_ms:1200,tokens_in:100,tokens_out:200})七、优化效果对比7.1 优化前后的指标指标优化前优化后提升首 token 延迟3s0.5s6x并发用户数3206x显存占用 (7B)16GB4GB4x检索耗时 (10万条)200ms20ms10x服务稳定性经常 OOM7x24 稳定-7.2 优化投入产出优化项投入效果模型量化5 分钟显存降 75%vLLM 加速10 分钟并发翻倍索引优化30 分钟检索快 10x缓存1 小时热门查询几乎零延迟监控2 小时问题可观测八、小结这篇咱们做了系统性的性能优化✅ 瓶颈分析定位 LLM 推理和向量检索是主要瓶颈✅ LLM 优化量化、vLLM、动态批处理、多实例✅ 检索优化索引选型、预热持久化、缓存、Milvus 升级✅ 系统优化异步、连接池、内存管理✅ 监控体系Prometheus Grafana 结构化日志性能优化的核心原则先测量再优化别凭感觉抓主要矛盾LLM 推理是最大头量化收益记录优化前后的数据监控先行没监控等于没优化你在性能优化过程中遇到过什么反直觉的问题比如某个优化反而变慢了欢迎分享踩坑经历
