西门子授权plc(模块)一级总代理商

一、作者概述

本项目的目标是开发一个高效的集成系统，专注于从西门子PLC设备中采集数据，并通过MQTT协议安全地传输这些数据到云服务器。在服务器上，利用先进的人工智能技术对这些数据进行深入的处理和分析。Zui终，系统将以语音的形式向用户反馈分析结果，提供一个直观且用户友好的数据理解方式。我的系统设计旨在充分利用云计算的强大功能，结合AI的Zui新进展，以实现数据处理的自动化和智能化。

1、数据采集与传输（第一篇文章）

使用C#语言从西门子PLC采集数据。

通过MQTT协议，将数据发送到部署在云服务器上的Blazor_SignaIR系统。

2、云服务器数据处理（第二篇文章）

在云服务器上部署MQTT服务器。

在云服务器上部署Blazor应用的Server模式。

通过Blazor_SignaIR实现B/S架构，对外提供Web服务，进行数据接收和处理。

3、语音到文本转换（第三篇文章）

利用达摩院Paraformer模型进行语音到文本的转换。

转换后的文本信息通过MQTT协议发送。

4、文本信息抽取（第四篇文章）

使用PaddleNLP进行文本信息抽取。

目标是提取关键信息以供后续AI模型分析。

5、数据库数据获取（第五篇文章）

使用InfluxDB时序数据库存储和检索数据（C#、.NET8）。

获取InfluxDB数据库中的数据、并进行清理、压缩提供给至本地部署的AI模型进行分析(Python)。

6、AI模型分析（此篇文章）

1.5版本通义千问模型（2024-02-28发布的模型Qwen1.5-1.8B-Chat-AWQ）。

项目面临一个挑战是本地显卡的显存仅有6G，这限制了我们只能部署1.8B参数的模型版本。尽管如此，该版本已经能够满足我们的分析和处理需求。，不能使用更高参数的模型（6种模型大小：0.5B、1.8B、4B、7B、14B       和 72B；）。

AI模型将对输入数据进行分析，并得出结论。

7、文本到语音转换

使用VITS模型进行文本到语音的转换。

接收MQTT消息后，生成WAV格式的语音并播放。

当前第六篇：

1. 接收 已经过压缩处理后的MQTT 消息，并利用大型语言模型（LLM， Qwen1.5-1.8B-Chat-AWQ）生成响应。然后，它将这些响应发送到云服务器，供B/S（浏览器/服务器）架构的云监控应用和语音合成应用使用。此外，程序还会复制这些响应，并将它们发送到另一个MQTT主题“LLM-VITS。
2. 在云服务器上部署的B/S架构云监控应用，新增了显示由大型语言模型（如Qwen1.5-1.8B-Chat-AWQ）生成的响应结果的功能。

二、大型语言模型（LLM， Qwen1.5-1.8B-Chat-AWQ）生成响应。

      运行界面：为本项目选择了 Qwen1.5-1.8B-Chat-AWQ 模型，主要因其先进的多语言支持和高效的自然语言处理能力，特别符合对实时数据分析和自然语言生成的需求。这款模型，虽然参数量仅为18亿，但已足以处理我们的数据分析任务，提供准确和及时的反馈。

1、Qwen1.5-1.8B-Chat-AWQ 简介

基于 Transformer 的仅解码器语言模型，预先训练了大量数据。与之前的 Qwen 相比，其改进包括：

1）6种模型大小：0.5B、1.8B、4B、7B、14B 和      72B；

2）聊天模型人类偏好的显著性能提升；

3）基础和聊天模型的多语言支持；

4）所有大小模型稳定支持 32K 上下文长度；

评估语言模型的基本能力：涵盖了包括语言理解、编程、推理、多语言能力、人类偏好、代理、检索增强生成（RAG）等基本能力。

Qwen1.5的模型在7亿参数以下非常具有竞争力。

2、系统架构

该聊天系统采用Python编程语言开发，整合了MQTT通信协议和大型语言模型Qwen1.5-1.8B-Chat-AWQ。MQTT提供了高效的消息传输机制，而LLM则负责处理和生成自然语言响应。

程序的基本构成：

1）MQTT配置：程序通过MQTT进行数据的接收和发送，使用了paho.mqtt.client库来实现MQTT客户端的功能。

2）模型加载与初始化：利用transformers库加载了Qwen1.5-1.8B-Chat-AWQ模型，这个模型在理解和生成自然语言方面具有高效的性能。

3）多线程与实时响应：程序使用Python的多线程功能来保证在生成模型响应时不会阻塞主线程，从而实现了更流畅的用户交互体验。

3、功能实现

实时消息处理：通过MQTT协议，程序可以实时接收来自不同源的消息，并快速生成响应。

自然语言处理：借助于LLM的能力，程序可以理解复杂的查询，并生成自然的语言响应。
代码分析与深度讲解：

程序的核心在于如何有效地整合MQTT通信和LLM。主要流程包括接收MQTT消息、利用LLM生成响应，以及将响应通过MQTT发送回去。通过Thread线程，我们能够异步地生成响应，保证了程序在等待模型生成时的响应性。

这段代码为建立一个异步、上下文感知的聊天系统奠定了基础。

MQTT回调函数：

1）on_connect:      当客户端成功连接到MQTT服务器时触发。这个函数的作用是在连接建立后订阅特定的主题（MQTT_TOPIC_LISTEN），以便接收来自该主题的消息。

