前阵子孩子上三年级作业里开始出现各种阅读理解题和作文小练笔家里平板上的AI助手倒是能答但我发现两个问题一是孩子在用的时候总被无关话题带跑二是聊天记录直接躺在别人的服务器上我这个人比较在意隐私。更麻烦的是家里网络偶尔抽风云端接口一断所谓智能机器人当场变傻子。于是我就动了心思把大语言模型装到本机做一个真正属于自己的“学伴机器人”顺便让它能控制点家里的设备变成“生活机器人”。技术栈上我选了自己最熟的C#路线——上位机用ASP.Net MVC写Web应用下位机用这几年越来越成熟的NanoFramework.Net让ESP32跑C#编写的嵌入式程序。这篇文章就把我的整套工程思路、选型取舍和踩坑记录整理出来给想做本地大模型应用、或者想把手头.NET技能延伸到硬件控制的朋友做个参考。先说清楚适合谁看你最好是有点C#基础知道ASP.Net MVC大概怎么建项目对LLM只有概念没实操过。如果你完全没写过代码这篇文章可能偏硬但原理部分也能帮你建立整体认知。1. 为什么学伴机器人要把LLM放本机而不是全走云端1.1 先从三个真实场景说起第一个场景发生在孩子的卧室。路由器在客厅隔着一堵承重墙孩子的平板偶尔会断流。我用云端API做实验的时候发现一旦网络波动单次问答的延迟能从1秒蹿到十几秒更别提流式输出中途断掉。孩子可不管底层原因他只会在那边喊“机器人卡了”。第二个场景是隐私。孩子问“人为什么会做梦”、“为什么爸爸会发脾气”这类问题他以为只是在跟一个小伙伴聊天但我不想让这些对话内容被第三方记录和分析。更不用说学伴机器人如果挂了摄像头或麦克风家庭画面和声音的隐私级别就更高了。第三个场景是寒暑假回老家。爷爷奶奶家没有装宽带或者宽带质量很一言难尽孩子想用机器人的时候没网那整台设备就跟砖头没区别。本机部署恰好把这几个问题一次解决离线可用数据不出门延迟也可控。模型跑在自家电脑上所有对话在本机内存里走一圈没有上传环节断网了也能继续聊。1.2 本机LLM的能力边界这里我得先泼盆冷水本地那点算力跑的7B模型跟云端GPT-4o级别的模型有代差别指望它事事精通。但学伴机器人这个场景里7B模型其实够用。它擅长的是日常问答、知识解释、作文思路建议、情感陪伴式对话以及按指令输出结构化JSON。它不擅长的是需要长链推理的数学难题、需要实时联网获取最新信息的问题以及超长上下文的深度分析。比如你问它“帮我规划一次从北京到成都的自驾游路线”它可以给你建议框架但没法告诉你今天哪条高速封路。所以架构上一定要留“插件”位置搜索结果接入、本地知识库检索、外部工具调用这些后续都可以通过MVC应用层补上去。后面要讲的RAG知识库简化版就是往这个方向走的第一步。1.3 算一笔账我粗略算过一台二手3060显卡主机大概三千到五千块算上功耗一年电费几百元。用云端API叫服务按Token计费单看单次问答便宜但长期跑下来每个月光是给孩子用的问答量就不好控。关键是孩子使用时间不固定兴趣来了能连续问一个小时云API费用就像出租车计价器一样咔咔走。如果是学校班级场景就更明显二三十个孩子同时访问就算做了限流那点预算也顶不住持续调用。本地部署一台稍好点的机器一次性投入后面使用成本只有电费而且数据不用经过任何第三方。2. 本机LLM的方案选型Ollama、量化模型与一套实测配置2.1 为什么我选了Ollama而不是llama.cpp或LocalAI市面上跑本地大模型的工具很多我重点对比了三个llama.cpp、LocalAI、Ollama。llama.cpp是底层推理引擎的标杆性能确实好支持各种CPU和GPU混跑但它本质上是个C工程要自己编译、自己写调用接口对.NET开发者来说太不友好。LocalAI也试过功能是不少但社区活跃度和模型管理体验都差一截。Ollama赢在两个字省心。它自带模型管理命令一条ollama pull就能把模型下到本地自带HTTP API还兼容OpenAI的接口格式。也就是说我甚至可以直接用OpenAI SDK的请求格式去访问它代码层面几乎不用改。对C#项目来说这意味着对接成本极低我只需要用HttpClient往它的本地端口发JSON就行。还有一点很重要Ollama对中文开源模型的支持很积极通义千问、DeepSeek这些国内模型都能直接拉取没有额外转换步骤。对一个中文学伴机器人来说这一步省了我大量麻烦。2.2 模型推荐与内存参考我实测过几组模型先上表格后面细说模型量化级别磁盘占用运行内存参考实际体感qwen2.5:3bQ4_K_M约2GB4GB可跑反应快但长句生成开始泛泛而谈qwen2.5:7bQ4_K_M约4.7GB8GB可跑中文理解稳长回答质量明显提升qwen2.5:14bQ4_K_M约9GB16GB才舒服质量最好但输出速度明显下降deepseek-r1:7bQ4_K_M约4.7GB8GB可跑推理类回答更有条理但对话偏“解释感”我的主力配置是qwen2.5:7b的4bit量化版本。8GB内存的机器跑它稍紧但配合Ollama的GPU层数配置后面细讲能压进可用的范围。机器上有独立显卡的话优先让GPU跑推理层跑不动的层再落到CPU。2.3 部署三步走第一步去Ollama官网下载对应系统版本的安装包装完它默认会注册成系统服务端口是11434。第二步拉模型。Windows下管理员身份打开终端ollama pull qwen2.5:7b这一步会从模型仓库下载几GB的文件网络状况好的话几分钟到十几分钟不等。第三步验证服务是否正常ollama serve然后另开一个终端curl http://127.0.0.1:11434/api/generate -d {\model\:\qwen2.5:7b\,\prompt\:\你好简单的自我介绍\}有返回内容就说明模型已经在工作了。这里有个容易忽略的细节Ollama默认只监听127.0.0.1也就是只能本机访问。如果后面想让平板或局域网内其他设备访问需要设置环境变量OLLAMA_HOST0.0.0.0但我的建议是不要急着开放局域网。真正应该暴露出去的是MVC后端接口本机LLM服务继续保持内网访问就好少一个暴露面少一分风险。3. C#侧的整体架构ASP.Net MVC应用如何串起LLM与机器人3.1 三层结构让机器人系统不变成一坨浆糊一开始我也想过把所有逻辑塞进Controller里后来发现完全不行聊天、知识库检索、设备控制、用户管理这些功能挤在一起改一个地方就可能炸一片。我最终分了三层Presentation层MVC的页面和Controller负责聊天界面、机器人状态面板、配置页面的交互。Application层聊天服务ChatService、知识库服务KnowledgeService、设备指令服务RobotCommandService处理具体业务逻辑。Infrastructure层OllamaClient封装对Ollama的HTTP调用、MqttClient上下位机通信、LiteDB/SQLite仓储。Controller只做参数接收和视图组装不直接碰Ollama API也不直接管MQTT。这样分层的原因很简单之后如果想从MVC换成Web API或者把Ollama换成别的推理后端只动Infrastructure层就够了不用牵一发动全身。3.2 用HttpClient调用Ollama的Chat接口Ollama官方有.NET客户端库但我实际用下来感觉还不够稳定尤其是流式接口的类型定义对不上。所以我直接用HttpClient手动拼JSON反而最可控。聊天接口的核心调用长这样public async Taskstring ChatAsync(string model, ListMessage messages, CancellationToken ct) { var payload new { model, messages, stream false, options new { temperature 0.7, num_ctx 8192 } }; using var client new HttpClient(); client.Timeout TimeSpan.FromMinutes(5); var content new StringContent( JsonSerializer.Serialize(payload), Encoding.UTF8, application/json ); var resp await client.PostAsync(http://127.0.0.1:11434/api/chat, content, ct); resp.EnsureSuccessStatusCode(); var json await resp.Content.ReadAsStringAsync(ct); using var doc JsonDocument.Parse(json); var assistantMsg doc.RootElement.GetProperty(message).GetProperty(content).GetString(); return assistantMsg ?? string.Empty; }这里有几个要点temperature调太高容易胡说八道学伴场景我通常压在0.6到0.7之间num_ctx是上下文长度默认2048太短多轮对话时模型聊着聊着就失忆但设得太大又吃内存8GB机器我建议8192封顶。3.3 流式输出打字机效果在MVC里的实现学伴机器人如果像老式对讲机一样等十几秒再一次性吐完整段文字体验非常差。我改成流式输出后孩子明显更愿意跟它“说话”了。这里有个很坑的细节Ollama的streamtrue返回的不是标准SSE格式而是NDJSON——每行一个独立JSON对象最后一行带done:true。所以不能用解析SSE的库直接处理最稳妥的办法是拿StreamReader逐行读public async IAsyncEnumerablestring ChatStreamAsync( string model, ListMessage messages, [EnumeratorCancellation] CancellationToken ct) { var payload new { model, messages, stream true }; var content new StringContent( JsonSerializer.Serialize(payload), Encoding.UTF8, application/json ); using var client new HttpClient(); using var resp await client.PostAsync( http://127.0.0.1:11434/api/chat, content, ct ); resp.EnsureSuccessStatusCode(); await using var stream await resp.Content.ReadAsStreamAsync(ct); using var reader new StreamReader(stream); while (await reader.ReadLineAsync(ct) is { } line) { if (string.IsNullOrWhiteSpace(line)) continue; using var doc JsonDocument.Parse(line); var ok doc.RootElement.GetProperty(done).GetBoolean(); if (ok) break; var text doc.RootElement .GetProperty(message) .GetProperty(content) .GetString(); if (!string.IsNullOrEmpty(text)) yield return text; } }前端我用SignalR把每个增量文本推给浏览器。SignalR对ASP.Net MVC的集成很成熟我在Hub里定义了一个StreamMessage(string delta)方法浏览器端收到后直接追加到聊天气泡里效果就是逐字蹦出来的打字机感。3.4 让LLM按JSON格式输出方便后续指令执行学伴机器人不只是聊天它还要控制灯、提醒作息、执行生活指令。所以我在系统提示词里明确要求模型输出结构化JSON。我用的System Prompt大概长这样代码里我放在一个静态类里管理你是“小智”一个关心孩子成长的中文学伴和生活助手。 回答要求 1. 日常聊天时语气温柔、简洁最多100字。 2. 输出必须是JSON格式不要用Markdown代码块包裹。 3. JSON结构如下 {type:chat|action|knowledge,content:回复内容,operation:{device:light|fan|speaker|null,action:on|off|timer,param:30分钟}} 4. type为chat表示普通对话action表示需要控制设备knowledge表示需要查询本地知识库。这样Controller拿到模型输出后先反序列化成RobotResponse对象根据type字段决定是直接返回聊天内容还是触发设备指令流程。解析失败的情况我做了兜底重试一次还是失败的话就把它当普通文本适配给chat类型至少保证界面不断。4. NanoFramework.Net下位机的角色从“听懂”到“行动”4.1 为什么非要一个下位机有人可能会问我都在本机跑LLM了直接在Windows上控制设备不行吗Windows调串口或USB确实可以但做学伴机器人你会发现几个麻烦控制器逻辑和聊天逻辑混在一起Windows一更新或断电重启整个机器人就瘫了。还有传感器轮询需要实时性Windows的调度不适合干这个。ESP32 DevKit模块只要几十块钱自带WiFi和蓝牙GPIO引脚够接灯、舵机和传感器功耗又低。关键是NanoFramework.Net能在这块小芯片上直接跑C#对.NET开发者来说上手成本比ESP-IDF的C语言低太多。我的方案就是“大脑在电脑手脚在单片机”MVC应用负责智力活动ESP32负责反应和动作。4.2 硬件与开发环境准备我用的硬件是ESP32 DevKit V1模组外接了一个LED灯珠、一个9g舵机、一个DHT11温湿度传感器。开发环境是Visual Studio 2022装上nanoFramework扩展再用nanoff工具给ESP32刷NanoFramework固件。刷固件命令示例dotnet tool install -g nanoff nanoff --target ESP32_DevKitc_V4 --update刷完之后VS就能通过USB直接把C#程序部署到板子上跟调试普通程序没什么两样这点对C#开发者来说极其友好。4.3 下位机程序骨架下位机主程序的结构很简单初始化、连WiFi、连MQTT、订阅指令主题、循环处理消息。using nanoFramework.Device.Gpio; using nanoFramework.Networking; using nanoFramework.M2Mqtt; using nanoFramework.M2Mqtt.Messages; using System; using System.Diagnostics; using System.Threading; MemoryStream stream new MemoryStream(); Debug.WriteLine(Booting robot device...); WifiNetworkHelper.ScanAndConnectDhcp( MY_WIFI_SSID, MY_WIFI_PASSWORD, TimeSpan.FromSeconds(30) ); var mqtt new MqttClient(192.168.1.10, 1883); mqtt.Connect(robot_esp32); mqtt.Subscribe( new[] { robot/command }, new[] { MqttQoSLevel.ExactlyOnce } ); mqtt.MqttMsgPublishReceived (sender, e) { var message Encoding.UTF8.GetString(e.Message, 0, e.Message.Length); var request SimpleJson.Parse(message); // 根据cmd字段执行动作 var cmd request[cmd]; switch (cmd) { case led_on: ledPin.Write(PinValue.High); break; case led_off: ledPin.Write(PinValue.Low); break; case servo: var angle int.Parse(request[param]); // 控制舵机转到指定角度 break; } }; // 每30秒上报一次在线状态 while (true) { mqtt.Publish( robot/status, Encoding.UTF8.GetBytes({\online\:true,\aliveTick\:1}), MqttQoSLevel.ExactlyOnce, false ); Thread.Sleep(30000); }这里的重点是在M2Mqtt这个库。NanoFramework生态里它算是Stable级别的支持QoS 1和QoS 2订阅和发布都靠它。我在程序里用QoS 1保证指令至少到达一次又不会像QoS 2那样握手太重对ESP32这种资源受限的设备来说是最佳平衡。4.4 通信协议设计上位机和下位机之间我用的是MQTTBroker跑在本机用的mosquitto。主题设计成两套robot/command上位机发布下位机订阅承载控制指令。robot/status下位机发布上位机订阅承载心跳和传感器状态。指令JSON格式{ reqId: 8f2a1c9e-3b45-4f67-9a2d-1b23c4d5e6f7, cmd: servo, param: 90 }reqId是每次指令生成的唯一编号下位机拿到后先查本地缓存如果处理过就直接丢弃防止信号重发导致重复动作。这个细节最初我没有考虑有一次MQTT断线重发舵机连着转了两下孩子还以为机器人抽搐了。5. 学伴机器人的功能拆解从知识问答到生活动作5.1 知识问答与作业辅导做一个本地也能用的微型知识库孩子总问课本上的知识点我一开始是把整个小学课本PDF喂给模型结果模型在长文本里胡编乱造。后来我改用RAG思路的简化版先把知识点拆成一条一条的问答对存进LiteDB用户提问时先用关键词匹配找出候选条目再用嵌入模型做向量相似度排序把最相关的几条拼进Prompt让模型基于这些内容回答。求嵌入的时候我顺便用Ollama的Embedding模型调用方式跟Chat接口类似curl http://127.0.0.1:11434/api/embeddings只是请求体里的model换成嵌入模型名称prompt换成文本。C#侧依然用HttpClient封装整个过程不引入额外的向量数据库LiteDB存float数组就够了因为数据量只有几百条顺序遍历算余弦相似度毫无压力。有个关键设计只有LLM输出的type为knowledge时才走这个检索流程避免每句话都调用知识库拖慢响应速度。5.2 情感陪伴与长期记忆让机器人记住孩子上次聊了什么光靠上下文窗口做记忆token消耗太大。我的做法是在LiteDB里维护一份“最近话题摘要”每次对话结束后让模型把这段对话浓缩成20字以内的摘要存库下次开车时把最近5条摘要注入System Prompt模型就能自然地接着上次的话题聊。比如昨天的摘要写的是“孩子画了一幅恐龙想给恐龙起个名字”今天孩子再说“小智我昨天那个恐龙还没有名字”模型能接上说出之前讨论的元素孩子惊喜得直拍手。需要强调一点不要试图把全部聊天历史一次性塞进去。上下文长度是有限资源一旦超出模型会把重要指令都忘掉。5.3 生活控制与意图识别规则先上大模型兜底对“打开灯”、“关风扇”、“十分钟后提醒我喝水”这类指令我现在的方案是先做规则匹配正则能命中就不麻烦LLM命中不了再发给模型识别。这个顺序很重要。纯规则匹配的问题是“帮我把卧室灯调亮一点”这种表达正则根本Hold不住这时候才轮到LLM出场。实际执行链条是用户输入文本传到MVC后端。RuleService尝试匹配正则库命中直接生成RobotResponse。未命中则调用LLM按系统提示词输出JSON。后端拿到typeaction的结果解析operation字段发布MQTT指令。下位机收到指令执行动作并上报状态。我实测下来90%的简单指令能被规则接住剩下10%的长尾表达靠LLM兜底既快又准。6. 实际调试验证中的坑与优化建议6.1 内存与算力调优先说最直接的坑8GB内存的机器跑qwen2.5:7b默认参数下经常出现OOM进程直接被系统杀掉。我的调优经验有三个方向。第一调低上下文长度。Ollama默认上下文是2048但如果你在请求里不传num_ctx它按模型配置文件走。我在MVC层统一把num_ctx压到8192然后看内存占用曲线如果还紧张就降到4096。上下文长度直接决定KV Cache的缓存大小不是越大越好。第二给Ollama指定可见的显存层数。我的机器用显卡跑设置环境变量OLLAMA_GPU_LAYERS35意思是把模型35层放到GPU剩下的层走CPU。这个数值靠试设太高显存爆设太低GPU闲置浪费最稳的方法是开任务管理器观察显存占用。第三换更小的模型。实在不行就用qwen2.5:3b功能上牺牲一点但响应速度质变。学伴机器人毕竟要的是“随叫随到”不是每句话都长篇大论。6.2 LLM幻觉与安全边界本地模型在事实类知识点上确实会一本正经地胡说八道这在学伴场景很危险。我的解决办法是凡是涉及事实判断的问题优先走知识库RAG流程知识库命中就直接引用库中内容模型只负责组织语言不负责编造事实。安全边界的处理同样不能含糊。我在System Prompt里加了一条硬性规则“如果孩子提到自伤、被欺凌、不安全行为立即在回复中明确建议告诉家长并输出type为alert。”这不是套话是学伴机器人的底线。我还做了一个关键词触发器在Controller层对用户输入做一次简单审查命中高危词就直接不走模型改走预设的安全回复。6.3 下位机的稳定性问题ESP32跑NanoFramework时WiFi掉线是常态。初期我试过只连WiFi不重连板子一掉线就成砖只能重新插电。后来做了三件事一是WiFi连接用WifiNetworkHelper.ScanAndConnectDhcp它带重试机制二是MQTT客户端做断线自动重连重连后重新订阅所有主题三是下位机每30秒上报心跳上位机连续3次收不到心跳就置为离线状态并在管理页面弹出提示。还有一个细节MQTT的reqId去重逻辑一定要做。断网重发、人为重复发布都会导致下位机重复执行指令。指令本身是幂等的还好但舵机旋转、灯开关这类有状态变化的操作重复执行就可能出问题。6.4 后续可以扩展的方向这套架构跑顺之后扩展空间其实很大。比如接入本地语音识别whisper.cpp的C版本通过本机HTTP服务暴露给C#调用孩子就能直接说话而非打字比如给ESP32接一块小屏幕让机器人有表情再比如把知识库升级成真正的向量检索方案用SQLite配合浮点向量做ANN索引数据量大了也不会拖慢。这些我目前都还在逐步尝试但从工程角度看底座已经打好了上位机、本机LLM、下位机三者解耦任何一环都可以独立升级替换。最后分享一点我自己的体会这个项目真正花时间的不是调Ollama也不是写MVC而是把“模型能力”和“机器行为”缝合起来——模型输出不可控但设备控制必须可控这两个世界的碰撞就是这类本机机器人项目最微妙的地方。你先别追求一步到位哪怕只实现“电脑上聊天、控制一个LED灯”这套架构跑通之后后续加功能都是顺水推舟。