北京
在一台树莓派、Jetson或是廉价的ARM虚拟机上跑本地模型时，有两股流量要接进来——浏览器、curl脚本通过HTTP端点请求逐token的流式输出，传感器、摄像头、控制器则通过MQTT上报遥测数据和批量作业。传统做法需要部署三四个独立的守护进程：一个Web应用服务器、一个HTTP/2反向代理、一个单独的MQTT broker，外加让它们协同工作的胶水代码。在边缘盒子上，每多一个组件就意味着多一次配置、多一次跨平台编译，尤其ARM或RISC-V还常碰到原生依赖的麻烦。
现在，一个纯Python的ASGI框架BlackBull把这些全部打包进了一个进程。它的协议栈——HTTP/1.1、HTTP/2、WebSocket、gRPC，以及一个完整的MQTT 5 broker——全是Python实现，无需额外中间件。整个边缘服务界面就像这样：一个Python进程在8000端口提供HTTP/1.1和HTTP/2（支持h2c明文或通过ALPN的TLS协商），/generate端点直接流出SSE token流，/devices端点返回最新设备读数的JSON；同时，同个进程还在1883端口运行MQTT 5 broker，接收以sensors/{device}/{metric}格式发布的遥测，并利用$share/组实现作业队列的轮询分发。
Token流式推理的实现干脆利落：只需定义一个异步生成器，遍历模型输出，每生成一个token就yield一个SSE事件，最后再发一个“done”事件，把它交给EventSourceResponse返回即可。prompt从查询字符串解析，完美兼容浏览器端EventSource API的GET请求。每个yield都是即时写入连接，靠传输背压而非缓冲控制流速，第一个token在模型还在计算后续结果时就能到达客户端。
并发生成是HTTP/2真正发挥价值的场景：多个/generate流可以在一条连接上多路复用，无需像HTTP/1.1那样排队等待。而且无需额外配置——明文h2c会根据连接前言自动检测，局域网内完全不用折腾TLS；浏览器场景下，只需传入证书文件就会在同一端口上走ALPN协商h2。
示例中的fake_model是一个异步生成器，在token之间主动睡眠，所以演示可以零依赖跑起来。但换成真实模型时，推理往往是CPU密集型（或NPU/GPU调用后的阻塞等待），直接把这类任务内联执行会导致事件循环停滞。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
