Esp32Robot入门05-大模型接口对接与配置（实战进阶：对接Qwen3.6-35B本地大模型与API配置实战）
Esp32Robot入门05-大模型接口对接与配置（实战进阶：对接Qwen3.6-35B本地大模型与API配置实战）
📌 文章简介：如何让 ESP32 机器人告别呆板的固定指令，拥有“幽默、贴心、秒懂”的 AI 灵魂？在完成了小智服务端网关的 Docker 部署后，本篇我们将深入实战，从本地 Ollama 一键拉起阿里千问大模型开始，手把手教你对接标准 OpenAI 兼容的大模型接口。我们将详细拆解网关服务端的 API 对接配置，并首度公开专门面向语音对话机器人的 System Prompt 黄金设计法，帮你彻底解决大段文本回复带来的“发音延迟”与“内存溢出”难题。文末还附带了一份极简的纯 Python 流式接口与首包延迟（TTFB）测速调试脚本，助你轻松驯服机器人的“本地大脑”！
1. 前言：给机器人一个“大脑”，让它懂得深度对话与幽默表达
在传统的智能硬件开发中，人机交互往往依赖于固化的规则引擎或关键字匹配。例如，当你说“开灯”时，单片机去控制继电器；当你说“今天天气怎么样”时，网关去请求一个天气 API 并生硬地朗读出来。这种交互模式冰冷、呆板，一旦用户说话的格式发生细微变化（如“能不能帮我把灯打开呀”），系统往往就会陷入无法识别的尴尬境地。
要让机器人真正“活”过来，成为一个会撒娇、会吐槽、能根据上下文进行幽默对话的“赛博生命”，我们就必须赋予它一个强大的“大脑”。这就是大语言模型（LLM）的用武之地。
在智能语音机器人的整体交互架构中，数据流是呈环形流动的。我们可以用以下链路来理解：
从上图可以看出，大语言模型（LLM）处于整个链路的核心决策地位。然而，语音对话场景下的 NLP 交互与我们在网页端使用 ChatGPT 聊天有巨大的不同：
- 口语噪音容忍度高：ASR 语音识别不可避免地会产生错别字、同音字或语气停顿（如“我…那个…想问下你那个啥”）。大模型必须具备极强的鲁棒性，能从充满噪音的语流中秒懂用户的真实意图。
- 极度苛刻的低延迟要求：在网页端，我们看着文字一个字一个字打印出来，等个 1~2 秒并不会觉得漫长。但在语音通话中，如果用户说完话后，机器人陷入了超过 1 秒的死寂，人机交互的顺畅感就会瞬间崩溃。
- 输出控制的严格性：如果大模型长篇大论，不仅会让语音合成（TTS）服务产生极大的延迟，还会撑爆 ESP32 极度紧张的硬件缓存。
因此，本篇我们将目光投向优秀的国产开源模型——阿里 Qwen（千问）大模型家族，并配合一键式本地部署神器 Ollama，共同打通我们机器人的“本地大脑”！
2. 本地 Ollama 千问大模型拉起
2.1 为什么选择 Ollama 与 Qwen？
在本地拉起大模型，很多硬件小白一看到 Python 环境、CUDA 驱动、PyTorch 依赖就头大。而 Ollama 则像大模型界的 Docker，它将模型的运行环境、权重文件打包成了一个个极简的镜像，支持在 Windows、macOS 以及 Linux 上一键拉起。
同时，阿里开源的 Qwen 系列模型，在中文口语理解、逻辑推理、指令遵循以及轻量化性能上，处于国内开源梯队的最顶端。针对不同的运行设备，我们可以根据显存/内存的大小，选择不同参数级别的 Qwen 模型：
| 硬件配置级别 | 推荐部署模型 | Ollama 拉起命令 | 首字响应延迟 (TTFB) | 对话智商与逻辑 | 适用场景 |
|---|---|---|---|---|---|
| 低配/调试级 (4G/8G 内存, CPU) |
Qwen2.5-1.5B | ollama run qwen2.5:1.5b |
~150ms | 基础对话、简单问答、控制指令 | 快速联调、边缘计算卡、老旧笔记本 |
| 中配/实用级 (16G 内存, RTX 3060/4060) |
Qwen2.5-7B | ollama run qwen2.5:7b |
~300ms | 良好，支持复杂逻辑与简单角色扮演 | 日常陪伴、智能家居 Agent 调度 |
| 高配/发烧级 (32G 内存, RTX 4090 或 Mac Studio) |
Qwen2.5-14B 或 Qwen2.5-32B |
ollama run qwen2.5:14bollama run qwen2.5:32b |
~600ms | 优秀，接近主流云端模型，推理能力极强 | 深度对话、复杂任务规划、写代码 |
| 企业/旗舰级 (专业显卡/集群) |
Qwen3.6-35B-A3B | 自定义 GGUF 导入或 API 对接 | ~800ms | 顶尖，极强的中文遵循能力与逻辑表达 | 商业展厅、前台机器人、专业顾问 |
[!TIP]
如果你的电脑没有独立显卡，或者内存小于 16GB，强烈建议使用qwen2.5:1.5b进行前期的硬件联调。虽然它的逻辑深度不如大参数模型，但在 CPU 上运行速度极快，首包延迟能控制在 200ms 以内，非常适合用来测试硬件音频流的顺畅度。
2.2 Ollama 极速安装与服务拉起
步骤 1：下载安装 Ollama
前往 Ollama 官网 下载对应你操作系统的安装包。安装完成后，Ollama 会在系统后台静默运行，并在任务栏托盘中显示它的可爱章鱼图标。
步骤 2：配置局域网跨主机监听（核心避坑）
默认情况下，Ollama 启动后只监听本地回环地址 127.0.0.1:11434。这意味着，如果你的小智网关部署在 Docker 容器内，或者你的机器人与电脑处于局域网内的不同设备上，它们将无法通过 IP 访问到 Ollama 接口。
为此，我们需要修改环境变量，强制 Ollama 监听 0.0.0.0：
- Windows 系统：
右键“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”。在系统变量中新建：- 变量名：
OLLAMA_HOST - 变量值：
0.0.0.0
配置完毕后，彻底退出 Ollama 客户端并重新双击启动。
- 变量名：
- macOS 系统：
在终端中执行以下命令，让配置写入 launchd 守护进程：
然后重启 Ollama 应用。launchctl setenv OLLAMA_HOST "0.0.0.0" - Linux 系统 (Systemd 服务管理)：
使用命令编辑服务配置文件：
在打开的空白处添加以下内容：sudo systemctl edit ollama.service
保存退出后，重载配置并重启服务：[Service] Environment="OLLAMA_HOST=0.0.0.0"sudo systemctl daemon-reload sudo systemctl restart ollama.service
步骤 3：一键下载并拉起模型
在终端中执行以下命令，Ollama 会自动从官方仓库下载千问 1.5B 权重，并直接在命令行中启动一个交互式的对话窗口：
ollama run qwen2.5:1.5b
当终端出现 >>> 提示符时，说明大模型已在本地加载成功！你可以试着输入：“你好，介绍一下你自己。” 观察它的回复速度。测试无误后，输入 /exit 退出交互窗口，Ollama 会继续在后台常驻服务。
2.3 检测服务连通性（CURL 实战）
Ollama 在后台运行时，默认会提供一套与 OpenAI 标准完全兼容的 API 接口。我们可以通过最基础的 curl 工具发送 HTTP 请求，来验证本地大模型的 Web API 接口是否正常通畅：
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen2.5:1.5b",
"messages": [
{"role": "user", "content": "你好，用一句话证明你是人工智能。"}
],
"stream": false
}'
如果服务连通，终端会在 100ms 内瞬间返回如下所示的标准 JSON 数据：
{
"id": "chatcmpl-346",
"object": "chat.completion",
"created": 1716377852,
"model": "qwen2.5:1.5b",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "你好！我是由阿里云训练的超大规模语言模型，旨在通过自然语言与你进行流畅的对话和高效的协助。"
},
"logprobs": null,
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 21,
"completion_tokens": 35,
"total_tokens": 56
}
}
返回 JSON 字段逐一剖析表：
对于网关开发或自定义开发，深入理解接口的返回结构是不可或缺的。下面是该 JSON 响应的详细字段解析：
| 字段名称 | 类型 | 说明 | 语音助手网关的关注点 |
|---|---|---|---|
id |
String | 本次对话的唯一请求 ID | 用于后台日志追踪、Debug 调试以及请求去重。 |
object |
String | 对象类型，通常固定为 chat.completion |
标准 OpenAI 格式校验，防止网关解析错乱。 |
created |
Integer | 请求创建时的 Unix 时间戳（秒级） | 用于计算从请求发出到大模型处理完毕所消耗的物理时间。 |
model |
String | 实际处理并响应请求的大模型名称 | 用于核对网关当前的路由逻辑是否正确分发到了指定模型。 |
choices |
Array | 大模型生成的候选项列表数组 | 核心文本提取区。语音助手网关必须读取并解析这个数组。 |
choices[0].message.content |
String | 大模型回复的具体文本内容 | 重中之重！该文本将被作为下一级语音合成（TTS）的直接输入。 |
choices[0].finish_reason |
String | 生成结束的原因，如 stop / length |
stop 代表正常生成完毕；length 代表超出网关设定的最大 Token 数被截断。 |
usage |
Object | Token 消耗统计，包含输入、输出及总计 | 用于评估本地显卡的计算吞吐率（比如每秒能跑多少个 Token）。 |
[!NOTE]
这里的 API 是标准的 OpenAI 兼容协议。这套协议是当今 AI 行业的黄金标准，意味着你今天为 Ollama 写的网关对接逻辑，未来可以直接零代码修改地平替为 DeepSeek、OpenAI、月之暗面（Kimi）等任何云端商业 API！
3. 网关服务端 API 对接配置
小智语音助手网关（xiaozhi-esp32-server）底层采用 Node.js 开发。它的核心逻辑是：实时接收 ESP32 发来的音频流 -> 调用 ASR 模块识别为文本 -> 将文本丢给 LLM API 拿到文本回答 -> 将文本送去 TTS 合成音频流 -> 通过 WebRTC 极速发给 ESP32。
要让网关使用我们刚刚在本地用 Ollama 拉起的 qwen2.5:1.5b，我们需要修改服务端的 config.json 配置文件。
3.1 完整的 config.json 生产级配置文件样例
请在你的网关安装目录下，找到或新建 config.json，并按照以下配置进行修改。
[!WARNING]
注意：JSON 标准协议中默认是不支持使用//这种双斜杠注释的。在实际复制以下代码并写入你的服务器配置文件时，请务必手动删去所有的中文注释，确保 JSON 格式合法！
{
"port": 8000,
"asr": {
"type": "whisper",
"model": "base.en",
"language": "zh"
},
"tts": {
"type": "cosyvoice",
"api_url": "http://localhost:50000/v1/tts",
"voice": "xiaozhi_voice"
},
"llm": {
"type": "openai",
"api_key": "ollama_placeholder_key",
"base_url": "http://127.0.0.1:11434/v1",
"model": "qwen2.5:1.5b",
"temperature": 0.7,
"max_tokens": 150,
"stream": true,
"system_prompt": "你是一个贴心、幽默、说话带有萌萌口语的智能语音小助手，你的名字叫小智。因为我的扬声器和网络带宽有限，你说话必须非常简练，字数严格控制在30到50个字以内，能用一句话说清楚就绝对不说第二句！回答中严禁包含任何Markdown符号、加粗符号、特殊标点、EMOJI表情或HTML标签，必须全部是能够流利朗读的中文文字。"
}
}
3.2 关键配置参数深度调优指南
type设置为"openai"：
虽然我们对接的是本地的 Ollama，但因为 Ollama 提供了 OpenAI 兼容层，所以它的驱动类型直接选"openai"即可。这比直接调用 Ollama 自研的/api/generate接口更具通用性。base_url的坑：- 如果你的小智网关和 Ollama 运行在同一台电脑上（非 Docker 环境），直接填
http://127.0.0.1:11434/v1即可。 - 如果你的网关是在 Docker 容器中运行的，而 Ollama 是安装在 Windows/macOS 主机上的，那么你需要将
127.0.0.1替换为宿主机的局域网 IP，或者在 Docker 容器里配置为http://host.docker.internal:11434/v1。
- 如果你的小智网关和 Ollama 运行在同一台电脑上（非 Docker 环境），直接填
stream必须设置为true：
这是语音对话成败的核心参数！如果设为false（非流式），网关必须等到本地大模型把整句话（比如 100 个字）完全吐完后，才能拿到响应，这会导致首字合成时间（TTFB）暴增到数秒。如果设为true，网关会在大模型吐出第一个字的瞬间，立刻将其送往流式 TTS，机器人几乎能在 200ms 内就发出声音，实现极为流畅的边说边想效果。
4. System Prompt 黄金设计与调优
很多开发者在网页端写 Prompt 得心应手，但当原封不动搬到 ESP32 语音机器人上时，却发现机器人的表现非常怪异、别扭。要么是说两句话就卡死，要么是说话断断续续。这其实是因为没有针对语音硬件的物理局限性进行 Prompt 优化。
4.1 痛点剖析：为什么语音机器人不能接受长篇大论？
⚠️ 痛点一：令人抓狂的首字节延迟（TTFB）
在文本大模型中，流式输出是以 Token（词块）为单位进行的。但是在语音合成（TTS）阶段，TTS 引擎为了发出连贯、带自然语气的真人声音，通常不能收到一个字就合成一个字。它需要至少读取完一个完整的子句（遇到逗号、句号、感叹号），通过上下文推理出情绪起伏后，才能开始进行高质 of 音频合成。
如果大模型的第一句话非常长（例如：“哦，亲爱的用户，这是一个非常好而且有深度的问题，关于你刚刚提到的ESP32单片机如何对接本地大模型这个话题，我将从以下十个维度为你做详细的展开阐述……”），TTS 引擎在遇到第一个句号前会处于“不断积压缓存”的状态，导致机器人长时间陷入可怕的沉默，严重破坏交互体验。
⚠️ 痛点二：ESP32 极度脆弱的内存溢出（OOM）
搭载 8MB PSRAM 的 ESP32-S3 虽然在嵌入式设备中算得上是“豪华配置”，但要实现高质量的 WebRTC 双向音频流传输，其内存利用率已经接近极限。
如果大模型回复了长达 500 字的小作文，网关需要将大量的音频 PCM 缓冲区进行队列积压，并源源不断地以高达 160Kbps 的码率向 ESP32 推送。一旦网络出现细微的抖动，ESP32 内部的音频 ringbuffer 缓冲区就会发生严重的“吞包”、“爆音”，甚至因为内存瞬间耗尽直接触发看门狗重启。
⚠️ 痛点三：人耳时序接受的“听觉疲劳”
人类获取信息的通道中，眼睛具有极高宽带（我们可以通过一目十行快速扫视大量文字），而耳朵则是单维的窄通道。当你戴着耳机听语音助手说话时，如果对方连续唠叨了 3 分钟，你大概率会感到烦躁不安，甚至想强行打断。对于硬件交互，“精炼、直接、口语化”是绝对的第一准则。
4.2 智能硬件专属：System Prompt 黄金设计法则
为了应对上述痛点，我们设计出了这套专为语音机器人优化的 System Prompt 框架，建议大家根据以下法则进行微调：
- 极端严格的字数限制：在 Prompt 开头必须用最高强度的命令限制输出字数。例如：“你的回答必须极端精炼，字数绝对、无条件限制在 30 到 50 个字以内！”
- 强制去除格式符号（符号净化）：大语言模型习惯输出 Markdown 的加粗符（
**重要**）、列表符（-）、表情符号（😊）以及代码块。当这些符号输入到 TTS 引擎中时，TTS 会产生严重的拼读错误（例如把**读成“星号星号”，或者被无法识别的特殊符号卡死）。所以必须在 Prompt 中写明：“严禁在回答中包含任何 Markdown 语法、Emoji 表情、特殊符号或 HTML 标签。” - 多用中文语气助词（增加人味）：为了让合成出来的声音不像没有感情的复读机，我们需要诱导大模型输出大量的口语语气词，例如“呀”、“哈喽”、“喵”、“哒”、“哦”。在 TTS 转换后，这些语气词会变成非常自然的叹息、升调，让人感觉暖心。
- 支持简易的人设角色扮演：例如你可以将其设定为一个傲娇的女仆，或是调皮的小猫娘，这会让每一次对话充满惊喜。
4.3 糟糕 Prompt vs 黄金 Prompt 对比效果表
为了让大家直观地感受调优的威力，我们对同一个问题（“天空为什么是蓝色的？”）在不同 Prompt 下的输出进行对比：
| 维度对比 | ❌ 糟糕的默认 Prompt（网页端思维） | 黄金语音优化 Prompt（智能硬件思维） |
|---|---|---|
| 大模型输出 | 这是一个关于物理学和光学的问题。天空之所以呈现蓝色，是因为太阳光是由红、橙、黄、绿、蓝、靛、紫七种颜色的光组成的。当太阳光穿过地球大气层时，会遇到空气分子和微小的尘埃。由于蓝色光的波长较短，它更容易被这些微小的粒子向四面八方散射，这种现象被称为瑞利散射（Rayleigh Scattering）。而红色光的波长较长，穿透力强，不易被散射。因此，当我们抬头看天空时，漫天被散射的蓝光就进入了我们的眼睛，让我们看到了蓝色的天空。 | 呀！这是因为太阳光里的蓝光波长比较短，在穿过大气层时被空气分子到处乱扔、向四面八方散射开啦，所以我们抬头看天空，就全都是漂亮的蓝色啦~ 明白了吗？ |
| 字数统计 | 204 字 | 42 字 |
| 首字播放延迟 (TTFB) | 约 3.8 秒（TTS 必须缓冲大量文本才能保证语调起伏） | 约 280 毫秒（短句极速切片，瞬间出声） |
| ESP32 缓冲区负载 | 极高，容易引起网络包积压和爆音。 | 极低，硬件运行丝滑、省电。 |
| 听觉交互体验 | 冰冷、冗长、像在背诵物理教科书，让人想立刻打断。 | 活泼、可爱、口语化、用通俗的语言秒懂知识。 |
5. Ollama 流式 API 调用测试源码 (Python)
在我们将配置正式更新到小智网关前，我们必须具备自主调试和评估大模型输出的能力。
下面是一份完整的、纯 Python 编写的本地大模型流式调用与性能测试脚本。它不需要你安装任何庞大的第三方 AI SDK（如 openai-python），仅仅依靠轻量级的 requests 库，就能实现底层的 Server-Sent Events (SSE) 流式数据接收，并能极其精准地测量出首字延迟（TTFB）与生成速率。
5.1 极简流式调试 Python 源码（含超详尽中文注释）
# -*- coding: utf-8 -*-
"""
文件名称: ollama_stream_test.py
描述: 专用于 ESP32 机器人对接本地大模型的 API 流式连通性与首包延迟 (TTFB) 测试脚本。
使用原生的 HTTP 流式传输，不依赖外部大型 API 包。
"""
import json
import time
import sys
import requests
def run_llm_voice_test(api_url, model, system_prompt, user_query):
"""
发送流式请求至本地大模型，模拟语音网关的调用流程，并精准统计性能指标。
"""
headers = {
"Content-Type": "application/json"
}
# 组装符合语音助手交互标准的 API 载荷
payload = {
"model": model,
"messages": [
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_query}
],
"stream": True, # 必须启用流式传输，这关乎语音的首字延迟
"temperature": 0.7, # 适度温度，保证对话既活泼又不会过于胡言乱语
"max_tokens": 150 # 严格限制最大 Token，防止模型突发性长篇大论
}
print("==================================================")
print("🚀 [硬件联调测试启动] 正在与本地大模型交互...")
print(f"📡 接口端点: {api_url}")
print(f"🧠 当前模型: {model}")
print(f"💬 玩家提问: {user_query}")
print("==================================================")
# 记录发起 HTTP 请求的物理时刻
start_time = time.time()
first_token_time = None
token_count = 0
full_response = []
try:
# 发送 POST 请求，必须指定 stream=True
response = requests.post(api_url, headers=headers, json=payload, stream=True, timeout=8)
if response.status_code != 200:
print(f"❌ 大模型服务响应异常，HTTP 状态码: {response.status_code}")
print(response.text)
return
# 实时逐行解析 Ollama 返回的 SSE (Server-Sent Events) 数据流
for chunk_line in response.iter_lines():
if not chunk_line:
continue
# 解码字节流为 UTF-8 字符串
decoded_text = chunk_line.decode('utf-8')
# 部分兼容 OpenAI 协议的接口会带有 "data: " 前缀，在此进行统一过滤与兼容
if decoded_text.startswith("data: "):
data_payload = decoded_text[6:]
else:
data_payload = decoded_text
# 捕获流式传输的正常结束标志 [DONE]
if data_payload.strip() == "[DONE]":
break
try:
# 解析单行 JSON 数据块
parsed_json = json.loads(data_payload)
# 兼容多种不同 API 格式（包括标准的 OpenAI choices 结构与 Ollama 原生结构）
delta_content = ""
if "choices" in parsed_json and len(parsed_json["choices"]) > 0:
delta = parsed_json["choices"][0].get("delta", {})
delta_content = delta.get("content", "")
elif "message" in parsed_json:
delta_content = parsed_json["message"].get("content", "")
elif "response" in parsed_json:
delta_content = parsed_json.get("response", "")
# 只有当模型真正吐出有效字符时，才计入统计
if delta_content:
# 关键里程碑：捕获并记录首个 Token 到达的时刻
if first_token_time is None:
first_token_time = time.time()
ttfb_ms = (first_token_time - start_time) * 1000
print(f"⚡ [首字延迟 (TTFB)] 👉 {ttfb_ms:.2f} 毫秒 👈 (语音合成黄金响应指标！)")
print("🤖 [机器人实时回答] : ", end="")
# 实时刷新终端屏幕，不带缓冲地输出文本 Token
sys.stdout.write(delta_content)
sys.stdout.flush()
# 累加 Token 计数与回答内容
token_count += 1
full_response.append(delta_content)
except json.JSONDecodeError:
# 忽略不合法的 JSON 碎片，防止程序崩溃
continue
end_time = time.time()
total_time = end_time - start_time
print("\n==================================================")
print("📊 [调优性能指标分析]")
print(f"⏱️ 请求到结束总耗时: {total_time:.3f} 秒")
if first_token_time:
# 计算纯粹的大模型推理时间（除去网络握手和首包加载）
inference_duration = end_time - first_token_time
tokens_per_second = token_count / inference_duration if inference_duration > 0 else 0
print(f"🚀 本地显卡推理速度: {tokens_per_second:.2f} Token/秒")
print(f"🔢 本次交互生成 Token 数量: {token_count} 个")
print(f"📝 完整纯净回复内容: {''.join(full_response)}")
else:
print("❌ 警告：大模型未输出任何有效字符，请检查显存占用或模型是否下载完整。")
print("==================================================")
except requests.exceptions.ConnectionError:
print("\n❌ 连接失败：无法与大模型服务建立连接。")
print("👉 请确保你的 Ollama 已经启动。运行命令测试：ollama list")
print(f"👉 请检查 API 地址是否被修改，当前配置地址为: {api_url}")
except Exception as err:
print(f"\n❌ 测试脚本发生非预期异常: {str(err)}")
if __name__ == "__main__":
# Ollama 本地服务的标准 OpenAI 兼容 Chat 端点
OLLAMA_API = "http://localhost:11434/v1/chat/completions"
# 推荐使用的本地测试模型。如果你下载了其他尺寸模型，在此直接修改名称即可
TEST_MODEL = "qwen2.5:1.5b"
# 针对语音合成（TTS）和硬件内存限制进行过极限调优的“黄金 System Prompt”
GOLDEN_SYSTEM_PROMPT = (
"你是一个贴心、幽默、说话带有萌萌口语的智能语音小助手，你的名字叫小智。"
"因为我的扬声器 and 网络带宽有限，你说话必须非常简练，字数严格控制在30到50个字以内，能用一句话说清楚就绝对不说第二句！"
"回答中严禁包含任何Markdown符号、加粗符号、特殊标点、EMOJI表情或HTML标签，必须全部是能够流利朗读的中文文字。"
"多用一些语气词，例如：'呀'、'哈喽~'、'喵~'、'哒'、'哦'，语气要轻松活泼！"
)
# 模拟用户语音输入转为文本后的提问
TEST_USER_QUERY = "你觉得今天的红烧肉好吃吗？"
# 运行实战测试
run_llm_voice_test(OLLAMA_API, TEST_MODEL, GOLDEN_SYSTEM_PROMPT, TEST_USER_QUERY)
5.2 如何运行此脚本进行 Prompt 调优？
- 安装核心依赖：
由于我们的脚本极致轻量，只需要安装 Python 的标准requests库即可：pip install requests -i https://pypi.tuna.tsinghua.edu.cn/simple - 启动本地大模型：
确保你已经在后台开启了 Ollama，并拉起了指定的模型：ollama run qwen2.5:1.5b - 执行测试脚本：
在终端中运行我们刚刚编写的测试脚本：python ollama_stream_test.py - 调试你的 Prompt：
通过修改TEST_USER_QUERY的提问，以及不断微调GOLDEN_SYSTEM_PROMPT的人设命令，你可以在终端中实时观察首字延迟 (TTFB) 的变化以及大模型输出的回答是否依然夹杂着*号、笑脸 Emoji 等语音“毒药”。当终端输出极其丝滑、速度飞快，且没有任何特殊乱码符号时，说明你已经完美降服了大模型，可以直接应用到小智机器人网关中啦！
✅ 本文总结
在本篇文章中，我们为 ESP32 智能机器人注入了真正的“AI 灵魂”：
- 打通本地大模型：使用 Ollama 一键拉起了阿里优秀的 Qwen 2.5/3.6 系列模型，并解决了局域网跨主机监听的配置难题。
- 网关 API 极速对接：通过修改小智网关的
config.json，实现了 OpenAI 标准兼容接口的流式（stream=True）无缝对接。 - 核心痛点攻克（语音 Prompt 黄金设计）：我们深刻剖析了语音机器人因为硬件 PSRAM 限制和 TTS 缓冲机制而产生的“发音延迟”与“内存溢出”致命伤。开箱即用地奉献了一套精炼、去 Markdown 符号、多语气词的智能硬件 System Prompt。
- 自主性能压测：使用一套纯 Python 编写的轻量级流式测试脚本，帮助我们量化了首包到达时间（TTFB），为后续的软硬件联调打下了极其坚实的工程基础！
📢 下一篇预告
大模型的大脑打通了，配置也搞定了！但是你是否好奇：机器人的声音和数据是如何穿透局域网和外网，以极其变态的毫秒级速度源源不断流式对讲的？ 为什么传统的 HTTP 或简单的 WebSocket 在这里不够快，而必须要请出大名鼎鼎的音视频实时通信王牌——WebRTC？
下一篇，我们将进入专栏中最核心的原理探索篇：
👉 《Esp32Robot入门06-语音通话协议WebRTC深度解析（原理剖析：硬件与大模型极速流式通话的底层秘密）》
我们将脱离枯燥的理论，用精美的手绘时序图、抓包数据分析和嵌入式源码，带你彻底解密实时语音通话在底层的低延迟极限传输之美！请大家备好咖啡，我们下期不见不散！
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
0
0- 0
已为社区贡献6条内容
所有评论(0)