Docker Compose编排边缘AI：Ollama本地推理部署实战

Docker Compose编排边缘AIOllama本地推理部署实战2026年AI落地的关键词变了。以前大家讨论的是哪个模型更强现在问得最多的是能不能跑在本地。数据隐私、调用成本、离线可用——这三个现实约束让本地AI推理成为刚需。Docker让本地AI部署的门槛大幅降低。不用折腾CUDA驱动、不用管Python环境冲突拉一个镜像就能跑。这篇从物联网边缘场景出发讲Docker Compose编排Ollama本地推理的完整实战。部署过程中管理多个Docker项目的参考资源可以借助虎王科技开源的 anime_nav_pro_plus 导航站 做内部技术资源聚合。为什么边缘节点需要本地AI物联网边缘节点的AI推理需求很具体设备异常检测、图像识别、语音唤醒。这些任务如果走云端API有三个问题。延迟不可控4G网络往返延迟100-300ms加上模型推理时间总延迟可能超过500ms。对于实时控制场景如设备故障预警这个延迟不可接受。成本随设备数线性增长1000台设备每天各推理100次就是10万次API调用。按0.01元/次算每月3万元。本地部署一次性投入硬件成本长期更划算。数据合规工业现场数据不允许出网这是很多政企项目的硬性要求。Ollama是目前最顺手的本地大模型推理工具。它把模型文件、推理引擎和API服务打包成一个二进制部署极其简单。环境准备边缘节点的硬件配置直接决定能跑多大的模型。实测参考硬件CPURAM可跑模型推理速度树莓派5Cortex-A76 x48GBqwen2:1.5b~8 tok/sNUCi5-1240P16GBqwen2:7b~15 tok/s工控机i7-1270032GBqwen2:14b~20 tok/s服务器Xeon GPU64GBqwen2:32b~30 tok/s物联网边缘节点通常用NUC或工控机方案。没有GPU也能跑只是速度慢一些。7B量化模型在纯CPU上推理速度约10-15 tok/s对非实时场景够用。Docker Compose编排单独docker run跑Ollama很简陋生产环境应该用Compose管理。一个完整的边缘AI节点通常需要Ollama 应用服务 监控version:3.8services:ollama:image:ollama/ollama:latestcontainer_name:ollamaports:-11434:11434volumes:-./ollama/models:/root/.ollamaenvironment:-OLLAMA_HOST0.0.0.0:11434-OLLAMA_MAX_LOADED_MODELS2-OLLAMA_NUM_PARALLEL2restart:unless-stoppedhealthcheck:test:[CMD,curl,-f,http://localhost:11434/api/tags]interval:30stimeout:10sretries:3ai-gateway:image:python:3.12-slimcontainer_name:ai-gatewaydepends_on:ollama:condition:service_healthyvolumes:-./gateway:/appworking_dir:/appcommand:python-m uvicorn main:app--host 0.0.0.0--port 8000ports:-8000:8000environment:-OLLAMA_URLhttp://ollama:11434-MODEL_NAMEqwen2:7brestart:unless-stoppedmonitoring:image:prom/node-exporter:latestcontainer_name:node-exporterpid:hostrestart:unless-stoppedcommand:---path.rootfs/hostvolumes:-/:/host:ro几个关键配置点。OLLAMA_MAX_LOADED_MODELS2限制同时驻留内存的模型数量避免内存溢出。OLLAMA_NUM_PARALLEL2允许2个并发推理请求根据CPU核心数调整。健康检查确保Ollama启动完成后再启动AI Gateway。模型镜像需要单独拉取不在Compose里定义# 拉取模型dockerexecollama ollama pull qwen2:7b# 验证模型可用curlhttp://localhost:11434/api/generate-d{ model: qwen2:7b, prompt: 你好, stream: false }AI Gateway为物联网场景定制直接让设备调Ollama的API不够灵活。中间加一层Gateway做请求路由、结果缓存和阈值告警。用Python FastAPI实现fromfastapiimportFastAPI,HTTPExceptionfrompydanticimportBaseModelimporthttpximportosimporttimefromfunctoolsimportlru_cache appFastAPI(titleIoT AI Gateway)ollama_urlos.getenv(OLLAMA_URL,http://ollama:11434)model_nameos.getenv(MODEL_NAME,qwen2:7b)classInferenceRequest(BaseModel):device_id:strsensor_data:dicttask:stranomaly_detectionclassInferenceResponse(BaseModel):device_id:strresult:strconfidence:floatlatency_ms:intapp.post(/api/analyze,response_modelInferenceResponse)asyncdefanalyze_device_data(req:InferenceRequest):starttime.time()# 构造提示词promptbuild_prompt(req.sensor_data,req.task)# 调用Ollama推理asyncwithhttpx.AsyncClient()asclient:respawaitclient.post(f{ollama_url}/api/generate,json{model:model_name,prompt:prompt,stream:False,options:{temperature:0.3,num_predict:200}},timeout30.0)ifresp.status_code!200:raiseHTTPException(status_code502,detailModel inference failed)resultresp.json()latencyint((time.time()-start)*1000)# 提取推理结果textresult.get(response,).strip()confidenceparse_confidence(text)returnInferenceResponse(device_idreq.device_id,resulttext,confidenceconfidence,latency_mslatency)defbuild_prompt(sensor_data,task):根据任务类型构造提示词iftaskanomaly_detection:return(f设备传感器数据:{sensor_data}\nf判断是否存在异常输出JSON格式: f{{anomaly: true/false, reason: ...}}\nf只输出JSON不要其他内容。)eliftaskfault_diagnosis:return(f设备传感器数据:{sensor_data}\nf如果数据异常分析可能的故障原因简要说明。)returnf分析以下数据:{sensor_data}defparse_confidence(text):从模型输出中提取置信度ifhighintext.lower():return0.9elifmediumintext.lower():return0.6return0.5Gateway做了几件事把设备ID和传感器数据封装成结构化请求、构造针对性的提示词、调用Ollama推理并返回延迟信息。temperature0.3降低随机性让推理结果更稳定。物联网场景实测在工控机i7-12700, 32GB RAM上实测以下场景设备异常检测设备每30秒上报一次传感器数据温度、振动、电流Gateway调用7B模型判断是否异常。指标数值备注平均推理延迟1.2-2.5秒取决于输出长度CPU占用60-80%推理期间内存占用~6GB7B量化模型准确率约85%与云端API对比85%的准确率跟GPT-4级别的模型有差距但在边缘场景下——能离线运行、不产生API费用、延迟可控——已经够用。关键是把模型当作预筛器模型判断为异常时再触发云端深度分析减少云端调用量。资源管理防止边缘节点被AI吃满Ollama推理时会吃满CPU如果边缘节点同时跑着数据采集服务推理可能导致数据采集中断。用Docker的资源限制来隔离services:ollama:# ... 其他配置deploy:resources:limits:cpus:6# 限制6核留2核给其他服务memory:8G# 限制8GB内存reservations:cpus:2memory:4GCPU限制让Ollama最多用6个核心留出2核给MQTT Broker和数据采集服务。这样推理时数据采集不会中断。模型管理策略边缘节点存储有限不能存太多模型。建议按场景精简到1-2个模型# 查看已加载模型curlhttp://localhost:11434/api/tags# 删除不需要的模型curl-XDELETE http://localhost:11434/api/delete-d{ name: qwen2:14b }# 模型自动卸载空闲5分钟后释放内存# 在Ollama启动参数中设置dockerexecollama ollama serve--keepalive5m--keepalive 5m让模型在5分钟没有请求后自动从内存卸载释放内存给其他服务。下次有请求时再重新加载。小结Docker Compose编排Ollama本地推理在物联网边缘场景中是可行且实用的。关键点在于资源隔离防止AI推理吃满节点资源、Gateway层做请求路由和提示词管理、模型按场景精简不贪多。7B量化模型在纯CPU上跑边缘异常检测准确率和延迟都能接受。搞边缘AI部署的同学如果正在评估本地推理方案这篇实测应该能帮你少踩坑。点赞收藏一下后续会补充分享多模型调度策略和边缘AI在工业质检中的落地经验关注不错过。