企业官网建设流程全解析

1. 从"云端依赖"到"本机自治"：这套LLM工程到底在解决什么问题

做过智能硬件和上位机联调的人大概都有过这种体验：设备端采集了一堆数据，想加个"智能问答"或者"语音交互"的功能，第一反应是调云端API。但真到了落地阶段，问题就来了——网络抖动导致响应延迟忽高忽低、按调用量计费的成本随着设备数量线性上涨、用户隐私数据要往外传、离线场景直接歇菜。尤其是做"学伴机器人"或者"生活机器人"这类陪伴型产品，用户对响应速度和隐私敏感度都很高，云端方案在很多场景下根本走不通。

这套工程思路的核心，就是把大语言模型的推理能力从云端"搬"到本机，让整个系统在断网状态下也能跑起来。具体来说，它覆盖了两个层面的"本机"：一个是上位机层面，在Windows环境下直接用C#加载.gguf或.onnx格式的模型文件做推理，不需要Python环境、不需要额外部署推理服务；另一个是下位机层面，在.NET NanoFramework这样的嵌入式运行时上，让资源受限的MCU也能承担一部分轻量级的模型交互和调度工作。

这里要先厘清一个容易混淆的点：标题里说的"C#.ASP.Net MVC"指的是上位机的应用框架，用MVC模式来组织界面、业务逻辑和模型调用层；而"C#.NanoFramework.Net下位机"指的是嵌入式端的运行时环境，两者通过串口、蓝牙或网络协议通信。整个系统不是"把大模型塞进单片机"这种不切实际的想法，而是上位机跑推理、下位机做交互和调度的分工架构。这个分工逻辑很关键，后面会详细展开。

适合读这套思路的人，我大致分三类：一是做智能硬件产品、想在设备里加AI能力但被云端方案卡住的开发者；二是熟悉C#/.NET技术栈、想切入LLM应用但不想折腾Python生态的工程师；三是做教育类、陪伴类机器人项目，对离线运行和隐私保护有硬性要求的团队。如果你属于其中任何一类，这套思路里的选型逻辑和踩坑经验应该能帮你省不少时间。

2. 整体架构设计：为什么是"上位机推理+下位机调度"这套组合

2.1 算力现实决定了分工边界

先摆一个基本事实：大语言模型的推理对算力和内存的需求，和嵌入式MCU的资源之间，差着好几个数量级。一个7B参数的模型，即使用4-bit量化，权重文件也在3.5GB到4GB左右，推理时还需要额外的KV Cache和中间激活值。而典型的嵌入式MCU，RAM可能只有几百KB到几MB，Flash也就几MB。这个差距不是靠优化能弥合的。

所以架构设计的第一原则就是：推理这件事必须放在有足够算力的设备上。在Windows上位机上，你可以用CPU推理（慢但通用），也可以用CUDA/DirectML做GPU加速（快但需要硬件支持）。下位机的角色不是"跑模型"，而是"管交互"——负责传感器数据采集、语音唤醒词检测、简单的状态机控制、和上位机的通信协议处理。这种分工让每个设备都做自己擅长的事。

我见过一些项目试图在ESP32这类MCU上跑tinyML模型做意图分类，这个思路本身没问题，但那是"小模型做小任务"，和"LLM做通用对话"是两码事。把这两者混为一谈，项目很容易在选型阶段就走偏。

2.2 为什么上位机选C#而不是Python

这是很多人会问的问题。Python在LLM生态里确实是主流，llama.cpp、transformers、onnxruntime这些库的Python绑定都很成熟。但选C#有它自己的道理：

• 部署简单：C#编译出来是自包含的可执行文件，用户双击就能跑，不需要装Python、不需要配虚拟环境、不需要处理pip依赖冲突。对于面向普通用户的桌面应用，这个优势太大了。
• 和现有.NET生态无缝集成：如果项目本身就用ASP.NET MVC做界面，用C#调模型就是同一个进程内的事，不用搞跨语言通信。
• 性能可控：C#的P/Invoke可以直接调用llama.cpp的原生库，性能损耗很小。LLamaSharp这个库就是干这个的，它把llama.cpp的能力封装成了.NET的API。
• ONNX Runtime的.NET绑定很成熟：微软自己维护的Microsoft.ML.OnnxRuntime包，在Windows上的表现很稳定，支持DirectML做GPU加速。

