做AI应用部署选型我已经被问过太多次。今天就说说我个人第一次把AI应用放到公网时经历的那个纠结ECS、轻量服务器、函数计算到底选哪个如果你也是个人开发者手里攥着几千块预算想把自己的第一个AI应用部署上线这篇内容就是给你准备的。先说结论没有绝对正确的答案但有一个相对稳妥的判断框架。你不需要懂太多云计算的底层原理只需要搞清楚自己的应用是什么形态、模型多大、流量稳不稳定答案基本就浮出水面了。这篇文章我会把三样东西的本质、AI应用的特殊性、以及我踩过的坑全部摊开来讲帮你在30分钟内做出一个不后悔的选择。1. 先搞清楚三样东西到底是什么很多人在选型的时候卡住不是因为选择太少而是因为对三个云产品只有模糊的“好像听说过”的印象。我先把它们翻译成人话再来谈怎么选。1.1 ECS云上的一台整机灵活但费心ECSElastic Compute Service本质就是你在云上租了一台电脑。CPU、内存、系统盘、带宽、公网IP全部可以自己拼装装什么系统、装什么软件、跑什么服务完全由你说了算。它的优势非常明显没有任何人为限制。你想装GPU驱动就装GPU驱动想挂载额外的数据盘就挂载数据盘想编译自定义内核也行。你甚至可以把它当成一台普通服务器用想干嘛就干嘛。对AI应用来说如果你需要GPU推理现阶段基本只有ECS这类云服务器能接得住。但它有一个致命伤所有维护工作都是你的。系统补丁要自己打安全漏洞要自己补防暴力破解要自己做日志要自己看数据备份要自己设。我第一次用ECS的时候光配置一个带安全加固的Nginx就折腾了一个晚上后来想想大部分精力根本没花在业务上全花在“养机器”上了。我打个比方ECS相当于你全款租了一套毛坯房墙壁、水电、地板、家具全都要自己搞。上限很高但下限也很低新手很容易在装修阶段就心态崩了。1.2 轻量应用服务器拎包入住的小机箱个人项目首选轻量应用服务器简称轻量本质上也是云服务器但云厂商帮你做了大量简化预设系统镜像、预设运行环境、提供傻瓜式控制台你不需要懂太多Linux知识也能把网站或应用跑起来。它最吸引人的地方是性价比。以常见的套餐为例同样是2核4G轻量的价格通常比同规格的ECS便宜而且带宽往往给得更大——很多轻量套餐直接给3M、5M甚至更高而ECS有时候默认带宽只有1M这点差距对个人项目来说体验差别很明显。但轻量服务器也有它的局限性。第一个局限是几乎没有GPU实例可选如果你想在云上跑大模型推理、做视频渲染、跑Stable Diffusion出图轻量基本帮不上忙你只能退回到本地算力或者外部推理服务。第二个局限是扩展能力被阉割很多轻量机型不支持自定义镜像网络配置也不能像ECS那样随意调整如果你中途想升级配置可能只能整体迁移。第三个局限是底层性能有封顶虽然日常够用但如果并发一高CPU和内存的瓶颈很快就会出现。轻量服务器就像拎包入住的精装小公寓家具齐全锅碗瓢盆都备好了你只需要带上行李就能住。但公寓的户型、承重、扩展空间都固定了想拆墙改造基本不可能。1.3 函数计算用完即走的公共厨房按次计费函数计算Function Compute是完全不同的思路你不需要关心服务器只需要上传一段代码或一个容器镜像声明“这个函数在什么事件触发时运行”云端就会自动帮你把环境拉起来、执行完毕、然后把资源释放掉。它的收费模式是按调用次数和资源消耗量来计算也就是说你的函数不被调用的时候你几乎不花一分钱。这种模式对突发流量简直是天生友好——平时没请求时零成本突然来了10万次并发请求也能自动弹性扩容扛住。但是函数计算有三个对AI应用很不友好的硬伤冷启动、执行时间限制和长连接限制。冷启动函数计算为了省钱空闲一段时间后会把实例销毁。下一次请求来时需要重新拉起运行环境、初始化依赖、加载模型这个时间可能长达几秒甚至几十秒。你的用户第一次访问时很可能直接等到超时。执行时间限制大部分函数计算平台单次执行时间默认只有几分钟有一些可以调到十几分钟如果你的任务是长时间运行的推理或训练根本没法塞进去。长连接限制函数计算天然是无状态、按请求调用的适合HTTP API但WebSocket、流式输出这类长连接场景非常别扭即便平台支持也有很多隐藏的限制。函数计算给我的感觉就像共享厨房你带着菜去按次付费做完就走连洗碗都省了。但它不适合你长期占着炉子炖一锅老火汤。对比维度ECS轻量应用服务器函数计算技术本质云上整机简化版云上整机无服务器运行环境管理难度高低很低成本模式包月/包年为主包月套餐为主按调用量计量GPU支持有GPU实例基本没有极少且昂贵冷启动无无明显存在长连接支持好好不适合典型AI场景GPU推理、自定义环境CPU推理、持续在线服务API接口、事件任务2. AI应用选型不是照搬普通网站那套逻辑很多人做选型的时候下意识会把AI应用当成普通Web应用来思考——“不就是跑个服务吗哪个服务器便宜选哪个”。这个思路对传统CRUD应用可能没问题但AI应用有三个非常明显的特殊性会直接影响选型结果。2.1 AI应用到底在“吃”什么资源普通网站的瓶颈多半在数据库和带宽但AI应用的瓶颈几乎全部集中在推理这一环模型加载到内存里要占多少空间跑一次前向传播需要多少CPU算力或GPU显存响应延迟能不能控制在可接受范围内。以我实际部署过的项目为例一个BERT系列的文本分类模型PyTorch版本加载后大约占1.2GB内存CPU单次推理耗时约0.2秒一个7B参数的语言模型即使量化到4bit也需要大约4GB到6GB的内存纯CPU推理生成一个token可能要几百毫秒如果是SD系列文生图模型没有GPU基本就告别实时出图了。所以在选型之前你必须先做一个动作在本地把模型跑通把内存占用和单次推理延迟测出来。这一步没人能替你完成但绝大多数人都会偷懒跳过结果就是——买了台2核4G的服务器高高兴兴部署完一调用就OOM或者等30秒才出结果。选型的第一条铁律先问你的模型多大、推理一次吃多少内存、要不要GPU再去看云产品的价格和配置。很多人反过来先看价格结果买了带不动的配置最后只能反复折腾。2.2 冷启动、长连接与状态管理函数计算的三道坎如果你打算用函数计算来部署AI应用我建议你先做好心理建设因为三道坎几乎是绕不开的。第一道坎是冷启动。我见过不少人把一个小型LLM放进函数计算本地测试一切正常一上生产就出问题。原因很简单冷启动时要拉镜像、初始化Python环境、加载模型文件整个过程算下来二三十秒前端早就超时了。有人问我能不能用预留实例解决可以但预留实例意味着你要一直为其付费那就等于放弃了一半的“省心省钱”优势。第二道坎是长连接。AI应用里常见的流式输出、语音对讲、实时监控等场景本质上都需要维持一条长连接而函数计算的设计哲学是“用完即走”它对短连接HTTP请求支持极好但对WebSocket这类长连接的支持始终差一口气。第三道坎是有状态。很多AI应用不是“请求一次就结束”的比如一个语音唤醒的宠物应用它需要记住用户上次说话的内容、需要维护多轮对话的上下文、需要保存会话状态。函数计算要求你把这些状态全部放到外部存储Redis、数据库或对象存储里能实现但复杂度直接翻倍。我自己就试过把一个多轮对话机器人塞进函数计算结果为了管理会话状态写了一大堆Redis读写代码比写推理逻辑还累最后实在受不了直接迁回服务器。2.3 账单要自己算清楚别被“免费额度”骗了函数计算按调用次数计费看着很诱人——“0.1元一次哪怕一天1000次也才100块”但这是典型的只看单价不看总账。函数计算的费用由几部分组成调用次数费用、资源量费用GB-秒或GB-s、公网流量费用、日志服务费用。资源量费用的计算方式是“内存大小 × 执行时间”如果您的函数每次执行2秒、占用1GB内存那么等于每次消耗2GB-秒。假设每月有100万次调用光资源量费用就是100万×2GB-秒200万GB-秒按单价0.000111元/GB-秒算大约222元加上100万次调用的触发费约20元再加上流量费月账单基本稳定在300到500元之间。而一台2核4G的轻量服务器包年价格往往只要几百块到一千出头流量只要不超套餐限制就不额外收费。如果您的服务每天都有稳定的调用量函数计算反而不便宜。当然如果您的服务是“偶尔被调用一下”型比如一个个人博客的AI摘要接口、一个只有朋友偶尔用一下的问答Bot函数计算的零闲置成本就很有优势。说到底算账的核心不是比单价而是预测你的流量形态。稳定持续流量 → 服务器类产品便宜突发流量、长时间闲置 → 函数计算便宜。3. 我建议的选型路径与方法前面讲了原理和坑下面给出一套可以直接复用的判断流程。这套流程是我自己反复调整后沉淀下来的不敢说适合所有人但至少能让大多数个人开发者在30分钟内锁定理性的方向。3.1 先回答三个问题答案自动浮现第一个问题我的模型需要GPU吗如果需要GPU做推理比如跑Diffusion模型、大语言模型答案非常明确函数计算和轻量服务器基本都不合适你只能选ECS弹性裸金属或GPU云服务器或者把推理放到第三方推理平台上通过API调用。如果只用CPU就能跑比如文本分类、小型语音识别、量化后的1.5B模型那么三选一继续往下看。第二个问题我的服务需要长连接、持续在线、保存状态吗如果需要比如语音唤醒宠物应用、实时流式输出、多人对话服务直接把函数计算排除。函数计算可以在没有请求时释放资源但你的应用需要一直在线监听或者需要维护连接状态轻量服务器和ECS才是正确方向。如果只是短请求的API接口函数计算进入候选名单。第三个问题我的流量是稳定持续还是间歇突发稳定持续 → 轻量服务器/ECS包年包月固定成本低性价比高。 间歇突发 → 函数计算空闲时零成本突发时自动扩容。把这三个问题的答案串起来基本上就能判断了。3.2 第一次部署AI应用的推荐路径很多新手会陷入一个误区先买服务器再研究部署最后发现配置不对然后退货重买。我不建议这么做。我建议第一次部署AI应用时走下面这条路径第一步本地先把模型跑通。用你自己的笔记本或台式机写一个简单的推理脚本测出模型加载耗时、单次请求延迟、内存占用。这个数据决定了后续选型的底线。第二步如果应用形态接近API接口优先用函数计算做一个最小验证。把推理逻辑包成函数用云平台自带的测试工具直接触发看看冷启动和响应延迟能不能接受。这一步的成本极低通常是几毛钱的事。第三步如果函数计算验证不过关延迟太高、状态管理太复杂再考虑轻量服务器。先买一个最低配置的套餐用Docker或systemd把服务跑起来公网访问一下看延迟和稳定性。第四步如果发现CPU性能不够、需要GPU再切割升级到ECS GPU实例。这一步通常发生在产品真正有了用户之后而不是一开始。这条路径的核心逻辑是用最低成本和最少操作先跑通全链路再根据真实数据决定是否“升舱”。我第一次就是直接买了台高配ECS结果配置完系统就花了两天最后发现业务需求根本没那么复杂白白浪费了钱和时间。3.3 一个最小可部署案例把文本分类模型变成公网API为了让你更直观地理解整套流程我拿一个最常见的例子走一遍把一个文本分类模型变成公网API。假设模型本身已经用ONNX导出推理脚本在本地正常运行接下来要在云上对外提供服务。第一步选一台轻量服务器配置2核4G、带宽3M到5M系统镜像选Ubuntu 22.04价格大概几十块一个月。这个配置足够跑小型ONNX模型了。第二步SSH登录后安装基础环境apt update apt install -y python3-pip pip install fastapi uvicorn onnxruntime第三步写一个最简单的FastAPI接口加载模型、做推理、返回JSONimport onnxruntime as ort from fastapi import FastAPI from pydantic import BaseModel app FastAPI() session ort.InferenceSession(model.onnx) class Item(BaseModel): text: str app.post(/predict) def predict(item: Item): inputs tokenizer(item.text, return_tensorsnp) # 伪代码实际按模型输入处理 outputs session.run(None, dict(inputs)) return {label: int(outputs[0].argmax())}第四步启动服务并设置自动重启uvicorn main:app --host 0.0.0.0 --port 8080建议用systemd或进程管理器如supervisor托管进程挂了能自动拉起避免半夜服务下线没人发现。第五步在云控制台的安全组/防火墙中放行8080端口。这一步非常关键很多新手卡在这里——本地访问正常公网死活不通多半就是安全组只放行了22端口其他端口全被拦了。第六步通过http://公网IP:8080/docs访问FastAPI自动生成的接口文档直接在页面上测试接口。整个过程大概一小时能搞定。没有GPU没有复杂的Dockerfile没有K8s就用最朴素的方式把AI应用暴露到公网。等以后流量上来了再考虑用更高阶的部署方案也不迟。4. 常见问题与避坑实录这部分是真正的干货所在。我把自己在实际部署中踩过的坑、后来复盘总结出来的经验都整理在下面希望对你有参考价值。4.1 我踩过的三个大坑第一个坑买了ECS服务也启动了但外面就是访问不了。查了代码、查了Nginx、查了防火墙折腾了两个小时最后发现是云安全组没开放端口。云服务器的“防火墙”其实有两层操作系统自带的防火墙iptables/firewalld和云平台的安全组。安全组相当于云平台的“上游关卡”它不放行你系统里怎么配置都没用。所以无论是买ECS还是轻量服务器第一步一定要先检查安全组的入方向规则。第二个坑轻量服务器带宽看着是5M但并发一高响应就变慢。我一开始以为是代码有问题一顿排查后发现是带宽被跑满了。5M带宽的理论峰值只有每秒约640KB如果你的接口返回一个稍大一点的JSON或者图片几十个并发就能把带宽塞满。对于AI应用如果返回的是JSON文本问题不大但如果做的是图片生成、语音合成这类返回多媒体文件的任务带宽是绝对不能忽视的瓶颈。第三个坑函数计算部署了模型结果第一次调用等了30秒前端直接超时。原因就是冷启动加模型加载。解决办法有几个一是预留实例相当于让函数计算时刻保活一个实例冷启动问题直接消失但你要持续付钱二是把模型放进对象存储函数启动时快速拉取尽量缩小镜像体积三是把函数计算的超时时间调到上限然后在前端加loading提示。不过说实话如果你需要经常处理这种延迟问题说明函数计算可能不太适合你的场景。4.2 运维技巧个人开发者的“低成本保命方案”个人开发者没有专职运维所以一定要把出问题的概率降到最低同时把恢复时间缩到最短。第一代码和模型一定要分开管理。代码用git托管模型文件用对象存储保存不要只存在本地磁盘上。否则实例一释放模型文件全没了那才叫欲哭无泪。第二一定要做进程守护。用systemd或Docker的restartalways策略保证进程挂了能自动拉起。AI推理任务偶尔会出现内存泄漏或段错误没有守护机制服务可能在你睡觉的时候就悄悄下线了。第三公网可用性监控必不可少。用UptimeRobot之类的免费检测工具每隔几分钟访问一次你的公网接口一旦监测到服务不可用立刻发邮件或消息通知你。这比你自己没事刷新网页靠谱一百倍。第四设置账单告警。尤其是按量付费的实例和函数计算一定要在云平台设置费用预警超过一定金额自动通知。我见过不少人月底看到账单直接傻眼。第五最低限度学一点Linux基础命令。复制文件、看日志、查端口、管理进程、编辑配置这五件事会了基本就能应对90%的日常运维需求了。4.3 什么时候该“升舱”或“降舱”选型不是一锤子买卖你的应用随着时间和流量的变化可能需要调整部署方式。如果你一开始选了函数计算但发现冷启动导致用户流失说明这个方案不适合你的业务形态尽早迁到轻量服务器或ECS。如果你一开始选了轻量服务器后来发现CPU长期90%以上、内存经常告警先别急着加钱升级配置。先做性能剖析看瓶颈是模型推理还是I/O很多时候优化一下代码比如用ONNX替代PyTorch、给模型加缓存就能解决一大半问题。如果你一开始很风光地上了GPU实例但实际每天只有零星几次调用建议认真算一笔账把GPU实例的钱换算成调用次数看看是不是降回CPU服务器或函数计算更划算。选型的关键是知道怎么“回头”。想顺利回头就要在写代码时做好平台解耦把模型推理封装成标准接口业务逻辑和推理逻辑分离。这样哪怕以后要从轻量迁到ECS、从ECS迁到K8s改动的成本都非常低。我在实际踩坑之后最大的一个体会是个人开发者的时间成本和注意力的价值经常被低估。省下的几十块钱可能远不够弥补你在服务器环境上折腾掉的一整天。反过来偶尔多花几十块买一份省心和可控往往比一味追求低价更划算。AI应用部署这条路没有一劳永逸的银弹但只要你把模型需求、流量形态、维护成本这三个变量看清了选择自然就清楚了。