2）on_message:      当从MQTT服务器接收到新消息时执行。这个函数用于处理接收到的消息。它更新全局变量，指示新消息已经被接收，并保存这条消息的内容。

3）on_disconnect:      当客户端与MQTT服务器的连接断开时执行。它用于处理连接断开的情况，特别是在出现非正常断开连接时提供反馈。

加载模型和分词器：

load_model_tokenizer:      这个函数负责从给定的检查点路径加载预训练的语言模型和相应的分词器。它将模型配置为在CUDA设备上运行（如果可用），设置生成响应时使用的Zui大新令牌数量，并打印有关CUDA环境的信息。此函数的作用是准备模型和分词器，使其能够用于后续的自然语言处理和生成任务。

设置了MQTT通信的基础设施，并准备了自然语言处理的核心组件，即预训练的大型语言模型和分词器。

_gc() 函数：负责清理Python的垃圾回收，并且如果CUDA可用，它也会清空CUDA的显存缓存。

具体作用：

gc.collect():      调用Python内建的垃圾回收机制来清理未引用的内存。这是为了防止内存泄漏，并优化内存使用。

if      torch.cuda.is_available(): 检查CUDA（用于GPU计算的一个接口）是否可用。

torch.cuda.empty_cache():      清空CUDA显存中的缓存，释放不再需要的显存资源。这对于在有限的GPU资源下运行大型模型尤为重要，比如本程序中使用的大型语言模型。

_release_cuda_memory() 函数：该函数用于同步CUDA操作并释放占用的CUDA显存。

具体作用：

torch.cuda.synchronize():      确保所有CUDA核心已经完成当前的任务。这在执行任何显存清理操作之前是必要的，以确保不会意外地中断或影响正在进行的CUDA操作。

torch.cuda.empty_cache():      与_gc()函数中相同，此调用清空CUDA显存缓存。这在一系列CUDA操作完成后特别有用，以确保不必要的显存占用被及时清理，从而为后续操作释放显存资源。

这两个函数是内存和显存管理的重要部分，特别是在处理需要大量计算资源的任务（如运行大型深度学习模型）时。通过有效管理内存和显存，这些函数帮助确保了程序的高效运行，同时防止了资源耗尽导致的问题。

通过构建一个对话历史和当前查询的结构来准备输入数据，然后使用异步方式调用模型生成聊天响应。这种异步方法可以提高程序的响应速度和整体性能，特别是在处理大量并发请求的场景下。同时，通过清理内存和显存，代码确保了资源的有效利用，减少了内存泄漏的风险。Zui终，程序将生成的文本作为响应返回，同时将模型从GPU移回CPU，减轻资源占用。

该函数实现了一个关键的循环，用于不断检查是否有新的MQTT消息到达。一旦收到消息，程序就会异步生成响应，并将响应通过MQTT发布回去。这个过程涉及到多个步骤，包括将模型移到GPU上以加快处理速度，生成响应，记录处理时间，格式化并发布响应，以及Zui后的清理工作。

特别值得注意的是，通过使用asyncio.sleep(0.1)，函数在等待新消息时不会阻塞其它异步任务的执行，从而提高了程序的整体效率和响应能力。此外，通过将处理过程封装在一个无限循环中，程序可以持续不断地处理新到达的消息。

以上实现了AI技术进行深度处理和分析。

三、在云服务器上部署的B/S架构云监控应用，显示响应结果

通过MQTT和SignalR技术，实现了数据的实时接收和跨多个客户端的即时分发。

集成了MQTT客户端以订阅和处理来自特定MQTT主题的消息。特别是，它处理来自“ASR_UIE_LLM”主题的消息，并检查收到的消息是否包含“LLM”键。如果是，程序会提取消息内容，并使用SignalR技术将这些数据实时发送到所有连接的客户端。

使用Razor语法创建了两个部分来显示ASR和LLM的处理结果。

使用条件渲染来判断receivedASRText和receivedLLMText字符串是否为空，如果不为空，则在页面上显示相应的文本。

创建一个HubConnection实例来与服务器上的SignalR hub进行通信。

通过监听“ReceiveASRData”和“ReceiveLLMData”事件来处理从服务器接收到的数据。

当这些事件被触发时，相应的消息内容将被保存在receivedASRText和receivedLLMText变量中，并触发UI的更新。

实时显示来自后端系统的LLM处理结果，提供了一种交互式的用户体验。

以下是我们使用 Qwen1.5-1.8B-Chat-AWQ 模型在实际应用场景中的一些测试结果。这些结果展示了模型处理问题的速度和效率，反映了其在实际工业环境中的应用潜力：
输入问题：

推理结果显示，推理耗时300秒左右：

Qwen1.5-1.8B-Chat-AWQ模型拥有18亿参数，这相对较小。参数量是衡量模型处理信息和解决复杂问题能力的一个重要因素。一般来说，参数越多，模型在语言理解和生成方面的能力越强，尤其是在处理复杂和多样化的任务时更为明显。曾有机会体验过一个拥有1750亿参数的模型，以下是一些未经筛选的体验结果，供大家参考。在Zui终章节中，我会探讨在本地部署超大型LLM的可能性：

Qwen1.5-1.8B-Chat-AWQ模型显存每次使用（专用GPU内存利用率）：

为直观展示模型处理速度，创建了一个演示版本。以下视频展示了每次响应生成的时间：
在这里Zui大回复字数设置为：model.generation_config.max_new_tokens = 520