当然，C#生态在LLM这块确实不如Python丰富，一些最新的量化技术、模型架构支持可能会滞后。但对于主流模型（Llama系列、Qwen系列、Phi系列等），LLamaSharp和ONNX Runtime的覆盖已经够用了。

2.3 下位机为什么选.NET NanoFramework

嵌入式端的运行时选择其实不少，C/C++裸机、MicroPython、RTOS加C，都是常见方案。选.NET NanoFramework的理由主要是技术栈统一：上位机是C#，下位机也是C#，开发者不用在两种语言和两套工具链之间来回切换。NanoFramework支持C#的语法子集，有Visual Studio的插件，调试体验比传统的嵌入式开发好不少。

它的资源占用也控制得不错，最小配置可以在只有128KB RAM和512KB Flash的芯片上跑起来。对于"学伴机器人"这种场景，下位机需要处理的任务——按键输入、LED指示、简单的语音模块串口通信、和上位机的协议解析——NanoFramework完全能胜任。

注意：NanoFramework不支持完整的.NET BCL，很多高级特性（如LINQ的大部分功能、反射、动态类型）都用不了。写代码时要按嵌入式思维来，别把上位机那套写法直接搬过去。

2.4 通信协议的设计考量

上位机和下位机之间怎么通信，这个看似简单的问题其实有不少讲究。常见的选择有串口（UART/USB CDC）、蓝牙SPP/BLE、WiFi TCP/UDP。选哪个取决于具体场景：

对于"学伴机器人"，如果是有线连接（比如放在桌上的设备），USB CDC是最省事的；如果是移动设备，蓝牙BLE更合适，但要注意BLE的MTU限制（通常20字节左右），传输长文本需要分包。

协议格式我建议用简单的长度前缀+JSON或者TLV（Type-Length-Value）。JSON可读性好、调试方便，但在MCU上解析开销大；TLV紧凑高效，但调试时需要用工具解析。折中方案是：控制指令用TLV，文本数据用长度前缀的UTF-8字符串。

3. 上位机实操：在Windows上用C#直接跑.gguf和.onnx模型

3.1 环境准备与依赖选型

先说.gguf路线。.gguf是llama.cpp定义的模型格式，专门为量化推理设计，支持Q4_K_M、Q5_K_M、Q8_0等多种量化级别。在C#里加载.gguf，目前最成熟的方案是LLamaSharp。

# 通过NuGet安装LLamaSharp dotnet add package LLamaSharp dotnet add package LLamaSharp.Backend.Cpu # 如果有NVIDIA GPU，可以加CUDA后端 dotnet add package LLamaSharp.Backend.Cuda12

LLamaSharp的版本要和llama.cpp的原生库版本匹配，这个在NuGet包描述里会写清楚。我踩过的坑是：装了最新版的LLamaSharp，但后端包版本没跟上，运行时报DllNotFoundException，排查了半天才发现是版本不匹配。

再说.onnx路线。ONNX Runtime的.NET包是Microsoft.ML.OnnxRuntime，GPU加速需要额外装Microsoft.ML.OnnxRuntime.DirectML或Microsoft.ML.OnnxRuntime.Gpu。

dotnet add package Microsoft.ML.OnnxRuntime dotnet add package Microsoft.ML.OnnxRuntime.DirectML

ONNX路线适合已经转好的模型，比如用optimum工具从HuggingFace导出的ONNX格式。它的优势是跨平台一致性好，DirectML后端在Windows上对AMD/Intel/NVIDIA显卡都支持。

3.2 模型文件的选择与量化级别权衡

选模型文件时，要在质量、速度、内存占用三者之间做权衡。以7B模型为例：

我的经验是：Q4_K_M是性价比最高的选择。它在质量损失和资源占用之间取得了很好的平衡，对于"学伴机器人"这种场景，回答质量完全够用。如果硬件内存充裕（16GB以上），可以上Q5_K_M；如果内存紧张（8GB），Q4_0或Q3_K_M是无奈之选，但要注意回答质量会下降。

提示：模型文件下载后一定要校验SHA256，我遇到过下载不完整导致加载时报"invalid magic number"的情况，重新下载就好了。

3.3 用LLamaSharp加载.gguf并实现流式输出

下面是一个最小可运行的示例，展示如何加载模型并做流式生成：

