基于STM32F103C8T6与SmallThinker-3B-Preview的边缘AI语音交互系统设计1. 引言你有没有想过给家里一个几十块钱的智能开关或者小设备装上能听懂人话、还能跟你聊天的“大脑”听起来像是科幻电影里的情节但现在用一块常见的STM32F103C8T6最小系统板加上一个在云端跑起来的轻量级大模型就能把这个想法变成现实。传统的智能设备交互要么是简单的按键要么需要依赖手机App要么就是得喊一声“小X同学”把语音数据传到遥远的云端服务器去处理。这种方式不仅响应有延迟对网络依赖强而且一旦服务器出问题设备就变“哑巴”了。我们能不能做一个更独立、更快速、成本也更低的方案呢这篇文章要聊的就是这样一个“土法炼钢”但很实用的方案用STM32F103C8T6这块经典的“学生党神板”作为终端负责“听”和“说”然后把听到的语音数据通过Wi-Fi或者4G模块发送到我们自己部署的SmallThinker-3B-Preview模型服务器上让这个模型来“思考”并生成回答最后再把回答文本传回STM32让它“说”出来或者显示出来。整个过程我们把复杂的“思考”工作交给了云端更强大的GPU而本地只做最擅长的实时采集和播放既保证了智能水平又把硬件成本压到了最低。2. 为什么选择这个组合在动手之前我们先聊聊为什么是STM32F103C8T6和SmallThinker-3B-Preview这对组合。这背后其实是一个很实际的工程权衡在有限的成本和资源下找到性能和功能的最佳平衡点。2.1 终端STM32F103C8T6最小系统板这块蓝色的小板子在电子爱好者和学生群体里几乎无人不知。选择它理由很充分成本极低核心板价格通常在十几到二十元人民币对于批量应用来说成本优势巨大。资源够用72MHz的主频20KB的RAM64KB的Flash。跑一个复杂的操作系统比如Linux肯定不行但运行一个实时操作系统RTOS或者裸机程序来处理语音采集ADC、数据打包、网络通信通过串口控制外挂模块、驱动一个小的OLED屏或者播放语音通过DAC或PWM是绰绰有余的。生态成熟无论是标准库还是HAL库资料、教程、社区支持都非常丰富开发门槛相对较低。各种传感器、通信模块如ESP8266 Wi-Fi模块、SIM800C 4G模块的驱动例程一抓一大把能极大缩短开发周期。低功耗潜力STM32系列优秀的低功耗特性使得这个终端在电池供电的便携设备或常驻设备中也能有不错的续航表现。简单说STM32F103C8T6在这里扮演了一个非常称职的“手脚”和“感官”角色它负责最前端的物理交互。2.2 “大脑”SmallThinker-3B-Preview模型那么“思考”的任务交给谁呢我们选择了SmallThinker-3B-Preview一个30亿参数级别的轻量化大语言模型。轻量且高效相比动辄百亿、千亿参数的大模型3B的规模在推理时对GPU显存的要求低得多。一块消费级的显卡比如RTX 3060 12GB就能流畅运行部署服务器的硬件成本可控。能力均衡虽然参数少但经过精心设计和训练的小模型在常见的对话、问答、指令理解等任务上已经能表现出令人满意的效果。对于智能家居的指令“打开客厅灯”、“明天天气怎么样”、简单的信息查询和闲聊完全够用。私有化部署这是最关键的一点。我们可以把模型部署在自己的服务器、甚至高性能PC上。这意味着数据不必经过第三方隐私和安全更有保障响应速度也取决于我们自己的网络和内网环境延迟可以做到很低。这个组合的核心思想就是“边缘感知云端思考”。把对实时性要求高的采集、播放任务放在资源受限但可靠的边缘端把对算力要求高的自然语言理解与生成任务放在资源可弹性扩展的云端。两者通过最通用的网络协议连接形成了一个灵活、可裁剪的架构。3. 系统设计与工作流程光说概念可能有点抽象我们把这个系统的“骨架”画出来看看它具体是怎么跑起来的。整个系统可以分为三个部分边缘终端、网络通道和云端服务。它们像一条流水线一样协同工作。[用户说话] -- (STM32终端) | v [麦克风采集音频] | v [音频预处理降噪、分帧、编码] | v [通过网络模块打包发送] | | (Wi-Fi / 4G) v (云端服务器) | v [接收音频数据解码] | v [语音识别 - 可选步骤] | v [文本送入SmallThinker模型推理] | v [生成回复文本] | v [将文本回复发送回终端] | | (Wi-Fi / 4G) v (STM32终端) | v [接收回复文本解析] | v [文本转语音合成 或 OLED屏显示] | v [用户听到/看到回复]3.1 边缘终端STM32F103C8T6的任务清单这块小板子要干好几件事我们可以用RTOS如FreeRTOS创建几个任务来分别处理语音采集任务通过ADC模块以固定的采样率比如16kHz读取麦克风模块如INMP441的数据存入缓冲区。音频预处理任务对原始音频数据进行简单的处理比如软件滤波降噪、分帧。为了减少网络传输的数据量通常会对音频进行编码压缩例如转换成OPUS、AMR-NB或简单的PCM流。STM32的算力做不了太复杂的编码但一些轻量级算法还是可以的或者也可以直接发送原始PCM数据数据量会大一些。网络通信任务这个任务负责与Wi-Fi模块如ESP-01S或4G模块如SIM800C通过串口UART通信。它把预处理好的音频数据按照自定义的协议例如在数据前加上帧头、长度、校验位打包通过AT指令集让模块发送到指定的云端服务器地址。响应处理任务监听网络模块的串口接收从云端返回的文本数据。解析协议后根据应用场景要么调用本地的TTS引擎可能需要外接一个简单的TTS合成芯片如SYN6288将文本转为语音播放要么将文本显示在连接的OLED屏幕上。3.2 云端服务端的任务清单云端服务器可以是一台带GPU的Linux服务器则负责“智力活”网络服务运行一个简单的Socket服务器可以用Python的socket库快速搭建监听特定端口接收来自无数个STM32终端发来的音频数据包。音频解码与ASR可选如果终端发送的是压缩编码的音频先将其解码为原始PCM。如果希望系统更通用可以在这里集成一个开源的语音识别ASR引擎如Vosk支持多种语言模型较小将音频转为文本。如果为了极致简化也可以约定终端发送的就是文本比如通过手机App输入跳过ASR步骤。模型推理服务这是核心。运行SmallThinker-3B-Preview的推理服务。可以使用FastAPI等框架封装一个API。当收到文本无论是直接来自终端还是经过ASR转换后将其构造成合适的Prompt例如“用户说{用户输入}。请以智能助手的身份回复”送入模型进行推理生成。响应返回将模型生成的回复文本通过同样的网络连接发回给对应的STM32终端。4. 关键环节的实现思路与代码片段了解了流程我们来看看几个关键环节具体怎么实现。这里会提供一些思路和简化版的代码示例。4.1 STM32端音频采集与网络发送假设我们使用STM32的ADC1以16kHz采样率采集麦克风数据并通过串口1控制ESP8266发送数据。首先是ADC的初始化和DMA采集// 伪代码基于HAL库 void ADC_Init_for_Audio(void) { ADC_ChannelConfTypeDef sConfig {0}; hadc1.Instance ADC1; hadc1.Init.ScanConvMode ADC_SCAN_DISABLE; hadc1.Init.ContinuousConvMode ENABLE; // 连续转换 hadc1.Init.DiscontinuousConvMode DISABLE; hadc1.Init.ExternalTrigConv ADC_SOFTWARE_START; // 软件触发 hadc1.Init.DataAlign ADC_DATAALIGN_RIGHT; hadc1.Init.NbrOfConversion 1; HAL_ADC_Init(hadc1); sConfig.Channel ADC_CHANNEL_0; // 假设接在PA0 sConfig.Rank ADC_REGULAR_RANK_1; sConfig.SamplingTime ADC_SAMPLETIME_28CYCLES_5; HAL_ADC_ConfigChannel(hadc1, sConfig); // 启动DMA传输将ADC数据循环存入一个缓冲区 HAL_ADC_Start_DMA(hadc1, (uint32_t*)audio_buffer, AUDIO_BUFFER_SIZE); }然后需要一个任务来处理这个缓冲区并打包发送// 在FreeRTOS任务中 void Audio_Net_Task(void *argument) { uint8_t net_packet[512]; // 自定义的网络包 uint16_t pkt_len 0; while(1) { // 1. 等待音频缓冲区满一个帧比如320字节20ms的数据 if (is_audio_frame_ready()) { // 2. 简单预处理例如计算能量过低则视为静音丢弃 if (compute_audio_energy(current_frame) SILENCE_THRESHOLD) { // 3. 构造协议包帧头(0xAA 0x55) 数据长度(2字节) 音频数据 校验和(1字节) net_packet[0] 0xAA; net_packet[1] 0x55; pkt_len FRAME_SIZE; net_packet[2] (pkt_len 8) 0xFF; net_packet[3] pkt_len 0xFF; memcpy(net_packet[4], current_frame, pkt_len); net_packet[4 pkt_len] calculate_checksum(net_packet, 4 pkt_len); // 4. 通过串口发送AT指令让ESP8266以TCP方式发送数据到服务器 // 例如ATCIPSENDlength\r\n然后发送net_packet send_to_esp8266_via_uart(net_packet, 5 pkt_len); } } vTaskDelay(pdMS_TO_TICKS(10)); // 适当延迟 } }4.2 云端使用Python搭建简单的推理服务云端服务器用Python写一个简单的服务接收数据并调用模型。# server.py - 一个非常简化的示例 import socket import threading from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 1. 加载SmallThinker模型和分词器 (假设已下载到本地) model_path ./SmallThinker-3B-Preview tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypetorch.float16, device_mapauto) model.eval() def handle_client(client_socket, addr): print(f[*] 接收到来自 {addr} 的连接) # 2. 接收数据 (这里简化协议实际需要解析帧头、长度等) data client_socket.recv(4096) if not data: return # 3. 假设接收到的就是UTF-8编码的文本如果传的是音频这里需先做ASR user_query data.decode(utf-8).strip() print(f[*] 用户输入: {user_query}) # 4. 构造Prompt并生成回复 prompt f用户说{user_query}\n请以智能助手的身份简洁回复 inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model.generate(**inputs, max_new_tokens100, do_sampleTrue, temperature0.7) response tokenizer.decode(outputs[0], skip_special_tokensTrue) # 截取模型生成的部分去掉Prompt assistant_response response.split(请以智能助手的身份简洁回复)[-1].strip() print(f[*] 模型回复: {assistant_response}) # 5. 将回复发送回客户端 client_socket.send(assistant_response.encode(utf-8)) client_socket.close() def start_server(): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind((0.0.0.0, 12345)) # 监听所有IP的12345端口 server.listen(5) print([*] 服务器监听在端口 12345) while True: client, addr server.accept() client_handler threading.Thread(targethandle_client, args(client, addr)) client_handler.start() if __name__ __main__: start_server()4.3 STM32端接收回复与TTS/显示STM32收到云端返回的文本后需要处理。// 在另一个FreeRTOS任务中监听ESP8266返回的数据 void Response_Handle_Task(void *argument) { uint8_t rx_buffer[256]; char response_text[200]; while(1) { // 1. 从串口读取ESP8266返回的数据包括IPD开头的TCP数据 if (uart_receive_from_esp8266(rx_buffer, len)) { // 2. 解析出纯文本回复这里需要根据ESP8266的返回格式和自定义协议解析 if (parse_tcp_response(rx_buffer, len, response_text)) { // 3. 根据模式处理回复 if (output_mode MODE_TTS) { // 调用TTS芯片通过UART发送合成指令如SYN6288 // 格式例如[0xFD 0x00 长度 文本... 校验和] send_to_tts_chip(response_text); } else if (output_mode MODE_DISPLAY) { // 在OLED屏幕上显示文本 OLED_Clear(); OLED_ShowString(0, 0, (uint8_t *)response_text); } } } vTaskDelay(pdMS_TO_TICKS(50)); } }5. 实际应用场景与优化思考这样一个系统能用在哪儿呢其实想象空间很大。智能家居中控做一个离线语音控制的开关面板不仅能执行“开灯关灯”的固定指令还能回答“今天需要浇花吗”这种需要结合天气API和模型推理的复杂问题。工业巡检助手巡检人员佩戴一个带有STM32和麦克风的设备看到设备时直接问“这台泵的额定功率是多少”模型可以从预置的设备知识库中查找并回答。低成本交互玩具/教育硬件给孩子做一个能对话、讲故事、回答问题的智能玩具成本可以控制得很低。信息查询终端在小区公告栏、商场导览处放置一个用户可以直接语音询问信息。当然这个基础方案还有很多可以优化的地方唤醒词与VAD可以集成一个轻量级的唤醒词引擎如Porcupine和语音活动检测VAD让设备只在听到唤醒词或检测到人声时才启动录音和上传节省流量和电量。协议优化使用更高效的二进制协议如MessagePack替代纯文本并加入心跳包、重传机制保证通信可靠性。边缘轻量ASR如果对隐私和实时性要求极高可以尝试在STM32上跑一个极轻量的语音识别模型如TensorFlow Lite for Microcontrollers将识别出的文本上传进一步减少数据量和云端依赖。上下文管理在云端服务中维护简单的对话上下文让模型能记住前几句对话实现多轮交互。6. 总结回过头来看这个基于STM32F103C8T6和SmallThinker-3B-Preview的方案其魅力不在于用了多尖端的技术而在于一种务实且灵活的架构思路。它巧妙地将计算密集型的大模型推理与对实时性、成本敏感的硬件终端解耦用最通用的网络连接起来形成了一个可扩展的“云边协同”系统。开发过程中最大的挑战可能不在于STM32的编程或者模型的部署而在于如何设计稳定、高效的通信协议以及如何处理好网络异常、数据丢包等现实问题。但正是解决这些“脏活累活”才让一个原型想法变成了真正可用的产品。如果你手头正好有一块吃灰的STM32F103C8T6最小系统板又想体验一下为大模型打造硬件入口的乐趣不妨从这个项目开始试试。从点亮一个LED到让设备听懂你的第一句话这个过程带来的成就感或许比单纯调用一个API要大得多。它让你真切地感受到智能不再飘在云端而是可以握在手里嵌入到我们身边任何一个平凡的物件之中。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
基于STM32F103C8T6与SmallThinker-3B-Preview的边缘AI语音交互系统设计
基于STM32F103C8T6与SmallThinker-3B-Preview的边缘AI语音交互系统设计1. 引言你有没有想过给家里一个几十块钱的智能开关或者小设备装上能听懂人话、还能跟你聊天的“大脑”听起来像是科幻电影里的情节但现在用一块常见的STM32F103C8T6最小系统板加上一个在云端跑起来的轻量级大模型就能把这个想法变成现实。传统的智能设备交互要么是简单的按键要么需要依赖手机App要么就是得喊一声“小X同学”把语音数据传到遥远的云端服务器去处理。这种方式不仅响应有延迟对网络依赖强而且一旦服务器出问题设备就变“哑巴”了。我们能不能做一个更独立、更快速、成本也更低的方案呢这篇文章要聊的就是这样一个“土法炼钢”但很实用的方案用STM32F103C8T6这块经典的“学生党神板”作为终端负责“听”和“说”然后把听到的语音数据通过Wi-Fi或者4G模块发送到我们自己部署的SmallThinker-3B-Preview模型服务器上让这个模型来“思考”并生成回答最后再把回答文本传回STM32让它“说”出来或者显示出来。整个过程我们把复杂的“思考”工作交给了云端更强大的GPU而本地只做最擅长的实时采集和播放既保证了智能水平又把硬件成本压到了最低。2. 为什么选择这个组合在动手之前我们先聊聊为什么是STM32F103C8T6和SmallThinker-3B-Preview这对组合。这背后其实是一个很实际的工程权衡在有限的成本和资源下找到性能和功能的最佳平衡点。2.1 终端STM32F103C8T6最小系统板这块蓝色的小板子在电子爱好者和学生群体里几乎无人不知。选择它理由很充分成本极低核心板价格通常在十几到二十元人民币对于批量应用来说成本优势巨大。资源够用72MHz的主频20KB的RAM64KB的Flash。跑一个复杂的操作系统比如Linux肯定不行但运行一个实时操作系统RTOS或者裸机程序来处理语音采集ADC、数据打包、网络通信通过串口控制外挂模块、驱动一个小的OLED屏或者播放语音通过DAC或PWM是绰绰有余的。生态成熟无论是标准库还是HAL库资料、教程、社区支持都非常丰富开发门槛相对较低。各种传感器、通信模块如ESP8266 Wi-Fi模块、SIM800C 4G模块的驱动例程一抓一大把能极大缩短开发周期。低功耗潜力STM32系列优秀的低功耗特性使得这个终端在电池供电的便携设备或常驻设备中也能有不错的续航表现。简单说STM32F103C8T6在这里扮演了一个非常称职的“手脚”和“感官”角色它负责最前端的物理交互。2.2 “大脑”SmallThinker-3B-Preview模型那么“思考”的任务交给谁呢我们选择了SmallThinker-3B-Preview一个30亿参数级别的轻量化大语言模型。轻量且高效相比动辄百亿、千亿参数的大模型3B的规模在推理时对GPU显存的要求低得多。一块消费级的显卡比如RTX 3060 12GB就能流畅运行部署服务器的硬件成本可控。能力均衡虽然参数少但经过精心设计和训练的小模型在常见的对话、问答、指令理解等任务上已经能表现出令人满意的效果。对于智能家居的指令“打开客厅灯”、“明天天气怎么样”、简单的信息查询和闲聊完全够用。私有化部署这是最关键的一点。我们可以把模型部署在自己的服务器、甚至高性能PC上。这意味着数据不必经过第三方隐私和安全更有保障响应速度也取决于我们自己的网络和内网环境延迟可以做到很低。这个组合的核心思想就是“边缘感知云端思考”。把对实时性要求高的采集、播放任务放在资源受限但可靠的边缘端把对算力要求高的自然语言理解与生成任务放在资源可弹性扩展的云端。两者通过最通用的网络协议连接形成了一个灵活、可裁剪的架构。3. 系统设计与工作流程光说概念可能有点抽象我们把这个系统的“骨架”画出来看看它具体是怎么跑起来的。整个系统可以分为三个部分边缘终端、网络通道和云端服务。它们像一条流水线一样协同工作。[用户说话] -- (STM32终端) | v [麦克风采集音频] | v [音频预处理降噪、分帧、编码] | v [通过网络模块打包发送] | | (Wi-Fi / 4G) v (云端服务器) | v [接收音频数据解码] | v [语音识别 - 可选步骤] | v [文本送入SmallThinker模型推理] | v [生成回复文本] | v [将文本回复发送回终端] | | (Wi-Fi / 4G) v (STM32终端) | v [接收回复文本解析] | v [文本转语音合成 或 OLED屏显示] | v [用户听到/看到回复]3.1 边缘终端STM32F103C8T6的任务清单这块小板子要干好几件事我们可以用RTOS如FreeRTOS创建几个任务来分别处理语音采集任务通过ADC模块以固定的采样率比如16kHz读取麦克风模块如INMP441的数据存入缓冲区。音频预处理任务对原始音频数据进行简单的处理比如软件滤波降噪、分帧。为了减少网络传输的数据量通常会对音频进行编码压缩例如转换成OPUS、AMR-NB或简单的PCM流。STM32的算力做不了太复杂的编码但一些轻量级算法还是可以的或者也可以直接发送原始PCM数据数据量会大一些。网络通信任务这个任务负责与Wi-Fi模块如ESP-01S或4G模块如SIM800C通过串口UART通信。它把预处理好的音频数据按照自定义的协议例如在数据前加上帧头、长度、校验位打包通过AT指令集让模块发送到指定的云端服务器地址。响应处理任务监听网络模块的串口接收从云端返回的文本数据。解析协议后根据应用场景要么调用本地的TTS引擎可能需要外接一个简单的TTS合成芯片如SYN6288将文本转为语音播放要么将文本显示在连接的OLED屏幕上。3.2 云端服务端的任务清单云端服务器可以是一台带GPU的Linux服务器则负责“智力活”网络服务运行一个简单的Socket服务器可以用Python的socket库快速搭建监听特定端口接收来自无数个STM32终端发来的音频数据包。音频解码与ASR可选如果终端发送的是压缩编码的音频先将其解码为原始PCM。如果希望系统更通用可以在这里集成一个开源的语音识别ASR引擎如Vosk支持多种语言模型较小将音频转为文本。如果为了极致简化也可以约定终端发送的就是文本比如通过手机App输入跳过ASR步骤。模型推理服务这是核心。运行SmallThinker-3B-Preview的推理服务。可以使用FastAPI等框架封装一个API。当收到文本无论是直接来自终端还是经过ASR转换后将其构造成合适的Prompt例如“用户说{用户输入}。请以智能助手的身份回复”送入模型进行推理生成。响应返回将模型生成的回复文本通过同样的网络连接发回给对应的STM32终端。4. 关键环节的实现思路与代码片段了解了流程我们来看看几个关键环节具体怎么实现。这里会提供一些思路和简化版的代码示例。4.1 STM32端音频采集与网络发送假设我们使用STM32的ADC1以16kHz采样率采集麦克风数据并通过串口1控制ESP8266发送数据。首先是ADC的初始化和DMA采集// 伪代码基于HAL库 void ADC_Init_for_Audio(void) { ADC_ChannelConfTypeDef sConfig {0}; hadc1.Instance ADC1; hadc1.Init.ScanConvMode ADC_SCAN_DISABLE; hadc1.Init.ContinuousConvMode ENABLE; // 连续转换 hadc1.Init.DiscontinuousConvMode DISABLE; hadc1.Init.ExternalTrigConv ADC_SOFTWARE_START; // 软件触发 hadc1.Init.DataAlign ADC_DATAALIGN_RIGHT; hadc1.Init.NbrOfConversion 1; HAL_ADC_Init(hadc1); sConfig.Channel ADC_CHANNEL_0; // 假设接在PA0 sConfig.Rank ADC_REGULAR_RANK_1; sConfig.SamplingTime ADC_SAMPLETIME_28CYCLES_5; HAL_ADC_ConfigChannel(hadc1, sConfig); // 启动DMA传输将ADC数据循环存入一个缓冲区 HAL_ADC_Start_DMA(hadc1, (uint32_t*)audio_buffer, AUDIO_BUFFER_SIZE); }然后需要一个任务来处理这个缓冲区并打包发送// 在FreeRTOS任务中 void Audio_Net_Task(void *argument) { uint8_t net_packet[512]; // 自定义的网络包 uint16_t pkt_len 0; while(1) { // 1. 等待音频缓冲区满一个帧比如320字节20ms的数据 if (is_audio_frame_ready()) { // 2. 简单预处理例如计算能量过低则视为静音丢弃 if (compute_audio_energy(current_frame) SILENCE_THRESHOLD) { // 3. 构造协议包帧头(0xAA 0x55) 数据长度(2字节) 音频数据 校验和(1字节) net_packet[0] 0xAA; net_packet[1] 0x55; pkt_len FRAME_SIZE; net_packet[2] (pkt_len 8) 0xFF; net_packet[3] pkt_len 0xFF; memcpy(net_packet[4], current_frame, pkt_len); net_packet[4 pkt_len] calculate_checksum(net_packet, 4 pkt_len); // 4. 通过串口发送AT指令让ESP8266以TCP方式发送数据到服务器 // 例如ATCIPSENDlength\r\n然后发送net_packet send_to_esp8266_via_uart(net_packet, 5 pkt_len); } } vTaskDelay(pdMS_TO_TICKS(10)); // 适当延迟 } }4.2 云端使用Python搭建简单的推理服务云端服务器用Python写一个简单的服务接收数据并调用模型。# server.py - 一个非常简化的示例 import socket import threading from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 1. 加载SmallThinker模型和分词器 (假设已下载到本地) model_path ./SmallThinker-3B-Preview tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypetorch.float16, device_mapauto) model.eval() def handle_client(client_socket, addr): print(f[*] 接收到来自 {addr} 的连接) # 2. 接收数据 (这里简化协议实际需要解析帧头、长度等) data client_socket.recv(4096) if not data: return # 3. 假设接收到的就是UTF-8编码的文本如果传的是音频这里需先做ASR user_query data.decode(utf-8).strip() print(f[*] 用户输入: {user_query}) # 4. 构造Prompt并生成回复 prompt f用户说{user_query}\n请以智能助手的身份简洁回复 inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model.generate(**inputs, max_new_tokens100, do_sampleTrue, temperature0.7) response tokenizer.decode(outputs[0], skip_special_tokensTrue) # 截取模型生成的部分去掉Prompt assistant_response response.split(请以智能助手的身份简洁回复)[-1].strip() print(f[*] 模型回复: {assistant_response}) # 5. 将回复发送回客户端 client_socket.send(assistant_response.encode(utf-8)) client_socket.close() def start_server(): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind((0.0.0.0, 12345)) # 监听所有IP的12345端口 server.listen(5) print([*] 服务器监听在端口 12345) while True: client, addr server.accept() client_handler threading.Thread(targethandle_client, args(client, addr)) client_handler.start() if __name__ __main__: start_server()4.3 STM32端接收回复与TTS/显示STM32收到云端返回的文本后需要处理。// 在另一个FreeRTOS任务中监听ESP8266返回的数据 void Response_Handle_Task(void *argument) { uint8_t rx_buffer[256]; char response_text[200]; while(1) { // 1. 从串口读取ESP8266返回的数据包括IPD开头的TCP数据 if (uart_receive_from_esp8266(rx_buffer, len)) { // 2. 解析出纯文本回复这里需要根据ESP8266的返回格式和自定义协议解析 if (parse_tcp_response(rx_buffer, len, response_text)) { // 3. 根据模式处理回复 if (output_mode MODE_TTS) { // 调用TTS芯片通过UART发送合成指令如SYN6288 // 格式例如[0xFD 0x00 长度 文本... 校验和] send_to_tts_chip(response_text); } else if (output_mode MODE_DISPLAY) { // 在OLED屏幕上显示文本 OLED_Clear(); OLED_ShowString(0, 0, (uint8_t *)response_text); } } } vTaskDelay(pdMS_TO_TICKS(50)); } }5. 实际应用场景与优化思考这样一个系统能用在哪儿呢其实想象空间很大。智能家居中控做一个离线语音控制的开关面板不仅能执行“开灯关灯”的固定指令还能回答“今天需要浇花吗”这种需要结合天气API和模型推理的复杂问题。工业巡检助手巡检人员佩戴一个带有STM32和麦克风的设备看到设备时直接问“这台泵的额定功率是多少”模型可以从预置的设备知识库中查找并回答。低成本交互玩具/教育硬件给孩子做一个能对话、讲故事、回答问题的智能玩具成本可以控制得很低。信息查询终端在小区公告栏、商场导览处放置一个用户可以直接语音询问信息。当然这个基础方案还有很多可以优化的地方唤醒词与VAD可以集成一个轻量级的唤醒词引擎如Porcupine和语音活动检测VAD让设备只在听到唤醒词或检测到人声时才启动录音和上传节省流量和电量。协议优化使用更高效的二进制协议如MessagePack替代纯文本并加入心跳包、重传机制保证通信可靠性。边缘轻量ASR如果对隐私和实时性要求极高可以尝试在STM32上跑一个极轻量的语音识别模型如TensorFlow Lite for Microcontrollers将识别出的文本上传进一步减少数据量和云端依赖。上下文管理在云端服务中维护简单的对话上下文让模型能记住前几句对话实现多轮交互。6. 总结回过头来看这个基于STM32F103C8T6和SmallThinker-3B-Preview的方案其魅力不在于用了多尖端的技术而在于一种务实且灵活的架构思路。它巧妙地将计算密集型的大模型推理与对实时性、成本敏感的硬件终端解耦用最通用的网络连接起来形成了一个可扩展的“云边协同”系统。开发过程中最大的挑战可能不在于STM32的编程或者模型的部署而在于如何设计稳定、高效的通信协议以及如何处理好网络异常、数据丢包等现实问题。但正是解决这些“脏活累活”才让一个原型想法变成了真正可用的产品。如果你手头正好有一块吃灰的STM32F103C8T6最小系统板又想体验一下为大模型打造硬件入口的乐趣不妨从这个项目开始试试。从点亮一个LED到让设备听懂你的第一句话这个过程带来的成就感或许比单纯调用一个API要大得多。它让你真切地感受到智能不再飘在云端而是可以握在手里嵌入到我们身边任何一个平凡的物件之中。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
