这两年聊 AI大家总爱把大模型比作“最强大脑”把机器人的运动控制、端侧设备上的小模型比作“最强小脑”。但真正把项目落地之后你会发现大脑和小脑从来不是二选一的关系而是彼此需要。大模型确实很聪明能写代码、做推理、懂知识图谱但它在物理世界里是有明显短板的。它看不懂实时传感器数据无法在几十毫秒内完成一次设备动作也没法在断网的环境里独立工作。反过来端侧的小模型和传统控制层虽然反应快、功耗低、能离线运行可一遇到“帮我判断一下当前家里是否安全”这种需要语义理解的指令就完全使不上劲。这篇文章会从“大脑”和“小脑”的职责边界讲起分析为什么大模型必须依靠端侧执行层端侧执行层又为什么需要大模型的规划和推理能力。然后我会带大家搭建一个最小可运行的“大脑-小脑协同”系统大模型负责解析用户指令并生成结构化行动计划本地执行层负责控制设备、读取传感器让两者真正协同工作。1. 为什么“最强大脑”离不开“最强小脑”1.1 大模型的能力边界大模型尤其是近年来流行的 LLM大语言模型最擅长的事情是从海量文本中学习并掌握知识、语法、逻辑推理和任务规划。它能把一段模糊的自然语言转换成结构化指令比如用户说“帮我安排一下明天的会议”大模型能提取时间、地点、参与人并生成待办列表。但大模型也有一个无法回避的问题它本身不直接连接物理世界。它看不到摄像头画面读不到温度传感器的数值也不能直接控制继电器。要让大模型真正“动手做点什么”必须借助一层本地执行系统。另外大模型的推理成本和延迟也决定了它不适合做高频实时控制。一个复杂任务在大模型上可能需要几百毫秒甚至几秒才能返回结果而控制电机、读取传感器、执行工业安全逻辑这些场景往往要求毫秒级响应。如果每一步都依赖云端大模型系统不仅成本高还可能在网络抖动时直接失效。1.2 端侧“小脑”的价值“小脑”这个词从生物机制借过来指的是负责运动协调、平衡控制和实时反馈的部分。对应到工程系统里端侧“小脑”可以是端侧部署的小参数模型比如 1.5B、3B 的小语言模型。传统控制逻辑比如 PID、状态机、规则引擎。轻量级推理框架比如 ONNX Runtime、TensorFlow Lite、NCNN、MNN。小脑的特点是快、稳、省。它不依赖外部网络可以在本地完成传感器读取、动作执行、异常检测。它还能保护隐私因为原始数据不需要上传到云端。但是小脑也有天花板。它只能按照预设规则做判断很难泛化到没有见过的复杂场景。比如一个规则引擎可以做到“温度超过 28 度就开空调”但它理解不了“主人心情不好的时候不要把空调开太冷”这种抽象指令。1.3 两者为什么必须协同这里就回到了标题的核心最强大脑和最强小脑相互需要。大模型需要小脑是因为大模型不能只输出文字它需要有人把“想法”变成“动作”把“规划”变成“现实”。小脑需要大模型是因为小脑的判断能力有限它需要有人帮它理解复杂指令、制定决策策略、生成动态执行方案。用一个具身智能的例子来说明。要让机器人完成“把客厅桌子上的杯子拿给我”需要大脑负责解析目标物体是“杯子”。理解“桌子”和“客厅”的空间关系。拆解成导航、识别、抓取、运动控制等子任务。而真正执行时小脑负责驱动轮子和机械臂。在移动过程中做实时避障。根据摄像头画面动态调整抓取姿态。少了大脑机器人只会执行固定动作少了小脑机器人连一个简单的移动动作都完成不了。2. 核心概念大脑与小脑的定位划分2.1 大模型适合做什么在“大脑”这一级大模型最适合承担以下职责职责说明意图理解把自然语言变成任务意图任务规划把复杂任务拆解成有序子任务知识检索结合知识库、RAG 提供上下文信息异常决策遇到新问题时生成处理策略人机交互生成自然语言回复和用户沟通这类任务的特点是不需要极低延迟但需要较强的语义理解能力和泛化能力偶尔一次推理耗时几百毫秒是可以接受的。2.2 端侧小模型或控制层适合做什么在“小脑”这一级端侧模型或传统控制层则负责高频传感器数据采集与解析。毫秒级实时控制指令下发。离线状态下的基础逻辑兜底。低成本重复性判断。保护敏感数据避免原始数据上传云端。一个小脑系统可能并不需要大模型只需要规则但当它接收到大模型下发的动态任务序列时它的执行能力就会被充分放大。2.3 云边协同的典型拓扑在大脑-小脑协作架构中常见的拓扑如下用户输入 ↓ [大脑] 云端大模型 / 本地大模型 - 意图理解 - 任务规划 - 复杂推理 ↓ 输出结构化 JSON 动作序列 [小脑] 本地执行层 / 端侧小模型 - 设备控制 - 传感器读取 - 实时反馈 ↓ 执行结果 / 状态上报这里有一个设计要点大脑和小脑之间必须有一套明确约定的数据协议不能靠自然语言直接传递否则后续解析成本会很高。最常见的做法是让大模型输出 JSON 结构由本地执行层解析后逐条处理。3. 从大脑到小脑的关键技术3.1 模型压缩与端侧推理小脑要跑在低功耗设备上模型不能太大因此需要模型压缩技术。常见的思路包括量化把 FP32 权重转成 INT8 或 FP16减小体积提升推理速度。剪枝去掉网络中不重要的连接或通道。蒸馏用大模型当老师训练出参数量更小的学生模型。在实际项目中量化是最容易落地的。比如把一个大模型从 7B 量化到 4bit体积从约 14GB 缩小到约 4GB很多消费级设备就能跑起来。端侧推理框架选择也要根据平台来定框架特点适用场景ONNX Runtime跨平台支持多种硬件加速服务端、桌面端、部分移动端TensorFlow Lite移动端生态成熟Android、iOSNCNN腾讯开源轻量高效移动端、嵌入式MNN阿里开源移动端优化好Android、iOSllama.cpp适合运行量化后的大模型CPU、消费级 GPU、树莓派等3.2 知识蒸馏与数据回流“大脑”之所以能帮助“小脑”成长关键路径是数据回流。一个典型的闭环流程是用户提出自然语言指令。大脑大模型生成结构化的任务规划结果。小脑执行任务并把执行结果、状态变化、异常情况记录下来。把高质量的执行日志整理成训练数据。使用这些数据微调一个更小的端侧模型。端侧模型逐渐覆盖高频场景减少对云端的依赖。比如在智能家居场景中用户高频指令“打开客厅灯”会被大脑规划成{action: turn_on, device: living_room_light}。当这类数据积累到一定量就可以微调一个极小的端侧意图识别模型让它在本地直接输出相同结构省去一次云端调用。3.3 结构化协议大脑如何指挥小脑为了保证大脑与小脑协作顺畅需要定义动作协议。动作协议最少包含以下字段action动作类型。device目标设备。value或target目标值可选项。condition条件逻辑可选项。一个典型协议示例[ { action: turn_on, device: living_room_light }, { action: read_temperature, device: temperature_sensor }, { action: condition, metric: temperature, op: gt, value: 28, then: [ { action: turn_on, device: air_conditioner } ] } ]小脑模块只需要识别这些固定字段不需要理解自然语言。这样大脑负责“智力”小脑负责“执行力”职责非常清晰。4. 实战搭建一个大脑-小脑协同的控制系统下面我们用一个可运行的示例完整演示“最强大脑”和“最强小脑”的配合过程。4.1 场景与整体设计假设我们要实现一个智能家居助手。用户输入一句自然语言我回到家了请打开客厅灯如果室温超过 28 度就开启空调。系统会经历两个阶段大脑阶段大模型把指令转换成 JSON 动作序列。小脑阶段本地执行程序解析 JSON完成设备控制和传感器读取。为了演示方便我们不连接真实硬件而是用 Python 模拟灯泡、空调和温度传感器。4.2 项目结构brain-cerebellum-demo/ ├── brain.py # 大脑模块调用大模型生成任务规划 ├── cerebellum.py # 小脑模块执行设备控制逻辑 ├── orchestrator.py # 编排层串起大脑和小脑 └── requirements.txt # 依赖文件4.3 大脑模块大模型任务规划大脑模块的核心职责是调用大模型 API发送系统提示词和用户指令然后解析返回的 JSON。需要说明的是不同大模型的 API 地址和认证方式有差异所以下面代码采用环境变量配置并兼容 OpenAI 格式接口和 Ollama 本地模型。如果你使用的是其他模型服务可以按同样的协议替换。文件requirements.txtrequests2.31.0文件brain.pyimport json import os import requests class Brain: 大脑模块负责把自然语言指令转换为结构化的动作序列。 def __init__(self, api_keyNone, base_urlNone, modelNone): self.api_key api_key or os.getenv(LLM_API_KEY, ) self.base_url base_url or os.getenv(LLM_BASE_URL, https://api.openai.com/v1) self.model model or os.getenv(LLM_MODEL, gpt-4o-mini) def plan(self, user_instruction: str) - list: system_prompt 你是一个智能家居任务规划器。 请把用户的自然语言指令转换为 JSON 数组数组中的每一项是一个动作。 动作格式如下 1. {action: turn_on, device: living_room_light} 2. {action: turn_off, device: living_room_light} 3. {action: read_temperature, device: temperature_sensor} 4. {action: condition, metric: temperature, op: gt, value: 28, then: [{action: turn_on, device: air_conditioner}]} 要求 - 只输出 JSON不要输出任何解释文字。 - 如果用户没有明确要求不要臆造动作。 - 条件判断使用 condition 动作then 字段存放满足条件时要执行的动作数组。 url f{self.base_url}/chat/completions headers { Content-Type: application/json } if self.api_key: headers[Authorization] fBearer {self.api_key} payload { model: self.model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_instruction} ], temperature: 0 } response requests.post(url, headersheaders, jsonpayload, timeout30) response.raise_for_status() data response.json() content data[choices][0][message][content] # 清理模型可能输出的 Markdown 代码块 content content.strip() if content.startswith(): content content.split()[1] if content.startswith(json): content content[4:] content content.strip() return json.loads(content)这段代码里有几个细节值得注意。第一temperature设置为 0是为了让大模型输出尽量稳定。在任务规划场景里我们要的是确定性不需要模型发散。第二系统提示词里明确写清楚动作格式和约束条件这是让大模型稳定输出 JSON 的关键。如果你发现模型经常输出多余文字可以继续强化提示词比如加上“不允许输出 JSON 之外的任何内容”。第三代码兼容两种运行方式。如果使用 OpenAI 官方 API就设置LLM_API_KEY如果使用 Ollama 本地模型可以把LLM_BASE_URL设置为http://localhost:11434/v1LLM_MODEL设置为本地模型名此时可以不设置 API Key。4.4 小脑模块本地设备执行小脑模块不需要理解自然语言它只负责执行大脑下发的结构化动作序列。文件cerebellum.pyimport random class Cerebellum: 小脑模块负责执行动作序列、读取传感器、控制设备状态。 def __init__(self): self.devices { living_room_light: False, air_conditioner: False } self.temperature 26.5 def execute(self, plan: list) - list: 按顺序执行大脑返回的动作序列。 results [] for step in plan: action step.get(action) if action turn_on: device step[device] self.devices[device] True results.append({device: device, status: on, ok: True}) elif action turn_off: device step[device] self.devices[device] False results.append({device: device, status: off, ok: True}) elif action read_temperature: # 模拟真实传感器读数波动 self.temperature round(random.uniform(22.0, 32.0), 1) results.append({ device: step[device], temperature: self.temperature, ok: True }) elif action condition: metric step[metric] op step[op] value step[value] current getattr(self, metric, None) if current is None: results.append({action: condition, error: unknown metric, ok: False}) continue if (op gt and current value) or (op lt and current value): sub_plan step[then] sub_results self.execute(sub_plan) results.extend(sub_results) else: results.append({ condition: f{metric} {op} {value}, matched: False, ok: True }) else: results.append({ action: action, error: unknown action, ok: False }) return results小脑模块用字典devices记录设备开关状态用temperature记录当前室温。read_temperature这里使用随机数模拟传感器波动真实项目中应该替换为实际硬件读取代码。condition动作是最有价值的部分。它读取当前温度判断是否满足条件如果满足就递归执行then里的子动作。这样大脑只需要输出判断条件小脑负责具体判断和执行。4.5 编排层串起大脑和小脑编排层是系统的入口它先调用大脑拿到计划再交给小脑执行。文件orchestrator.pyimport json from brain import Brain from cerebellum import Cerebellum def main(): user_instruction input(请输入指令) brain Brain() plan brain.plan(user_instruction) print(大脑规划结果) print(json.dumps(plan, ensure_asciiFalse, indent2)) cerebellum Cerebellum() results cerebellum.execute(plan) print(\n小脑执行结果) for result in results: print(json.dumps(result, ensure_asciiFalse)) print(\n当前设备状态) print(json.dumps(cerebellum.devices, ensure_asciiFalse, indent2)) print(当前室温, cerebellum.temperature) if __name__ __main__: main()这里刻意把大脑和小脑解耦。你可以只替换Brain的实现比如把云端大模型换成端侧小模型而不需要修改小脑代码。你也可以把Cerebellum替换成真实硬件控制库而大脑不需要感知硬件变化。4.6 运行与验证启动前需要配置环境变量。以 OpenAI 官方接口为例export LLM_API_KEY你的API_Key export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini如果使用 Ollama 本地模型export LLM_API_KEY export LLM_BASE_URLhttp://localhost:11434/v1 export LLM_MODELqwen2.5:3b安装依赖并运行pip install -r requirements.txt python orchestrator.py输入指令我回到家了请打开客厅灯如果室温超过 28 度就开启空调。运行结果类似大脑规划结果 [ { action: turn_on, device: living_room_light }, { action: read_temperature, device: temperature_sensor }, { action: condition, metric: temperature, op: gt, value: 28, then: [ { action: turn_on, device: air_conditioner } ] } ] 小脑执行结果 {device: living_room_light, status: on, ok: true} {device: temperature_sensor, temperature: 28.9, ok: true} {device: air_conditioner, status: on, ok: true} 当前设备状态 { living_room_light: true, air_conditioner: true } 当前室温 28.9由于温度是随机模拟的第二次运行可能会因为温度低于 28 度而出现空调未开启的结果这正好体现了“小脑结合实时数据做判断”的价值。如果大模型输出了不合法的 JSONjson.loads会直接抛异常。这种问题在真实项目里很常见下一节我会专门讲排查方法。5. 进阶让端侧小模型真正成为“小脑”前面的示例中小脑是纯规则逻辑还没有用到端侧模型。在实际工程中我们希望部分判断能力也能放到端侧。一个典型的场景是室内人体检测。摄像头采集画面后小脑端侧模型判断“是否有人”然后把结果上报给大脑。大脑不需要实时看视频只需要收状态这样既降低带宽压力也保护用户隐私。端侧模型的部署方式大同小异核心流程是训练或蒸馏得到一个较小的模型。转换为 ONNX 或 TFLite 格式。使用端侧推理框架加载模型。在本地实时推理并输出结果。以 ONNX Runtime 为例加载一个分类模型的代码片段如下import onnxruntime as ort import numpy as np # 加载 ONNX 模型 session ort.InferenceSession(person_detector.onnx, providers[CPUExecutionProvider]) # 假设输入 shape 为 [1, 3, 224, 224] input_name session.get_inputs()[0].name input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # 推理 outputs session.run(None, {input_name: input_data}) print(outputs[0])这段代码只是展示基本流程。真实项目中你需要准备模型文件、预处理图像、解析输出结果。如果是做人体检测建议使用 YOLO 系列目标检测模型输出的是边界框和置信度。你可以把上面这段推理代码封装进Cerebellum让它在执行某个动作时自动调用。这样一来小脑不仅会执行规则还拥有了“感知能力”离真正的“最强小脑”就更近了一步。6. 常见问题与排查思路在实战中大脑-小脑协同最常见的坑可以整理成下面这张表。问题现象常见原因解决思路大脑接口请求超时网络不稳定或模型推理时间过长设置合理超时时间开启流式输出增加缓存模型返回内容无法解析成 JSON大模型输出了解释文字或 Markdown 代码块在系统提示词中强化格式约束返回后做清理后处理设备执行成功但状态未更新控制层与硬件之间存在通信延迟增加设备状态确认机制执行后主动回读状态传感器读数波动很大传感器噪声或环境干扰多次采样取均值使用滤波算法端侧小模型推理效果差训练数据不足或数据分布不匹配使用蒸馏数据回流持续微调小模型本地资源不足模型过大或推理框架未做加速使用量化模型开启 GPU/NPU 加速用户敏感数据上了云端所有数据都调用云端 API在端侧做数据过滤、脱敏只上传必要信息排查顺序建议如下先看大脑返回的原始内容是什么确认是不是 JSON。再检查协议字段是否匹配比如小脑代码里读取的字段名是否和大模型输出一致。接着检查小脑执行日志看设备动作是否真的触发。最后检查环境差异比如本地依赖版本、硬件权限、网络连通性。7. 最佳实践与工程建议在实际项目中要让“最强大脑”和“最强小脑”稳定协作我认为有这几点值得重视。7.1 协议先行再写代码大脑和小脑之间的 JSON 协议是整个系统的“接口契约”。项目启动时应该先用 JSON Schema 或文档把它固定下来避免开发过程中两边各改各的。协议设计要尽量简单。动作类型越少越好能用turn_on、turn_off、read_temperature表达清楚的就不要引入复杂的嵌套结构。条件判断虽然是协议的一部分但也要控制嵌套层数否则小脑解析代码会变得很难维护。7.2 可观测性比功能更重要由于系统链路比较长任何一个环节出错都不容易定位。建议至少记录以下内容用户原始指令。大脑返回的完整 JSON。小脑执行每一步的结果。设备最终状态。每次调用的耗时。日志最好带上任务 ID方便把一条完整链路的日志串联起来。7.3 做好超时、重试和降级云端大模型调用必须设置超时时间。建议把超时分成两档普通任务 15 到 30 秒复杂任务可以更长。超时后要有重试机制但重试次数不宜过多否则会造成雪崩。降级策略同样重要。当大脑不可用时小脑可以切到预置规则模式。例如之前总结过“温度超过 28 度就开空调”这本身就是一条可靠的本地规则不需要大脑参与也能执行。7.4 安全与隐私是不可触碰的底线真实场景中小脑采集到的原始数据是否上传云端一定要在设计阶段就明确。比如摄像头画面、用户声音、家庭传感器数据都属于敏感信息能本地处理就不要上传。设备控制类的指令应该加上权限校验。不能因为小脑执行了大模型下发的动作就省略授权环节。尤其是涉及门锁、电闸、燃气阀等高风险设备时必须做二次确认。7.5 持续用数据喂养小脑“小脑”不是一成不变的。每次大脑的规划结果、小脑的执行反馈都是非常有价值的训练数据。项目上线后建议定期把高质量的执行日志清洗出来用于微调端侧模型。这个闭环一旦跑通系统会越用越聪明。高频任务逐渐被本地小模型接管云端大模型只处理真正复杂和低频的请求成本和响应速度都会得到明显改善。如果大家在自己的本地环境里跑这个“大脑-小脑”示例时遇到问题欢迎在评论区留言交流。下一篇我可以继续写端侧小模型微调、以及如何把 RAG 接入这套架构的完整实操感兴趣的话可以先点个收藏方便后续查找。 大模型与端侧小脑协同：从原理到实战搭建智能控制系统
这两年聊 AI大家总爱把大模型比作“最强大脑”把机器人的运动控制、端侧设备上的小模型比作“最强小脑”。但真正把项目落地之后你会发现大脑和小脑从来不是二选一的关系而是彼此需要。大模型确实很聪明能写代码、做推理、懂知识图谱但它在物理世界里是有明显短板的。它看不懂实时传感器数据无法在几十毫秒内完成一次设备动作也没法在断网的环境里独立工作。反过来端侧的小模型和传统控制层虽然反应快、功耗低、能离线运行可一遇到“帮我判断一下当前家里是否安全”这种需要语义理解的指令就完全使不上劲。这篇文章会从“大脑”和“小脑”的职责边界讲起分析为什么大模型必须依靠端侧执行层端侧执行层又为什么需要大模型的规划和推理能力。然后我会带大家搭建一个最小可运行的“大脑-小脑协同”系统大模型负责解析用户指令并生成结构化行动计划本地执行层负责控制设备、读取传感器让两者真正协同工作。1. 为什么“最强大脑”离不开“最强小脑”1.1 大模型的能力边界大模型尤其是近年来流行的 LLM大语言模型最擅长的事情是从海量文本中学习并掌握知识、语法、逻辑推理和任务规划。它能把一段模糊的自然语言转换成结构化指令比如用户说“帮我安排一下明天的会议”大模型能提取时间、地点、参与人并生成待办列表。但大模型也有一个无法回避的问题它本身不直接连接物理世界。它看不到摄像头画面读不到温度传感器的数值也不能直接控制继电器。要让大模型真正“动手做点什么”必须借助一层本地执行系统。另外大模型的推理成本和延迟也决定了它不适合做高频实时控制。一个复杂任务在大模型上可能需要几百毫秒甚至几秒才能返回结果而控制电机、读取传感器、执行工业安全逻辑这些场景往往要求毫秒级响应。如果每一步都依赖云端大模型系统不仅成本高还可能在网络抖动时直接失效。1.2 端侧“小脑”的价值“小脑”这个词从生物机制借过来指的是负责运动协调、平衡控制和实时反馈的部分。对应到工程系统里端侧“小脑”可以是端侧部署的小参数模型比如 1.5B、3B 的小语言模型。传统控制逻辑比如 PID、状态机、规则引擎。轻量级推理框架比如 ONNX Runtime、TensorFlow Lite、NCNN、MNN。小脑的特点是快、稳、省。它不依赖外部网络可以在本地完成传感器读取、动作执行、异常检测。它还能保护隐私因为原始数据不需要上传到云端。但是小脑也有天花板。它只能按照预设规则做判断很难泛化到没有见过的复杂场景。比如一个规则引擎可以做到“温度超过 28 度就开空调”但它理解不了“主人心情不好的时候不要把空调开太冷”这种抽象指令。1.3 两者为什么必须协同这里就回到了标题的核心最强大脑和最强小脑相互需要。大模型需要小脑是因为大模型不能只输出文字它需要有人把“想法”变成“动作”把“规划”变成“现实”。小脑需要大模型是因为小脑的判断能力有限它需要有人帮它理解复杂指令、制定决策策略、生成动态执行方案。用一个具身智能的例子来说明。要让机器人完成“把客厅桌子上的杯子拿给我”需要大脑负责解析目标物体是“杯子”。理解“桌子”和“客厅”的空间关系。拆解成导航、识别、抓取、运动控制等子任务。而真正执行时小脑负责驱动轮子和机械臂。在移动过程中做实时避障。根据摄像头画面动态调整抓取姿态。少了大脑机器人只会执行固定动作少了小脑机器人连一个简单的移动动作都完成不了。2. 核心概念大脑与小脑的定位划分2.1 大模型适合做什么在“大脑”这一级大模型最适合承担以下职责职责说明意图理解把自然语言变成任务意图任务规划把复杂任务拆解成有序子任务知识检索结合知识库、RAG 提供上下文信息异常决策遇到新问题时生成处理策略人机交互生成自然语言回复和用户沟通这类任务的特点是不需要极低延迟但需要较强的语义理解能力和泛化能力偶尔一次推理耗时几百毫秒是可以接受的。2.2 端侧小模型或控制层适合做什么在“小脑”这一级端侧模型或传统控制层则负责高频传感器数据采集与解析。毫秒级实时控制指令下发。离线状态下的基础逻辑兜底。低成本重复性判断。保护敏感数据避免原始数据上传云端。一个小脑系统可能并不需要大模型只需要规则但当它接收到大模型下发的动态任务序列时它的执行能力就会被充分放大。2.3 云边协同的典型拓扑在大脑-小脑协作架构中常见的拓扑如下用户输入 ↓ [大脑] 云端大模型 / 本地大模型 - 意图理解 - 任务规划 - 复杂推理 ↓ 输出结构化 JSON 动作序列 [小脑] 本地执行层 / 端侧小模型 - 设备控制 - 传感器读取 - 实时反馈 ↓ 执行结果 / 状态上报这里有一个设计要点大脑和小脑之间必须有一套明确约定的数据协议不能靠自然语言直接传递否则后续解析成本会很高。最常见的做法是让大模型输出 JSON 结构由本地执行层解析后逐条处理。3. 从大脑到小脑的关键技术3.1 模型压缩与端侧推理小脑要跑在低功耗设备上模型不能太大因此需要模型压缩技术。常见的思路包括量化把 FP32 权重转成 INT8 或 FP16减小体积提升推理速度。剪枝去掉网络中不重要的连接或通道。蒸馏用大模型当老师训练出参数量更小的学生模型。在实际项目中量化是最容易落地的。比如把一个大模型从 7B 量化到 4bit体积从约 14GB 缩小到约 4GB很多消费级设备就能跑起来。端侧推理框架选择也要根据平台来定框架特点适用场景ONNX Runtime跨平台支持多种硬件加速服务端、桌面端、部分移动端TensorFlow Lite移动端生态成熟Android、iOSNCNN腾讯开源轻量高效移动端、嵌入式MNN阿里开源移动端优化好Android、iOSllama.cpp适合运行量化后的大模型CPU、消费级 GPU、树莓派等3.2 知识蒸馏与数据回流“大脑”之所以能帮助“小脑”成长关键路径是数据回流。一个典型的闭环流程是用户提出自然语言指令。大脑大模型生成结构化的任务规划结果。小脑执行任务并把执行结果、状态变化、异常情况记录下来。把高质量的执行日志整理成训练数据。使用这些数据微调一个更小的端侧模型。端侧模型逐渐覆盖高频场景减少对云端的依赖。比如在智能家居场景中用户高频指令“打开客厅灯”会被大脑规划成{action: turn_on, device: living_room_light}。当这类数据积累到一定量就可以微调一个极小的端侧意图识别模型让它在本地直接输出相同结构省去一次云端调用。3.3 结构化协议大脑如何指挥小脑为了保证大脑与小脑协作顺畅需要定义动作协议。动作协议最少包含以下字段action动作类型。device目标设备。value或target目标值可选项。condition条件逻辑可选项。一个典型协议示例[ { action: turn_on, device: living_room_light }, { action: read_temperature, device: temperature_sensor }, { action: condition, metric: temperature, op: gt, value: 28, then: [ { action: turn_on, device: air_conditioner } ] } ]小脑模块只需要识别这些固定字段不需要理解自然语言。这样大脑负责“智力”小脑负责“执行力”职责非常清晰。4. 实战搭建一个大脑-小脑协同的控制系统下面我们用一个可运行的示例完整演示“最强大脑”和“最强小脑”的配合过程。4.1 场景与整体设计假设我们要实现一个智能家居助手。用户输入一句自然语言我回到家了请打开客厅灯如果室温超过 28 度就开启空调。系统会经历两个阶段大脑阶段大模型把指令转换成 JSON 动作序列。小脑阶段本地执行程序解析 JSON完成设备控制和传感器读取。为了演示方便我们不连接真实硬件而是用 Python 模拟灯泡、空调和温度传感器。4.2 项目结构brain-cerebellum-demo/ ├── brain.py # 大脑模块调用大模型生成任务规划 ├── cerebellum.py # 小脑模块执行设备控制逻辑 ├── orchestrator.py # 编排层串起大脑和小脑 └── requirements.txt # 依赖文件4.3 大脑模块大模型任务规划大脑模块的核心职责是调用大模型 API发送系统提示词和用户指令然后解析返回的 JSON。需要说明的是不同大模型的 API 地址和认证方式有差异所以下面代码采用环境变量配置并兼容 OpenAI 格式接口和 Ollama 本地模型。如果你使用的是其他模型服务可以按同样的协议替换。文件requirements.txtrequests2.31.0文件brain.pyimport json import os import requests class Brain: 大脑模块负责把自然语言指令转换为结构化的动作序列。 def __init__(self, api_keyNone, base_urlNone, modelNone): self.api_key api_key or os.getenv(LLM_API_KEY, ) self.base_url base_url or os.getenv(LLM_BASE_URL, https://api.openai.com/v1) self.model model or os.getenv(LLM_MODEL, gpt-4o-mini) def plan(self, user_instruction: str) - list: system_prompt 你是一个智能家居任务规划器。 请把用户的自然语言指令转换为 JSON 数组数组中的每一项是一个动作。 动作格式如下 1. {action: turn_on, device: living_room_light} 2. {action: turn_off, device: living_room_light} 3. {action: read_temperature, device: temperature_sensor} 4. {action: condition, metric: temperature, op: gt, value: 28, then: [{action: turn_on, device: air_conditioner}]} 要求 - 只输出 JSON不要输出任何解释文字。 - 如果用户没有明确要求不要臆造动作。 - 条件判断使用 condition 动作then 字段存放满足条件时要执行的动作数组。 url f{self.base_url}/chat/completions headers { Content-Type: application/json } if self.api_key: headers[Authorization] fBearer {self.api_key} payload { model: self.model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_instruction} ], temperature: 0 } response requests.post(url, headersheaders, jsonpayload, timeout30) response.raise_for_status() data response.json() content data[choices][0][message][content] # 清理模型可能输出的 Markdown 代码块 content content.strip() if content.startswith(): content content.split()[1] if content.startswith(json): content content[4:] content content.strip() return json.loads(content)这段代码里有几个细节值得注意。第一temperature设置为 0是为了让大模型输出尽量稳定。在任务规划场景里我们要的是确定性不需要模型发散。第二系统提示词里明确写清楚动作格式和约束条件这是让大模型稳定输出 JSON 的关键。如果你发现模型经常输出多余文字可以继续强化提示词比如加上“不允许输出 JSON 之外的任何内容”。第三代码兼容两种运行方式。如果使用 OpenAI 官方 API就设置LLM_API_KEY如果使用 Ollama 本地模型可以把LLM_BASE_URL设置为http://localhost:11434/v1LLM_MODEL设置为本地模型名此时可以不设置 API Key。4.4 小脑模块本地设备执行小脑模块不需要理解自然语言它只负责执行大脑下发的结构化动作序列。文件cerebellum.pyimport random class Cerebellum: 小脑模块负责执行动作序列、读取传感器、控制设备状态。 def __init__(self): self.devices { living_room_light: False, air_conditioner: False } self.temperature 26.5 def execute(self, plan: list) - list: 按顺序执行大脑返回的动作序列。 results [] for step in plan: action step.get(action) if action turn_on: device step[device] self.devices[device] True results.append({device: device, status: on, ok: True}) elif action turn_off: device step[device] self.devices[device] False results.append({device: device, status: off, ok: True}) elif action read_temperature: # 模拟真实传感器读数波动 self.temperature round(random.uniform(22.0, 32.0), 1) results.append({ device: step[device], temperature: self.temperature, ok: True }) elif action condition: metric step[metric] op step[op] value step[value] current getattr(self, metric, None) if current is None: results.append({action: condition, error: unknown metric, ok: False}) continue if (op gt and current value) or (op lt and current value): sub_plan step[then] sub_results self.execute(sub_plan) results.extend(sub_results) else: results.append({ condition: f{metric} {op} {value}, matched: False, ok: True }) else: results.append({ action: action, error: unknown action, ok: False }) return results小脑模块用字典devices记录设备开关状态用temperature记录当前室温。read_temperature这里使用随机数模拟传感器波动真实项目中应该替换为实际硬件读取代码。condition动作是最有价值的部分。它读取当前温度判断是否满足条件如果满足就递归执行then里的子动作。这样大脑只需要输出判断条件小脑负责具体判断和执行。4.5 编排层串起大脑和小脑编排层是系统的入口它先调用大脑拿到计划再交给小脑执行。文件orchestrator.pyimport json from brain import Brain from cerebellum import Cerebellum def main(): user_instruction input(请输入指令) brain Brain() plan brain.plan(user_instruction) print(大脑规划结果) print(json.dumps(plan, ensure_asciiFalse, indent2)) cerebellum Cerebellum() results cerebellum.execute(plan) print(\n小脑执行结果) for result in results: print(json.dumps(result, ensure_asciiFalse)) print(\n当前设备状态) print(json.dumps(cerebellum.devices, ensure_asciiFalse, indent2)) print(当前室温, cerebellum.temperature) if __name__ __main__: main()这里刻意把大脑和小脑解耦。你可以只替换Brain的实现比如把云端大模型换成端侧小模型而不需要修改小脑代码。你也可以把Cerebellum替换成真实硬件控制库而大脑不需要感知硬件变化。4.6 运行与验证启动前需要配置环境变量。以 OpenAI 官方接口为例export LLM_API_KEY你的API_Key export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini如果使用 Ollama 本地模型export LLM_API_KEY export LLM_BASE_URLhttp://localhost:11434/v1 export LLM_MODELqwen2.5:3b安装依赖并运行pip install -r requirements.txt python orchestrator.py输入指令我回到家了请打开客厅灯如果室温超过 28 度就开启空调。运行结果类似大脑规划结果 [ { action: turn_on, device: living_room_light }, { action: read_temperature, device: temperature_sensor }, { action: condition, metric: temperature, op: gt, value: 28, then: [ { action: turn_on, device: air_conditioner } ] } ] 小脑执行结果 {device: living_room_light, status: on, ok: true} {device: temperature_sensor, temperature: 28.9, ok: true} {device: air_conditioner, status: on, ok: true} 当前设备状态 { living_room_light: true, air_conditioner: true } 当前室温 28.9由于温度是随机模拟的第二次运行可能会因为温度低于 28 度而出现空调未开启的结果这正好体现了“小脑结合实时数据做判断”的价值。如果大模型输出了不合法的 JSONjson.loads会直接抛异常。这种问题在真实项目里很常见下一节我会专门讲排查方法。5. 进阶让端侧小模型真正成为“小脑”前面的示例中小脑是纯规则逻辑还没有用到端侧模型。在实际工程中我们希望部分判断能力也能放到端侧。一个典型的场景是室内人体检测。摄像头采集画面后小脑端侧模型判断“是否有人”然后把结果上报给大脑。大脑不需要实时看视频只需要收状态这样既降低带宽压力也保护用户隐私。端侧模型的部署方式大同小异核心流程是训练或蒸馏得到一个较小的模型。转换为 ONNX 或 TFLite 格式。使用端侧推理框架加载模型。在本地实时推理并输出结果。以 ONNX Runtime 为例加载一个分类模型的代码片段如下import onnxruntime as ort import numpy as np # 加载 ONNX 模型 session ort.InferenceSession(person_detector.onnx, providers[CPUExecutionProvider]) # 假设输入 shape 为 [1, 3, 224, 224] input_name session.get_inputs()[0].name input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # 推理 outputs session.run(None, {input_name: input_data}) print(outputs[0])这段代码只是展示基本流程。真实项目中你需要准备模型文件、预处理图像、解析输出结果。如果是做人体检测建议使用 YOLO 系列目标检测模型输出的是边界框和置信度。你可以把上面这段推理代码封装进Cerebellum让它在执行某个动作时自动调用。这样一来小脑不仅会执行规则还拥有了“感知能力”离真正的“最强小脑”就更近了一步。6. 常见问题与排查思路在实战中大脑-小脑协同最常见的坑可以整理成下面这张表。问题现象常见原因解决思路大脑接口请求超时网络不稳定或模型推理时间过长设置合理超时时间开启流式输出增加缓存模型返回内容无法解析成 JSON大模型输出了解释文字或 Markdown 代码块在系统提示词中强化格式约束返回后做清理后处理设备执行成功但状态未更新控制层与硬件之间存在通信延迟增加设备状态确认机制执行后主动回读状态传感器读数波动很大传感器噪声或环境干扰多次采样取均值使用滤波算法端侧小模型推理效果差训练数据不足或数据分布不匹配使用蒸馏数据回流持续微调小模型本地资源不足模型过大或推理框架未做加速使用量化模型开启 GPU/NPU 加速用户敏感数据上了云端所有数据都调用云端 API在端侧做数据过滤、脱敏只上传必要信息排查顺序建议如下先看大脑返回的原始内容是什么确认是不是 JSON。再检查协议字段是否匹配比如小脑代码里读取的字段名是否和大模型输出一致。接着检查小脑执行日志看设备动作是否真的触发。最后检查环境差异比如本地依赖版本、硬件权限、网络连通性。7. 最佳实践与工程建议在实际项目中要让“最强大脑”和“最强小脑”稳定协作我认为有这几点值得重视。7.1 协议先行再写代码大脑和小脑之间的 JSON 协议是整个系统的“接口契约”。项目启动时应该先用 JSON Schema 或文档把它固定下来避免开发过程中两边各改各的。协议设计要尽量简单。动作类型越少越好能用turn_on、turn_off、read_temperature表达清楚的就不要引入复杂的嵌套结构。条件判断虽然是协议的一部分但也要控制嵌套层数否则小脑解析代码会变得很难维护。7.2 可观测性比功能更重要由于系统链路比较长任何一个环节出错都不容易定位。建议至少记录以下内容用户原始指令。大脑返回的完整 JSON。小脑执行每一步的结果。设备最终状态。每次调用的耗时。日志最好带上任务 ID方便把一条完整链路的日志串联起来。7.3 做好超时、重试和降级云端大模型调用必须设置超时时间。建议把超时分成两档普通任务 15 到 30 秒复杂任务可以更长。超时后要有重试机制但重试次数不宜过多否则会造成雪崩。降级策略同样重要。当大脑不可用时小脑可以切到预置规则模式。例如之前总结过“温度超过 28 度就开空调”这本身就是一条可靠的本地规则不需要大脑参与也能执行。7.4 安全与隐私是不可触碰的底线真实场景中小脑采集到的原始数据是否上传云端一定要在设计阶段就明确。比如摄像头画面、用户声音、家庭传感器数据都属于敏感信息能本地处理就不要上传。设备控制类的指令应该加上权限校验。不能因为小脑执行了大模型下发的动作就省略授权环节。尤其是涉及门锁、电闸、燃气阀等高风险设备时必须做二次确认。7.5 持续用数据喂养小脑“小脑”不是一成不变的。每次大脑的规划结果、小脑的执行反馈都是非常有价值的训练数据。项目上线后建议定期把高质量的执行日志清洗出来用于微调端侧模型。这个闭环一旦跑通系统会越用越聪明。高频任务逐渐被本地小模型接管云端大模型只处理真正复杂和低频的请求成本和响应速度都会得到明显改善。如果大家在自己的本地环境里跑这个“大脑-小脑”示例时遇到问题欢迎在评论区留言交流。下一篇我可以继续写端侧小模型微调、以及如何把 RAG 接入这套架构的完整实操感兴趣的话可以先点个收藏方便后续查找。