using LLama; using LLama.Common; public class LocalLlmService { private LLamaWeights _weights; private LLamaContext _context; private InteractiveExecutor _executor; public void Initialize(string modelPath) { var parameters = new ModelParams(modelPath) { ContextSize = 2048, // 上下文窗口大小 GpuLayerCount = 20, // 卸载到GPU的层数，0表示纯CPU BatchSize = 512, // 批处理大小 Threads = 8 // CPU线程数 }; _weights = LLamaWeights.LoadFromFile(parameters); _context = _weights.CreateContext(parameters); _executor = new InteractiveExecutor(_context); } public async IAsyncEnumerable<string> GenerateAsync(string prompt) { var chatHistory = new ChatHistory(); chatHistory.AddMessage(AuthorRole.User, prompt); var inferenceParams = new InferenceParams { MaxTokens = 512, AntiPrompts = new List<string> { "User:" }, Temperature = 0.7f, TopP = 0.9f }; await foreach (var token in _executor.ChatAsync(chatHistory, inferenceParams)) { yield return token; } } }

几个关键参数的解释：ContextSize决定了模型能"记住"多长的对话历史，2048对于日常对话够用，但如果你要做长文档问答，需要调到4096甚至8192，代价是内存占用增加。GpuLayerCount是卸载到GPU的层数，设得越高GPU利用率越高，但显存不够会报错，需要根据显卡显存调整。Temperature控制输出的随机性，0.7是个比较平衡的值，做事实性问答可以调到0.3，做创意生成可以调到1.0。

3.4 ONNX Runtime路线的加载与推理

ONNX路线的代码结构不太一样，需要自己处理tokenizer和推理循环：

using Microsoft.ML.OnnxRuntime; using Microsoft.ML.OnnxRuntime.Tensors; public class OnnxLlmService { private InferenceSession _session; public void Initialize(string modelPath) { var options = new SessionOptions(); options.AppendExecutionProvider_DML(0); // 使用DirectML，0表示GPU设备索引 options.GraphOptimizationLevel = GraphOptimizationLevel.ORT_ENABLE_ALL; _session = new InferenceSession(modelPath, options); } public int[] RunInference(int[] inputIds, int[] attentionMask) { var inputTensor = new DenseTensor<long>( inputIds.Select(i => (long)i).ToArray(), new[] { 1, inputIds.Length }); var maskTensor = new DenseTensor<long>( attentionMask.Select(i => (long)i).ToArray(), new[] { 1, attentionMask.Length }); var inputs = new List<NamedOnnxValue> { NamedOnnxValue.CreateFromTensor("input_ids", inputTensor), NamedOnnxValue.CreateFromTensor("attention_mask", maskTensor) }; using var results = _session.Run(inputs); var logits = results.First().AsTensor<float>(); // 后续做argmax或采样得到下一个token return SampleNextToken(logits); } }

ONNX路线的麻烦之处在于：tokenizer需要单独处理，通常用Microsoft.ML.Tokenizers库；采样逻辑（top-k、top-p、temperature）要自己实现；KV Cache的管理也要手动做。相比之下，LLamaSharp把这些都封装好了，开发效率高很多。所以我的建议是：能用.gguf就用.gguf，ONNX路线留给有特定需求的场景（比如模型只有ONNX格式、或者需要跨平台部署到非Windows环境）。

3.5 ASP.NET MVC中的集成方式

在MVC架构里，LLM服务应该作为一个单例服务注入，避免每次请求都重新加载模型：

// Program.cs 或 Startup.cs builder.Services.AddSingleton<LocalLlmService>(sp => { var service = new LocalLlmService(); service.Initialize(@"D:\models\qwen2.5-7b-instruct-q4_k_m.gguf"); return service; }); // Controller public class ChatController : Controller { private readonly LocalLlmService _llm; public ChatController(LocalLlmService llm) { _llm = llm; } [HttpPost] public async Task<IActionResult> Send([FromBody] ChatRequest request) { var response = new StringBuilder(); await foreach (var token in _llm.GenerateAsync(request.Message)) { response.Append(token); } return Json(new { reply = response.ToString() }); } }

如果要支持流式输出到前端，可以用Server-Sent Events（SSE）或者WebSocket。SSE更简单，适合单向的token推送：

[HttpGet] public async Task StreamChat(string message, CancellationToken ct) { Response.Headers.Add("Content-Type", "text/event-stream"); await foreach (var token in _llm.GenerateAsync(message).WithCancellation(ct)) { await Response.WriteAsync($"data: {token}\n\n"); await Response.Body.FlushAsync(); } }

注意：模型加载是耗时操作（几秒到几十秒），一定要在应用启动时完成，不要放在请求处理路径里。另外，LLM推理是CPU/GPU密集型任务，多个请求并发时会互相争抢资源，建议加一个信号量做限流。

4. 下位机实操：.NET NanoFramework上的交互调度实现

4.1 开发环境搭建与硬件选型

NanoFramework的开发需要Visual Studio的扩展。在VS的扩展管理器里搜索".NET NanoFramework"安装即可。安装后会多出一类项目模板，包括"Blank Application"、"GPIO Example"等。

硬件方面，官方支持的芯片不少，常见的有STM32系列、ESP32系列、TI CC13xx系列。对于"学伴机器人"这种场景，我推荐ESP32-S3，原因有三：一是它有WiFi和BLE，通信方式灵活；二是它有向量指令扩展，虽然跑不了LLM，但做一些简单的信号处理（如音频预处理）有优势；三是它的GPIO丰富，接传感器和执行器方便。

烧录固件需要用nanoff工具：

dotnet tool install -g nanoff nanoff --target ESP32_S3 --update --serialport COM3

烧录完成后，在VS里选择对应的设备，就可以直接部署和调试了。

4.2 下位机的职责边界与状态机设计

下位机不跑LLM，那它到底干什么？我把它归纳为四件事：

1. 输入采集：按键、触摸、麦克风（通过外接语音模块）、传感器数据
2. 本地预处理：唤醒词检测、按键消抖、数据格式化
3. 通信管理：和上位机的协议收发、断线重连、心跳维持
4. 输出控制：LED指示、屏幕显示、舵机/电机控制、语音播报触发

这四件事用一个状态机来组织最清晰。我通常设计这几个状态：Idle（待机）、Listening（采集输入）、Sending（发送到上位机）、Waiting（等待响应）、Speaking（输出响应）、Error（异常处理）。

public enum RobotState { Idle, Listening, Sending, Waiting, Speaking, Error } public class RobotStateMachine { private RobotState _currentState = RobotState.Idle; private readonly ISerialTransport _transport; public void Update() { switch (_currentState) { case RobotState.Idle: if (WakeWordDetected()) TransitionTo(RobotState.Listening); break; case RobotState.Listening: var input = CaptureInput(); if (input != null) { _pendingInput = input; TransitionTo(RobotState.Sending); } break; case RobotState.Sending: _transport.SendMessage(_pendingInput); TransitionTo(RobotState.Waiting); break; case RobotState.Waiting: if (_transport.HasResponse()) { _pendingResponse = _transport.ReceiveMessage(); TransitionTo(RobotState.Speaking); } else if (Timeout()) { TransitionTo(RobotState.Error); } break; case RobotState.Speaking: PlayResponse(_pendingResponse); TransitionTo(RobotState.Idle); break; case RobotState.Error: HandleError(); TransitionTo(RobotState.Idle); break; } } }

这个状态机在主循环里以固定频率调用（比如每10ms一次），保证响应及时性。注意NanoFramework里没有async/await的完整支持，所以不能用异步编程模型，得用这种轮询式的主循环。

4.3 串口通信协议的实现

下位机和上位机之间的协议，我设计了一个简单的帧格式：

[0xAA][0x55][Length_H][Length_L][Type][Payload...][Checksum]

• 0xAA 0x55：帧头，用于同步
• Length：Payload长度，2字节大端
• Type：消息类型（0x01=文本输入，0x02=文本输出，0x03=控制指令，0x04=心跳）
• Payload：实际数据，UTF-8编码
• Checksum：从Length到Payload的异或校验

NanoFramework端的发送实现：

public void SendMessage(byte type, string payload) { var payloadBytes = Encoding.UTF8.GetBytes(payload); var frame = new byte[7 + payloadBytes.Length]; frame[0] = 0xAA; frame[1] = 0x55; frame[2] = (byte)(payloadBytes.Length >> 8); frame[3] = (byte)(payloadBytes.Length & 0xFF); frame[4] = type; Array.Copy(payloadBytes, 0, frame, 5, payloadBytes.Length); byte checksum = 0; for (int i = 2; i < frame.Length - 1; i++) checksum ^= frame[i]; frame[frame.Length - 1] = checksum; _serialPort.Write(frame, 0, frame.Length); }

接收端要处理粘包和半包问题。串口数据是流式的，一次Read可能读到半帧，也可能读到多帧。我的做法是维护一个接收缓冲区，每次读到数据就追加进去，然后循环尝试解析完整帧：

private readonly List<byte> _rxBuffer = new List<byte>(); public void OnSerialDataReceived(byte[] data) { _rxBuffer.AddRange(data); while (TryParseFrame(out var frame)) { ProcessFrame(frame); } } private bool TryParseFrame(out Frame frame) { frame = null; // 找帧头 while (_rxBuffer.Count >= 2) { if (_rxBuffer[0] == 0xAA && _rxBuffer[1] == 0x55) break; _rxBuffer.RemoveAt(0); } if (_rxBuffer.Count < 7) return false; int payloadLen = (_rxBuffer[2] << 8) | _rxBuffer[3]; int totalLen = 7 + payloadLen; if (_rxBuffer.Count < totalLen) return false; // 校验 byte checksum = 0; for (int i = 2; i < totalLen - 1; i++) checksum ^= _rxBuffer[i]; if (checksum != _rxBuffer[totalLen - 1]) { _rxBuffer.RemoveAt(0); // 校验失败，丢弃帧头继续找 return false; } frame = new Frame { Type = _rxBuffer[4], Payload = _rxBuffer.GetRange(5, payloadLen).ToArray() }; _rxBuffer.RemoveRange(0, totalLen); return true; }

提示：NanoFramework的List<byte>性能一般，如果数据量大，建议用固定大小的环形缓冲区。另外，串口中断里不要做复杂处理，把数据丢进缓冲区就返回，解析放在主循环里做。

4.4 上位机侧的串口服务实现

上位机用System.IO.Ports.SerialPort来收发数据。注意.NET Core之后，SerialPort需要单独装System.IO.Ports包：

dotnet add package System.IO.Ports

上位机的接收逻辑和下位机类似，也是缓冲区+帧解析。但上位机可以用异步方式：

public class SerialTransport : IDisposable { private readonly SerialPort _port; private readonly List<byte> _rxBuffer = new List<byte>(); private readonly object _lock = new object(); public event Action<Frame> FrameReceived; public SerialTransport(string portName, int baudRate = 115200) { _port = new SerialPort(portName, baudRate) { ReadTimeout = 100, WriteTimeout = 100 }; _port.DataReceived += OnDataReceived; _port.Open(); } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { var available = _port.BytesToRead; var buffer = new byte[available]; _port.Read(buffer, 0, available); lock (_lock) { _rxBuffer.AddRange(buffer); while (TryParseFrame(out var frame)) { FrameReceived?.Invoke(frame); } } } }

上位机收到文本输入帧后，调用LLM服务生成回复，再通过串口发回给下位机。这个流程要处理好超时和异常，比如LLM推理时间过长（超过下位机的等待超时），下位机会进入Error状态。我的做法是：下位机的等待超时设得宽一些（比如30秒），同时上位机在开始推理前先发一个"处理中"的帧，让下位机知道请求已收到。

5. 常见问题与排查技巧实录

5.1 模型加载与推理类问题

问题一：加载.gguf时报"invalid magic number"

这个错误几乎都是模型文件损坏或不完整导致的。排查步骤：先校验文件SHA256，和下载页面对比；如果SHA256对不上，重新下载。另外要注意，有些模型文件是分片的（比如model-00001-of-00003.gguf），需要全部下载并放在同一目录，LLamaSharp会自动识别。

问题二：推理速度慢得无法接受

先确认是否用了GPU加速。如果GpuLayerCount设为0，那就是纯CPU推理，7B模型在普通CPU上大概每秒2-5个token，确实慢。检查方法：看任务管理器里GPU占用率，如果为0，说明没走GPU。可能的原因：没装CUDA/DirectML后端包、显卡驱动版本不匹配、显存不足导致自动回退到CPU。

问题三：生成的内容乱码或重复

乱码通常是tokenizer不匹配导致的，确认模型文件和tokenizer配置是否对应。重复输出（比如一直重复同一句话）是采样参数问题，调低Temperature、调高RepeatPenalty（重复惩罚）可以缓解。LLamaSharp里对应的参数是RepeatPenalty，默认1.1，可以调到1.2-1.3。

问题四：内存占用过高导致系统卡顿

7B模型Q4量化后，加载到内存大约占4-5GB，加上KV Cache和运行时开销，总共6-8GB。如果系统内存只有8GB，会非常吃力。解决方案：换更小的模型（3B或1.5B），或者用更激进的量化（Q3_K_M），或者限制ContextSize（比如从4096降到2048）。

5.2 串口通信类问题

问题五：数据丢失或帧解析错误

最常见的原因是波特率不匹配或缓冲区溢出。先确认两端波特率一致（115200是常用值）。如果数据量大，115200可能不够，可以调到921600。另外，下位机的接收缓冲区如果太小，高频数据会丢，建议至少256字节。

问题六：下位机频繁重启

NanoFramework下位机重启通常是内存不足或未处理异常导致的。排查方法：在Main里包一层try-catch，把异常信息通过串口打出来；用GC.Run()手动触发垃圾回收，观察是否缓解。如果确认是内存不足，要减少对象分配，比如复用缓冲区而不是每次new。

问题七：上位机收不到下位机数据

先确认串口是否被其他程序占用（比如串口调试助手没关）。然后检查DataReceived事件是否触发——有些USB转串口芯片的这个事件触发不稳定，可以改用轮询方式读取。另外，Windows的串口驱动有时会缓冲数据，设置ReadTimeout和WriteTimeout为较小值可以改善。

5.3 系统集成类问题

问题八：LLM回复太长导致下位机显示不全

下位机的屏幕通常很小，显示不了长文本。解决方案：上位机在发送回复前做截断或摘要，只发前N个字符；或者下位机做分页显示，按键翻页。我倾向于前者，因为下位机做文本处理能力有限。

问题九：多轮对话的上下文管理

LLM需要上下文才能做多轮对话，但上下文越长，推理越慢、内存占用越大。我的做法是：维护一个固定长度的对话历史（比如最近5轮），超出就丢弃最早的。LLamaSharp的ChatHistory支持这种管理，也可以自己实现一个环形队列。

问题十：模型切换时的资源释放

如果要支持多个模型切换，切换前必须释放旧模型占用的资源，否则内存会持续增长。LLamaSharp里要调用_context.Dispose()和_weights.Dispose()。注意Dispose的顺序：先释放Context，再释放Weights。

5.4 常见问题速查表

5.5 几条踩坑心得

心得一：模型文件放在SSD上。机械硬盘加载4GB的模型文件要几十秒，SSD只要几秒。这个差异在开发调试阶段特别明显，因为你会频繁重启应用。

心得二：下位机的看门狗一定要开。NanoFramework支持硬件看门狗，在Main循环里定期喂狗。如果程序卡死，看门狗会自动重启，避免设备"假死"。我有个项目因为没开看门狗，设备跑几天就卡住，排查了很久才发现是某个串口读取操作阻塞了主循环。

心得三：上位机的LLM服务要做健康检查。模型加载后不一定能正常工作（比如显存不足导致推理失败），建议在服务启动后跑一次简单的推理测试，确认正常后再对外提供服务。

心得四：协议里加一个"版本号"字段。上位机和下位机的固件可能不同步更新，协议版本不一致会导致解析错误。在帧头里加一个版本字节，双方校验版本，不匹配就报错提示升级，能省很多排查时间。

心得五：日志要分级。下位机的日志通过串口输出，如果什么都打，会淹没关键信息。建议分ERROR/WARN/INFO/DEBUG四级，默认只输出WARN以上，调试时再开DEBUG。上位机的日志写到文件，按天滚动，方便回溯。

这套"上位机推理+下位机调度"的架构，我在几个项目里实际跑过，稳定性没问题。关键是要把职责边界划清楚，上位机专心做推理，下位机专心做交互，中间的通信协议设计得健壮一些。模型选型和量化级别的选择，要根据实际硬件配置来定，没有万能方案。如果硬件资源实在紧张，可以考虑用更小的模型（1.5B或3B），或者把一些简单意图识别放到下位机本地做，只把复杂对话交给上位机。这个内容后续还可以往"多模型热切换"和"下位机本地意图分类"两个方向扩展，前者解决不同场景用不同模型的需求，后者能进一步降低对上位机的依赖。