企业官网建设流程全解析

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

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服务打包成一个二进制，部署极其简单。

环境准备

边缘节点的硬件配置直接决定能跑多大的模型。实测参考：

物联网边缘节点通常用NUC或工控机方案。没有GPU也能跑，只是速度慢一些。7B量化模型在纯CPU上推理速度约10-15 tok/s，对非实时场景够用。

Docker Compose编排

单独docker run跑Ollama很简陋，生产环境应该用Compose管理。一个完整的边缘AI节点通常需要Ollama + 应用服务 + 监控：

version:"3.8"services:ollama:image:ollama/ollama:latestcontainer_name:ollamaports:-"11434:11434"volumes:-./ollama/models:/root/.ollamaenvironment:-OLLAMA_HOST=0.0.0.0:11434-OLLAMA_MAX_LOADED_MODELS=2-OLLAMA_NUM_PARALLEL=2restart: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:8000"environment:-OLLAMA_URL=http://ollama:11434-MODEL_NAME=qwen2:7brestart:unless-stoppedmonitoring:image:prom/node-exporter:latestcontainer_name:node-exporterpid:hostrestart:unless-stoppedcommand:---path.rootfs=/hostvolumes:-/:/host:ro

几个关键配置点。OLLAMA_MAX_LOADED_MODELS=2限制同时驻留内存的模型数量，避免内存溢出。OLLAMA_NUM_PARALLEL=2允许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 app=FastAPI(title="IoT AI Gateway")ollama_url=os.getenv("OLLAMA_URL","http://ollama:11434")model_name=os.getenv("MODEL_NAME","qwen2:7b")classInferenceRequest(BaseModel):device_id:strsensor_data:dicttask:str="anomaly_detection"classInferenceResponse(BaseModel):device_id:strresult:strconfidence:floatlatency_ms:int@app.post("/api/analyze",response_model=InferenceResponse)asyncdefanalyze_device_data(req:InferenceRequest):start=time.time()# 构造提示词prompt=build_prompt(req.sensor_data,req.task)# 调用Ollama推理asyncwithhttpx.AsyncClient()asclient:resp=awaitclient.post(f"{ollama_url}/api/generate",json={"model":model_name,"prompt":prompt,"stream":False,"options":{"temperature":0.3,"num_predict":200}},timeout=30.0)ifresp.status_code!=200:raiseHTTPException(status_code=502,detail="Model inference failed")result=resp.json()latency=int((time.time()-start)*1000)# 提取推理结果text=result.get("response","").strip()confidence=parse_confidence(text)returnInferenceResponse(device_id=req.device_id,result=text,confidence=confidence,latency_ms=latency)defbuild_prompt(sensor_data,task):"""根据任务类型构造提示词"""iftask=="anomaly_detection":return(f"设备传感器数据:{sensor_data}\n"f"判断是否存在异常，输出JSON格式: "f'{{"anomaly": true/false, "reason": "..."}}\n'f"只输出JSON，不要其他内容。")eliftask=="fault_diagnosis":return(f"设备传感器数据:{sensor_data}\n"f"如果数据异常，分析可能的故障原因，简要说明。")returnf"分析以下数据:{sensor_data}"defparse_confidence(text):"""从模型输出中提取置信度"""if"high"intext.lower():return0.9elif"medium"intext.lower():return0.6return0.5

Gateway做了几件事：把设备ID和传感器数据封装成结构化请求、构造针对性的提示词、调用Ollama推理并返回延迟信息。temperature=0.3降低随机性，让推理结果更稳定。

物联网场景实测

在工控机（i7-12700, 32GB RAM）上实测以下场景：

设备异常检测：设备每30秒上报一次传感器数据（温度、振动、电流），Gateway调用7B模型判断是否异常。

85%的准确率跟GPT-4级别的模型有差距，但在边缘场景下——能离线运行、不产生API费用、延迟可控——已经够用。关键是把模型当作"预筛器"：模型判断为异常时再触发云端深度分析，减少云端调用量。

资源管理：防止边缘节点被AI吃满

Ollama推理时会吃满CPU，如果边缘节点同时跑着数据采集服务，推理可能导致数据采集中断。用Docker的资源限制来隔离：

services:ollama:# ... 其他配置deploy:resources:limits:cpus:"6"# 限制6核（留2核给其他服务）memory:8G# 限制8GB内存reservations:cpus:"2"memory:4G

CPU限制让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在工业质检中的落地经验，关注不错过。