XY同学我见过太多做AI应用的人，把全部身家押在某个平台上，结果平台一关、价格一涨、接口一变，整个项目直接归零。这也是为什么我越来越坚定地做本地AI基础设施这套东西。我做的AIStarter + PanelAI，本质上不是去追某个模型，而是在搭建一套自己可控的基础设施底座。这篇文章我会把"为什么我还在坚持这件事"、"这套组合到底在解决什么问题"、"从零开始落地需要走哪些路"、"它的收益边界在哪"以及"我踩过的坑"一次说清楚，适合正在纠结自建还是用平台、有数据安全顾虑、或者想搭建私有AI服务的人。
1. "90%平台都死了"：这句话到底在说哪个环节死了
1.1 平台死掉的方式各有不同，但死因大同小异
你可能注意到一个现象：每隔几个月就有一批AI平台项目宣布停止服务、调整业务方向、或者被收购后逐步关停。标题里说"90%平台都死了"，这个数字不一定精确，但方向是准的。
我梳理过这些平台的死法，基本可以分成几类。
第一类是"生态位不清晰"的平台。它们做的事情是：把模型能力包一层壳，做成一个标准API对外卖。问题是，模型能力本身来自上游大厂，平台没有独占资源；下游客户又随时可以绕开平台直接对接模型厂商。中间层的价值非常单薄，一旦上游降价、或者下游发现直连更便宜，平台立刻被抽空。
第二类是"靠补贴维持"的平台。早期为了抢用户，API价格压得非常低，甚至免费。看起来热闹，但研发成本、算力成本、支持成本全是真实支出。补贴总有一个尽头，停止补贴的那一刻，用户流失比来时还快。
第三类是"被合规成本压垮"的平台。模型安全审查、数据出域备案、内容合规，每一项都是持续投入。对大型公司来说这是必要成本，对创业团队来说，这可能是致命的现金流黑洞。
这几类平台的死因表面不同，本质上都是同一个问题：它们没有形成足够深的壁垒，也没有找到可持续的成本结构。
1.2 平台时代的"免费API/低价接口"陷阱
我说句难听的话，很多开发者对平台免费API的依赖，已经到了一种危险的地步。
我见过不少团队，产品原型跑在别人的免费接口上，然后跟投资人讲的故事是"我们基于最新的大模型构建"。问题是，你基于的模型是别人的，接口的配额是别人给的，定价权也在别人手里。你整个产品的命脉，被一个你完全控制不了的外力捏着。
免费API最典型的路径是：前期给足额度，等你产品做起来、用户量上来，然后突然改规则、限制并发、提高价格。你不是没得选，只是这时候你的代码已经深度耦合在那个平台上了，迁移成本高到让你心痛。
还有一种更隐蔽的坑是"看起来便宜，实际很贵"。有些平台的API单价确实低，但你需要额外支付向量化费用、知识库托管费用、推理加速费用、日志分析费用，七七八八加起来，单位成本早就超过了直接自建。而且这些费用拆分得很碎，你在对账的时候才会发现，每一笔都不大，加起来吓人。
1.3 平台服务商和开发者之间的错位
我不是全盘否定平台模式，平台确实有它的价值：快速验证、免运维、弹性扩缩容。中小团队在早期用平台，是完全理性的选择。
但我要说一个更深层的错位：平台服务商的商业逻辑和开发者的长期利益，天然存在冲突。
平台想要的是用户留在自己体系内，用他们的API、存储、数据库、监控，形成绑定；开发者想要的是可控、可迁移、成本可预测。这两个目标在短期可以兼容，在中长期一定打架。你越是深度依赖某个平台，你就越难按照自己的节奏迭代。
所以我在设计AIStarter + PanelAI的时候，第一原则就是"自包含"。模型可以换，运行环境可以重建，API接口风格统一，数据留在本地。平台是我的过渡工具，而不是我的地基。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. AIStarter + PanelAI 到底解决了什么：本地AI基础设施的定位
2.1 这套组合的分工逻辑
先说一下我自己的理解。AIStarter负责的是"启动层"，它解决的是本地模型运行时的一键拉起、环境依赖管理、GPU资源分配、模型进程守护这些问题。PanelAI负责的是"管理面板层"，它解决的是多模型统一管理、API密钥分发、用量统计、日志查看、前端对话界面这些偏"人机交互"的问题。
两件事分开做，是因为它们面向的对象不同。AIStarter更像是一个底层守门人，它不需要花哨的界面，但必须在断电重启、显存残留、进程崩溃之后，还能把模型服务拉起来。PanelAI则必须界面友好、信息清晰，让团队里的非运维角色也能看到当前的模型状态、调用情况、成本消耗。
这种分工的逻辑其实和传统后端开发很像：systemd负责守护服务，Nginx负责暴露入口，Grafana负责展示状态。AIStarter对应前两者，PanelAI对应后者，只不过这里管的是"模型进程"和"推理请求"。
2.2 为什么必须是"本地"而不是"私有云"
很多人会说，既然要可控，那我买台云服务器不也一样吗？说实话，不一样的。
"本地"这个词，我强调的不是物理位置，而是"数据不出域"和"链路自主可控"。你在云上买一台GPU服务器，虽然服务器名义上是你的，但数据仍然经过了云厂商的基础设施。对于有严格数据合规要求的场景，比如医疗记录、企业内部文档、用户隐私数据，这仍然是不可接受的。
另一个现实因素是可迁移性。本地的硬件资产是实打实属于你的，今天可以用这台机器跑模型，明天换更好的显卡，把环境迁移过去就行。而云上的GPU实例，本质是租来的，实例释放后一切归零。
还有一个很多人没提的点：本地基础设施天然就是一种成本上限管控。 你买了一张显卡，算力上限就摆在那里，你会主动去优化模型、裁剪数据、控制请求量。而在云上，弹性扩容按钮就在那里，点一下成本就上去，很多人根本控制不住自己。
2.3 设计上的三个关键取舍
在搭建这套本地AI基础设施的过程中，我做了三个关键取舍。
第一个取舍是"模型可换优于模型最强"。很多人上来就要跑最大的模型，但我的思路是先把接口层抽象出来，让底座可以随时接入不同的模型运行时。今天可能跑的是7B/8B量级的开源模型，明天有更好的开源模型出现，我只需要改一行配置就能切换，不需要改业务代码。
第二个取舍是"服务稳定优先于功能丰富"。PanelAI的功能列表我一直在做减法。一个好用的管理面板，不是功能越多越好，而是"该有的都有，不该有的绝不塞进来"。API密钥管理、请求日志、用量统计、模型健康状态，这四样是核心。花哨的仪表盘、复杂的报表，优先级都往后放。
第三个取舍是"默认不调外部API"。整套系统的默认配置是全部离线可跑。只有在用户主动配置外部模型服务时，才会发出网络请求。这个设计的初衷是：默认状态必须是安全、可控、可复现的，特殊能力靠配置开启，而不是默认开启。
3. 从零搭一套本地AI基础设施：从选硬件到跑通对话
3.1 硬件选型的第一原则：先看显存，再看算力
很多人搭本地AI第一步就是去挑显卡，盯着算力数据看半天。我的建议是反过来的：先确定你要跑的模型参数量级，再反推显存需求，最后才看算力。
这里有一个粗略但好用的估算方法。以量化后的模型为例：7B模型在4-bit量化下大约需要5GB到6GB显存，13B模型大约需要9GB到10GB，70B模型则需要40GB以上。这还只是模型权重的占用，实际推理时还要加载KV Cache、中间激活值，所以建议在模型权重占用基础上再留30%到50%的余量。
如果你主要跑7B到14B的模型，一张24GB显存的消费级卡就够用了，比如RTX 3090、4090，性价比很高。如果确定要跑70B级别的大模型，那就需要两块24GB的卡做张量并行，或者直接考虑48GB显存的专业卡，成本会明显上升。
内存也不能忽视。模型在反量化、预处理、以及跑CPU offload的时候会大量吃内存。我建议整机内存至少是显存的2倍，64GB起步会舒服很多。硬盘方面，模型文件动辄十几GB甚至几十GB，建议直接用NVMe固态，加载速度差好几倍。
3.2 模型运行时的选择：为什么我优先考虑这些runtime
模型跑起来需要runtime，我的选择逻辑是：能离线、无额外obfuscation、社区活跃、兼容性好。
以最常见的Ollama为例，它的优势是安装简单、模型管理方便、一条命令就能把模型跑起来，对新手极其友好。llama.cpp则是更底层的选择，纯C/C++实现，依赖少，适合嵌入手写脚本或运行在低配设备上。vLLM更适合高并发、长文本场景，吞吐量优势明显，但安装配置复杂度也更高。
AIStarter在设计上做了一层运行时抽象，不会绑定某一个runtime。它的做法是：把"模型启动命令"、"环境变量"、"端口映射"、"健康检查方式"写成配置文件。你要切运行时，改配置而不是改代码。
这里分享一个通用化的操作路径，具体细节以你自己的环境为准。
首先，安装运行时和下载模型。比如用Ollama，就两步：
bash复制curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:7b
然后确认模型能正常响应：
bash复制ollama run qwen2.5:7b "你好"
我建议你先跑通这一步，再接入管理面板，不要一上来就搞复杂架构。这个基础能跑通，再往后都是按部就班的配置工作。
3.3 启动器与面板的接线方式：模型层、服务层、API层
我的实践里，AIStarter + PanelAI的接线逻辑可以拆成三层。
模型层是最底层，指具体的运行时和模型文件，比如Ollama进程、vLLM服务、或者通过llama.cpp启动的本地HTTP服务。这一层的主要责任是"让模型能响应用户请求"。
服务层是中间层，它负责把不同模型的调用方式统一成一个内部标准格式。不同runtime的请求格式可能不一样，有的兼容OpenAI格式，有的不兼容，AIStarter的职责就是屏蔽这种差异，向上层暴露一个一致的接口。
API层是最高层，PanelAI在这里做密钥校验、并发控制、请求日志、用量统计。业务系统只需要拿着API Key访问PanelAI提供的统一入口，不需要关心背后跑的是哪个模型、哪个runtime。
这个三层设计的核心好处是职责分离。某一天你想把Ollama换成vLLM来提升并发，你只动模型层和服务层的配置；某一天你想给某个业务线单独分配配额，你只需要在API层操作，模型完全不用动。
3.4 一个最小可用的部署拓扑
我直接给一个我实际使用的、最小可用的部署拓扑，仅供参考。
- 一台带GPU的Linux主机（Ubuntu 22.04是我最常用的系统）；
- 安装Docker，AIStarter和PanelAI都跑在容器里，方便管理依赖与迁移；
- 模型runtime选择Ollama容器模式，通过
--gpus all参数透传GPU； - 面板通过端口映射暴露到局域网，默认绑定127.0.0.1，需要外部访问时再通过反向代理加鉴权。
完整流程大概是这样：AIStarter容器启动后，会自动检查Ollama容器是否健在、需要的模型是否完整、显存是否正常。如果一切正常，它把Ollama的地址上报给PanelAI；PanelAI探测到模型服务可用之后，在界面上显示"运行中"，同时开放API入口。这个过程完全本地化，不需要外部网络。
有一个比较实用的技巧：如果你只有一台机器，面板和模型运行时容易抢资源。我建议在docker-compose里给容器设置CPU和内存限制，至少保证面板进程在模型OOM的时候不会被一起带走。我用docker的mem_limit和cpus参数分别限制，效果很稳。
4. 本地AI基础设施真正值得投入的场景与收益边界
4.1 适合自建的场景：数据敏感、高频调用、定制需求
先说结论，再展开。我判断一个场景适不适合自建本地AI基础设施，就看三条：数据敏感程度高不高、调用频率高不高、定制需求强不强。
数据敏感场景大家都能理解，企业内部的知识库问答、代码辅助、客服系统，这些数据出了域就存在风险。自建把数据牢牢锁在自己手里，这是任何云平台都给不了的安全感。
高频调用场景很容易被低估。看起来每次调用成本不高，但如果你每天要处理几十万次调用，累积起来就是一笔极大的开销。自建之后，主要的边际成本是电费和硬件折旧，你可以在一个固定的成本上做无限的优化，而API调用每一笔都要付费，省不下来。
定制需求这里我特别说一句。平台API给你的能力是"模型能力"，不是你业务场景的"解决方案"。你需要做模型微调、few-shot样例管理、特殊词表过滤、私有知识库融合，这些在平台上要么做不了、要么贵得离谱、要么受平台限制。而本地基础设施允许你完全掌控这条链路，想怎么改就怎么改。
4.2 不适合自建的场景：任务稀疏、紧急上线、需要巨大模型
有适合就必然有不适合，我不想把自建说得天花乱坠。
任务稀疏的场景就不适合。如果你只是偶尔跑几次推理、做做原型验证，自建的成本要远高于用API。一台GPU服务器的闲置成本、维护成本、电费成本，分摊到每个月那几次请求上，单次成本高得吓人。这种时候老老实实按量付费，才是最理性的选择。
紧急上线的场景也容易翻车。自建基础设施需要时间：买卡、装机、配环境、调性能、压测。如果你下周就要上线，自建绝对来不及，这时候直接买平台API是最稳的。
需要巨大模型的场景要谨慎。当前顶尖的闭源大模型参数量是几千亿级别，你需要的数据中心级算力，不是几块显卡能解决的。本地AI基础设施更适合7B到70B这个区间的模型，再往上，成本和收益就非常不划算了。
4.3 成本账：不只是GPU的费用
我把自建的成本拆给你看，你大概心里有数。
硬件成本：一块RTX 4090大概在一万五到两万之间，整机配下来三到五万是很正常的。这个是一次性投入，不产生持续费用，但你需要考虑折旧。
电力成本：满载运行的话，一块4090的功耗在350W左右，整机加上CPU和其他配件，一台机器峰值功耗可能到800W甚至更高。按每天运行8小时算，一个月的电费大概几百块钱。如果不关机，成本会翻倍。
维护成本：这个最容易被忽略。模型版本升级、环境依赖冲突、显存泄漏、磁盘占满、面板本身出bug，这些都是真实时间支出。我把自己的维护频率做了一个统计，每月大约需要两个半天处理这些杂事。如果你的时间成本高，要把它算进总账里。
对比来看，API方式的成本是线性增长的，调用越多付费越多；自建是前面集中投入、后面边际成本递减。如果你能预估到未来12个月内的调用量稳定在一个较高水平，自建大概率是划算的。如果做不到，建议先用API。
5. 踩过的坑和未来方向
5.1 模型兼容性这个坑
我踩过最浅但最频繁的坑，是模型兼容性。
不同模型的对话模板不一样，有的用ChatML格式，有的用Alpaca格式。同一个模型在不同runtime下，输出格式可能有细微差别。最离谱的一次，我换了一个runtime之后，模型输出的内容格式全部错乱，排查了半天才发现是模板文件中一个特殊token没有正确转义。
我的经验是：在接入一个新模型之前，先在命令行里手工跑一次对话，确认输出格式正确后再接入面板。不要直接进配置，否则出了问题，你根本分不清是模型问题、runtime问题、还是面板解析问题。
5.2 显存管理的隐形损耗
显存管理是一个极其隐蔽的坑。模型进程退出后，显存并不总是立刻释放。如果之前的进程崩溃了，残留显存会占用着不放，新进程启动时直接OOM。
我现在的做法是：面板里加一个"重置显存"按钮，在启动模型前强制检查一次显存占用。具体实现不复杂，通过nvidia-smi查询已用显存，如果超过阈值就给用户明确提示，避免在显存不足的情况下盲目启动新模型。
还有一点很关键：多个模型并发加载时，显存是共享的。你不能假设每个模型都按理论上的最小显存占用计算。实测下来，同时加载两个模型时，实际占用往往大于两者单独占用之和，因为CUDA context本身就会消耗几百MB显存。要给每个模型预留额外的安全余量。
5.3 升级与回滚
自建基础设施最大的痛点是升级。你装好了环境，跑了三个月的模型，突然新版本runtime出来了，性能提升很诱人，但升级之后旧模型可能跑不了了。
我的建议是建立一个简单但可靠的回滚机制。具体做法：把容器的镜像打上版本标签，每次升级之前，先把当前可用的镜像tag保存好。一旦升级后出现问题，直接使用旧tag重新启动容器，一分钟之内回到升级前的状态。这个习惯成本极低，但能救你无数次。
另外重要的一点是：不要把模型文件和程序放在同一个目录里。 如果你需要回滚，程序版本可以切换，但模型文件应该是一个独立的路径，不被版本化覆盖。我已经见过不少人升级程序时误删了整个模型目录，然后被迫重新下载几十GB的文件，那种绝望我懂。
5.4 生态仍在快速变化，怎么决定追赶还是等待
最后聊一下方向感。现在的模型生态变化极快，每隔几个月就有新的模型、新的运行时、新的推理优化方案出现。身处这种环境，一个很自然的心态是焦虑——害怕自己用的方案很快就过时了。
我的经验是：区分"核心价值"和"外围工具"。 你的核心价值是业务逻辑、数据沉淀、用户体验，这些不会因为模型换了一个版本就失效。模型和runtime只是外围工具，它们应该通过配置层可替换，而不是焊死在你的代码里。
所以我对"追赶"和"等待"的判断标准是：新东西能不能直接提升业务效果？如果能，花时间迁移是值得的；如果只是参数好看、跑分更高，但对实际业务没有明显帮助，那就再等等。框架在变、模型在变、API在变，但你的业务数据、你积累的评测集、你对用户需求的理解，这些才是真正的时间复利。
最后再分享一个实践细节。我一直坚持定期手动跑一遍"冷启动演练"：把机器完全关机，断电重启，然后观察AIStarter和PanelAI能否在无人干预的情况下，把服务恢复到正常状态。这个动作看起来原始，但它能暴露出一堆平时看不见的问题——比如某个服务没有设置开机自启、某个路径在重启后不存在、某个密钥在环境变量里丢失了。基础设施这行，稳比快更重要。你日常觉得"一切正常"不代表真的正常，只有经历过一次冷启动、断电、迁移的考验，你才会知道这套东西到底是不是靠谱。