小团队AI基础设施怎么做：一台机器、几个服务和最少运维

[admin]

小团队做 AI 应用，最容易被两种声音拉扯。一种声音说必须上 Kubernetes、分布式向量库、全链路可观测、模型微调平台和复杂网关，否则不够生产级。另一种声音说先把几个容器跑起来，有问题再说。前者常常把团队拖进运维泥潭，后者又容易让系统在第一个真实用户面前崩掉。更务实的答案在中间：一台可靠机器，几个边界清楚的服务，一套能恢复的备份，一组足够解释故障的监控，再加上严格的权限和成本控制。

小团队的 AI 基础设施不应该以“像大厂”为目标。大厂架构解决的是多团队、多区域、多租户、海量并发、复杂合规和长期平台演进问题。小团队最先要解决的是另一组问题：应用能不能稳定访问，模型调用能不能统一管理，知识库能不能查得准，文件能不能保存，日志能不能追踪，出错后能不能定位，机器坏了能不能恢复，费用会不会失控，密钥会不会泄漏。把这些做好，比过早上复杂平台更有价值。

“一台机器”也不是玩具化。它可以是一台 64GB 内存的工作站、一台带 GPU 的本地服务器、一台云主机、一台办公室小服务器，甚至是“本地机器加少量云 API”的混合形态。关键不在机器数量，而在服务边界：哪些东西必须本地可控，哪些东西可以走外部 API，哪些数据必须备份，哪些服务必须对外暴露，哪些入口只能内网访问。只要边界清楚，小团队完全可以用一台机器支撑早期生产级 AI 应用。

一、小团队基础设施先回答五个问题

第一个问题是用户从哪里进来。AI 应用可能是 Web 页面、企业微信机器人、飞书机器人、内部管理后台、API 服务或浏览器插件。入口决定认证方式、限流方式、日志粒度和用户体验。如果入口没有统一，后面的模型、知识库和文件系统都会被多个应用重复接入，权限也会变得混乱。

第二个问题是模型从哪里来。小团队通常不会只用一种模型。简单分类和摘要可以用便宜模型，复杂推理用强模型，隐私敏感内容用本地模型，图片或语音走专门服务。没有统一模型网关时，每个应用都会自己保存密钥、自己处理重试、自己估算成本，最后很难知道钱花在哪里、哪个模型质量最好、哪个用户调用异常。

第三个问题是知识和文件放在哪里。AI 应用离不开文档、图片、表格、聊天记录、向量、索引和中间产物。小团队常见失败是把文件随手放进容器目录，把向量库当唯一知识来源，把原文和索引分离后没有版本记录。结果是容器重建后文件丢失，索引能查到但不知道来自哪份原文，备份恢复后知识库状态不一致。

第四个问题是出错后怎么看。AI 系统的错误不只是 500。它可能是模型超时、提示词退化、RAG 召回差、工具调用失败、用户权限错误、API 余额不足、GPU 内存不够、向量索引版本错、文件解析失败。没有日志、指标和 trace，只看用户反馈，团队会把时间花在猜测上。

第五个问题是机器坏了怎么办。小团队最常说“后面再做备份”，但 AI 应用的数据往往从第一天就有价值：用户上传的文件、整理过的知识库、模型调用记录、人工修订、提示词版本、业务配置。备份不是上线后的豪华功能，而是基础设施的入场券。

这五个问题比具体技术栈更重要。Docker Compose、Caddy、LiteLLM、Ollama、vLLM、Postgres、pgvector、Qdrant、MinIO、Prometheus、Loki、OpenTelemetry、restic、Tailscale、NetBird 都只是可选答案。先定边界，再选工具。

二、一台机器可以承载什么

一台机器最适合承载早期 AI 应用的“控制面”和“轻中等数据面”。控制面包括反向代理、认证、应用后端、模型网关、任务队列、数据库、对象存储、日志、监控和备份。轻中等数据面包括中小规模向量检索、文档解析、缓存、异步任务、本地小模型推理。只要并发不高、数据量可控、恢复路径清楚，这种形态比多节点架构更容易维护。

一台机器不适合承诺高可用。机器断电、硬盘损坏、系统升级失败、网络中断，都会导致服务不可用。如果业务已经要求全年无明显中断，单机就是瓶颈。但早期团队常常还没到这个阶段。真正需要的是可恢复，而不是虚假的高可用。用户可以接受短暂停机，但不能接受数据丢失、恢复无路、问题不可解释。

单机架构的优点是操作路径短。服务都在一处，网络简单，数据路径可见，排查容易，成本清楚。Docker Compose 官方文档把 Compose 定位为定义和运行多容器应用的工具，用一个 YAML 管理服务、网络和卷。对小团队来说，这正好够用：把后端、数据库、向量库、对象存储、模型网关、监控组件放在一个 Compose 项目里，比手动启动多个服务稳定得多。

单机架构的缺点是资源争抢。模型推理、文档解析、向量构建、数据库查询和日志写入可能互相影响。GPU 机器尤其要小心：一个大模型占满显存，其他任务全部排队；一次批量向量化占满 CPU，Web 请求变慢；日志无限增长，磁盘被打满。小团队要用资源上限、队列、定时任务和磁盘告警控制这些风险。

判断一台机器是否够用，可以看四个指标：峰值并发、数据增长速度、恢复时间要求、团队运维能力。如果每天几十到几百个活跃用户、文档量在几十万段以内、允许数小时恢复、没有专职运维，一台机器加外部备份是合理起点。如果已经有大规模多租户、实时 SLA、海量文件和严格隔离，就不该假装单机能长期解决。

三、最小服务图：不要少了关键角色

小团队的一机 AI 基础设施，可以拆成九个角色。第一是入口代理，负责 HTTPS、域名、路由和基础访问控制。第二是应用后端，负责业务 API、用户、权限、任务和页面数据。第三是模型网关，负责统一接入外部模型和本地模型。第四是本地推理服务，负责隐私敏感或低成本模型调用。第五是数据库，保存用户、配置、任务、权限、提示词版本和业务记录。第六是向量检索，保存 embedding 和文档片段索引。第七是对象存储，保存原文、图片、导出文件和中间产物。第八是队列和后台任务，处理解析、索引、批量调用和重试。第九是观测与备份，负责日志、指标、trace、告警和恢复。

这九个角色不一定九个软件。Postgres 加 pgvector 可以同时承担数据库和中小规模向量检索；本地文件系统也可以先承担对象存储；应用后端可以内置简单队列；日志可以先从 Docker logs 起步。但角色不能消失。你可以暂时不用独立向量库，但不能没有“原文和索引如何对应”的设计；你可以暂时不用完整 tracing，但不能没有“每次模型调用怎么定位”的记录。

入口代理建议优先使用 Caddy、Nginx 或 Traefik 中团队最熟的一个。Caddy 的官方文档强调 automatic HTTPS，会在知道域名或 IP 时自动处理证书和续期，并把 HTTP 请求重定向到 HTTPS。对小团队来说，证书自动化很有价值，因为忘记续期证书是低级但常见的线上事故。若团队已有 Nginx 经验，也可以继续用 Nginx；重点不是换工具，而是把外部入口统一收口。

容器管理建议从 Docker Compose 起步。Compose 的价值在于把服务、网络、卷和环境变量集中到一个配置文件，并能用一组命令启动、停止、查看日志和重建。小团队不需要为了“生产级”强行上 Kubernetes。Kubernetes 很强，但它引入集群、Ingress、持久卷、控制面、权限和运维复杂度。单机早期最需要的是少出错、好恢复、易理解。

数据库建议优先用 Postgres。原因不是它时髦，而是它稳、生态成熟、备份工具多、事务可靠、权限和索引能力足够。AI 应用里大量状态是关系型的：用户、团队、文件、任务、运行记录、模型配置、知识库版本、人工反馈。把这些放进一个可靠数据库，比散落在多个 JSON 文件里更安全。

对象存储可以早期用本地卷，稍复杂后使用 MinIO 或云端 S3。MinIO 官方资料把它定位为高性能、S3 兼容、可自托管的对象存储。对象存储适合保存非结构化文件：原始文档、图片、音频、导出报告、临时产物。它和数据库的关系很清楚：数据库保存元数据和权限，对象存储保存文件本体。

向量检索可以在 pgvector 和 Qdrant 之间选择。pgvector 的 README 明确支持在 Postgres 中做向量相似度搜索，包括精确和近似最近邻，并能把向量和关系数据放在一起。数据量不大、过滤条件多、团队想减少组件时，pgvector 很适合。Qdrant 则是专门向量数据库，提供 collection、payload、过滤、快照等能力。检索规模扩大、向量负载独立、需要更专门的向量能力时，Qdrant 更合适。

四、模型网关是小团队的成本闸门

小团队最容易低估模型网关。刚开始一个应用直接调用一个模型服务，看起来很简单。过一段时间后，团队会接入多个模型供应商、多个本地模型、多个业务应用、多个用户和多个环境。没有网关，密钥散落在配置里，调用日志分散，预算无法拆分，模型替换成本高，失败重试各写各的。

模型网关要解决五件事。第一是统一接口，让应用尽量用同一种调用方式接不同模型。第二是密钥隔离，前端和业务应用不要直接持有供应商主密钥。第三是路由和降级，某个模型失败时可以切到备用模型，简单任务可以走低成本模型。第四是预算和限流，不同用户、项目和功能有不同额度。第五是日志和成本统计，知道每次调用花了多少、用了哪个模型、耗时多少、失败原因是什么。

LiteLLM Proxy 的官方文档强调代理、虚拟密钥、预算和花费管理，这类能力正好对应小团队痛点。它不是唯一选择，也可以自研一个很薄的模型网关，但“网关”这个角色不应缺席。只要有多个应用或多种模型，就应该把调用集中起来。

本地模型服务可以从 Ollama 起步。Ollama 官方 API 文档说明本地 API 默认在 http://localhost:11434/api 提供模型交互能力，并有 Python 和 JavaScript 官方库。Ollama 的优势是简单，适合个人和小团队快速跑本地模型、做隐私敏感任务、做低成本摘要和分类。它不适合作为所有高并发生产推理的唯一答案。

如果需要更高吞吐和 OpenAI 兼容服务，可以考虑 vLLM。vLLM 官方文档提供 OpenAI-Compatible Server，用于服务化模型推理。它比 Ollama 更偏推理服务和吞吐优化，适合有 GPU、要承载较多请求、需要服务化参数控制的场景。代价是配置和运维更复杂。

模型网关还要配合任务分类。不要让所有请求都走最强模型。标题生成、语言润色、简单分类、字段抽取、摘要草稿，可以使用便宜模型或本地模型。复杂推理、长上下文、多工具任务、高风险建议，再使用强模型。小团队的成本控制，不是上线后看账单哭，而是从路由设计开始。

还有一个容易忽略的点：模型网关不是安全系统的全部。它能管密钥和调用，但不能理解所有业务权限。用户能不能访问某份文档、能不能调用某个工具、能不能看到某个客户数据，应由应用后端判断。不要把业务权限塞进模型提示词。

五、知识库不要只等于向量库

很多小团队一做 AI 基础设施，就把“知识库”理解成“向量库”。这会埋下长期问题。向量库只是检索索引，不是知识本体。真正的知识库至少包含原始文件、解析结果、分块文本、向量、元数据、权限、版本、更新时间、来源链接、删除状态和索引任务记录。

如果只有向量，没有原文，回答出错时无法追溯。如果只有原文，没有分块版本，重新索引时不知道和旧答案是否一致。如果只有分块，没有权限，用户可能查到不该看的内容。如果只有最新文件，没有历史版本，旧报告引用的依据会消失。AI 知识库要能回答三类问题：这段答案依据哪份资料，资料当时是什么版本，当前用户是否有权看到。

Postgres 加 pgvector 的优势是把这些问题放在一个数据库里处理。文档表、文件表、分块表、embedding 表、权限表、索引任务表可以建立清晰关系。对小团队来说，这种一体化降低运维负担。缺点是向量规模上来后，数据库压力会变大，检索调优也需要经验。

Qdrant 的优势是向量检索专用。它的 collection 和 payload 模式适合把向量与元数据一起存储，官方文档也提供 snapshots，用于归档、复制部署和恢复。对于需要独立扩展向量检索、或希望把向量负载从主数据库拆出去的团队，Qdrant 是合理选择。无论用哪种，原始文件和业务元数据仍然不能丢。

分块策略要按内容类型设计。制度文档、合同、FAQ、表格、代码、会议记录的结构不同。统一按固定字数切分，能快速起步，但容易切断条款、表格上下文和标题层级。小团队可以先用简单规则，但要保存分块版本和解析器版本。否则每次改切分算法，都不知道历史答案为何变化。

知识库还要有重建能力。向量索引不是不可替代资产，原文和元数据才是。备份时至少要覆盖原始文件、数据库元数据、索引配置和模型版本。最理想状态是：即使向量库坏了，也能根据原文和元数据重新构建索引。这样团队不会被某个向量库的内部状态绑死。

六、对象存储和文件路径要早一点规范

AI 应用会产生大量文件：用户上传的 PDF、Excel、Word、图片、音频，系统生成的报告、截图、解析文本、中间 JSON、向量化批次、导出包。早期随手放在某个目录很方便，但几周后就会出现文件找不到、权限不清、重复占空间、备份遗漏和容器重建丢失。

文件系统设计要遵循三个原则。第一，文件本体和元数据分离。数据库记录文件属于谁、用途是什么、来源是什么、状态是什么、哈希是什么、存储路径是什么；对象存储或本地卷保存文件。第二，路径可迁移。不要把绝对路径写死到业务结果里，保存逻辑路径或对象 key。第三，原始文件不可轻易覆盖。解析结果可以重建，原始上传文件要保留版本。

MinIO 或 S3 兼容存储的价值在于形成统一对象接口。很多工具、备份系统和应用都能和 S3 API 配合。即使早期不部署 MinIO，也要按对象存储思路管理文件：bucket、key、metadata、content hash、权限和生命周期。这样以后从本地磁盘迁移到 MinIO 或云对象存储时，不需要重写业务逻辑。

小团队还要注意磁盘容量。文档解析和向量化往往会产生多份副本：原文件一份，解析文本一份，切块一份，embedding 一份，日志一份，导出一份。再加上容器镜像、数据库 WAL、对象存储版本、备份缓存，磁盘增长会很快。基础监控里必须有磁盘使用率和增长速度。磁盘满不是小问题，它会让数据库、对象存储和日志系统一起异常。

文件删除也要谨慎。用户点击删除时，业务上可能需要立即不可见，但底层可以先软删除，再由后台任务清理对象。这样既能支持误删恢复，也能避免索引和文件不同步。涉及隐私或合规要求时，必须定义硬删除和备份保留策略，不能模糊处理。

七、反向代理和访问控制要收口

一台机器上跑多个服务时，最糟糕的做法是把每个服务都直接暴露到公网：应用后端一个端口，向量库一个端口，数据库管理一个端口，对象存储一个端口，监控一个端口，模型服务一个端口。这样短期方便，长期危险。公网入口应该尽量收口到反向代理，内部服务只在内网或 Docker network 中通信。

Caddy 的自动 HTTPS 能降低证书维护成本。Nginx 和 Traefik 也都成熟。无论选哪一个，入口层要做四件事：域名到服务的路由，HTTPS，基础安全头和请求体大小限制，必要的认证或转发认证。AI 应用特别容易处理大文件和长请求，入口层要设置上传大小、超时和流式响应策略，否则用户上传文档或等待生成时会出现奇怪中断。

管理端口尽量不要公网开放。数据库、Redis、向量库管理 API、模型服务、Prometheus、Loki、Grafana、对象存储控制台，都应该只允许内网访问或通过 VPN/零信任网络访问。Tailscale 文档中的 tailnet 和 ACL 思路，NetBird 自托管文档中的私有网络思路，都说明了一个方向：管理面应该走受控私网，而不是给每个后台服务加一个公开域名。

如果必须对外暴露管理页面，也要加单点登录、强密码、多因素认证、IP 限制和最小权限。小团队经常把“内部系统”暴露在公网但无人知晓，直到被扫描器发现。AI 基础设施里还保存模型密钥、用户文件和知识库，暴露风险更高。

访问控制还包括服务间权限。应用后端可以访问数据库，模型服务不应该直接访问对象存储所有文件；向量化任务可以读取待索引文件，不应该拥有删除用户数据权限；模型网关可以调用外部模型，不应该读取用户业务表。容器网络、服务账号、API key 和数据库账号都要按角色分开。小团队不需要复杂到企业 IAM，但不能所有服务共用一个万能密钥。

八、可观测性从最低可用做起

AI 应用可观测性不要一开始就追求大而全，但必须覆盖三件事：请求是否成功，慢在哪里，模型调用发生了什么。传统 Web 系统看 HTTP 状态码、延迟和错误日志；AI 系统还要看模型、token、成本、检索命中、工具调用、重试和人工接管。

Prometheus 官方文档把它描述为监控和告警系统，会从目标 HTTP 端点抓取指标并存成时间序列。对小团队来说，最基本的指标包括服务存活、请求量、错误率、延迟、队列长度、数据库连接数、磁盘使用率、CPU、内存、GPU 显存、模型调用次数和费用估算。指标用于发现“现在是否异常”和“趋势是否危险”。

日志用于解释具体发生了什么。Grafana Loki 文档把 Loki 定位为日志聚合系统，并用 LogQL 查询日志。小团队可以从容器日志收集开始，不必一开始就做复杂日志平台。但日志格式要尽量结构化，至少包含请求 ID、用户或团队标识、任务 ID、模型名、工具名、错误码和耗时。不要在日志里写明文密钥和敏感文档内容。

Trace 用于串起一次请求的完整路径。OpenTelemetry 官方文档说明它是生成、导出、收集 trace、metrics、logs 的可观测框架和工具集，本身不是后端。AI 工作流尤其需要 trace，因为一次用户请求可能经过入口、后端、文件解析、向量检索、模型网关、外部模型、工具调用和数据库写入。没有 trace，只看单个日志片段很难知道卡在哪里。

小团队可以分阶段做可观测。第一阶段，统一请求 ID，把应用日志、模型调用日志和任务日志串起来。第二阶段，加基础指标和告警，至少知道服务挂了、磁盘满了、错误率高了、模型费用异常了。第三阶段，引入 OpenTelemetry 或类似 trace，把关键链路可视化。不要等系统复杂后再补，因为那时每个服务的日志格式已经不一致。

可观测性还有一个 AI 特有指标：质量反馈。模型回答是否被用户采纳，知识库引用是否有效，人工修改了哪些内容，失败样本属于哪类。这些不一定放进 Prometheus，但应该进入业务数据库或评测集。AI 基础设施最终不是为了服务在线，而是为了结果可靠。

九、备份是单机架构的生命线

单机可以接受，前提是备份认真。备份至少覆盖五类数据：Postgres 数据库，对象存储或上传文件，向量库快照，配置和密钥的可恢复版本，应用关键版本信息。少备任何一类，恢复时都会断链。数据库恢复了但文件没了，知识库不可用；文件恢复了但数据库元数据没了，权限和来源丢失；向量库恢复了但原文没了，无法校验；配置没了，服务起不来。

restic 官方资料强调它可以把文件备份到多种存储，支持加密、增量传输和可验证恢复。对小团队来说，restic 或同类工具的价值在于简单、可脚本化、支持异地备份。备份不要只放在同一块硬盘上。机器硬盘坏了，同盘备份也一起没了。最低要求是本机快照加异地备份，最好再有定期恢复演练。

Postgres 要做逻辑备份或物理备份，至少要能恢复到最近可接受时间点。对象存储要备份原始文件和元数据。Qdrant 官方文档中的 snapshots 可以用于归档或复制部署，但分布式场景还要按节点处理；单机 Qdrant 也要把 snapshot 纳入备份流程。pgvector 如果在 Postgres 中，则跟随 Postgres 备份。

备份不是“命令成功”就结束。必须做恢复演练。恢复演练可以每周或每月在另一目录、另一台机器或临时环境中进行：恢复数据库，恢复文件，启动服务，抽查一个知识库，打开一个用户文件，跑一次检索，确认应用能读到数据。没有演练的备份只是心理安慰。

密钥备份要格外小心。模型供应商密钥、数据库密码、对象存储密钥、JWT 密钥、加密盐、备份仓库密码，这些丢了会导致服务无法恢复，泄漏则会造成安全事故。不要把明文密钥直接放进公开仓库。小团队可以使用密码管理器、密钥文件加密存储、操作系统密钥库或专门 secret 管理工具。关键是知道“谁有权访问，哪里有副本，如何轮换”。

备份策略也要有保留周期。每天备份、保留 7 天；每周备份、保留 4 周；每月备份、保留若干个月。具体周期取决于数据价值和成本。AI 应用中，用户误删文件、错误索引、模型批处理写坏数据，都可能需要回到过去某个版本。只保留最近一次备份，不足以应对逻辑错误。

十、运维最少，不是没有运维

最少运维的含义是减少无意义复杂度，而不是没人负责。小团队需要一套轻量运行手册，写清楚常见动作：如何启动，如何停止，如何更新，如何看日志，如何查错误，如何扩磁盘，如何恢复备份，如何轮换密钥，如何关闭某个模型，如何限制某个用户调用。

更新策略要保守。AI 基础设施里的组件很多：模型网关、应用、数据库、向量库、对象存储、反向代理、监控、备份工具。本地开发时可以频繁升级，生产机器不要随手拉 latest。镜像版本要固定，升级前看变更，升级后跑冒烟测试。数据库和向量库升级尤其要准备回滚或恢复方案。

配置要版本化，但密钥不要明文版本化。Compose 文件、Caddyfile、应用配置模板、监控规则、备份脚本，都应该放在私有仓库或受控目录里。环境变量中的敏感值单独管理。这样换机器时，团队知道要恢复哪些配置，而不是靠某个人终端历史。

服务要有健康检查。Docker Compose 支持服务状态管理，但应用自身也要有健康接口。健康检查不应该只返回“进程还在”，还要至少检查关键依赖是否可用，例如数据库连接、对象存储连接、模型网关状态。对于用户请求链路，最好有一个合成检查：调用一个低成本模型、读取一条测试知识、完成一次简单检索。

队列和后台任务要有限制。AI 应用很容易被批量任务拖垮：一次上传一千个文件，一次重建全部向量，一次批量生成报告。后台任务应该有并发上限、重试上限、失败队列和暂停开关。没有这些开关，系统出问题时只能停全站。

成本也要运维化。每天模型调用量、费用、失败率、平均延迟、最贵用户、最贵功能，都应该能看到。小团队常见事故不是技术崩溃，而是某个循环任务把模型 API 费用刷爆。预算告警和调用限额要早做。

十一、一个推荐起步方案

一个务实的一机起步方案可以这样搭。入口层使用 Caddy，负责 HTTPS 和反向代理。容器编排使用 Docker Compose，所有服务加入内部网络，只暴露 Caddy 的 80 和 443，以及必要的私网管理入口。应用后端使用团队熟悉的栈，比如 FastAPI、NestJS、Rails、Django 或 Go。数据库使用 Postgres。向量检索早期用 pgvector，数据量变大或检索压力独立后再拆到 Qdrant。对象存储早期用本地持久卷，稍后迁移到 MinIO 或云 S3。

模型层使用一个统一网关。外部模型通过 LiteLLM Proxy 或自研薄网关接入，本地轻量模型通过 Ollama，GPU 服务化需求再引入 vLLM。应用不直接持有供应商主密钥，不直接决定所有模型路由。后台任务用 Redis Queue、Celery、BullMQ、Sidekiq 或团队熟悉的队列，不要让用户请求同步完成所有解析和索引。

观测层从三件事开始：应用结构化日志，Prometheus 基础指标，Grafana 面板。日志先保留在本机或 Loki 中，指标覆盖服务、机器、磁盘、数据库和模型调用。Trace 可以在关键链路稳定后引入 OpenTelemetry。不要为了观测工具本身耗尽精力，但也不要没有请求 ID 和模型调用记录。

安全层使用三个入口。公开入口只给用户应用。团队管理入口走 Tailscale、NetBird 或等价私网。数据库、向量库、对象存储控制台、Prometheus、Loki、模型服务都不直接公网开放。所有外部 API key 只放在服务端，前端拿短期会话或业务 token。

备份层使用数据库备份、文件备份和异地同步。Postgres 每日备份，文件和对象存储每日增量，Qdrant 或其他向量库定期 snapshot。restic 用于加密增量备份到外部磁盘、另一台机器或云存储。每月至少做一次恢复演练，确认不只是文件存在，而是应用能用。

这个方案不花哨，但能支撑很多早期 AI 产品。它的核心是少而清楚：一个入口，一个编排方式，一个数据库，一个模型网关，一个文件系统，一个备份链路，一套最小观测。等业务增长后，再把最拥挤的角色拆出去，而不是一开始就把所有复杂度买回来。

十二、容量规划：先管住最容易失控的三件事

小团队做容量规划，不需要一开始就做复杂压测报告，但必须管住三件事：磁盘、模型调用和后台任务。磁盘最容易被忽视，因为早期数据不多，大家以为硬盘很大。AI 应用上线后，上传文件、解析文本、向量索引、日志、备份和导出结果会一起增长。磁盘一旦满，数据库写入、对象存储、日志系统和模型缓存都可能同时出问题。最低要求是给数据卷、日志卷和备份目录分别看使用率，并设置提前告警。

模型调用是第二个失控点。一个用户请求可能触发多次模型调用：分类一次、检索改写一次、重排一次、生成一次、校验一次。如果后台批量任务也用同样链路，费用会快速增长。容量规划要看“每个业务动作平均调用几次模型”，而不是只看“每个用户发了几句话”。模型网关记录每个功能、用户和任务的调用成本后，团队才能决定哪些环节要缓存，哪些环节换便宜模型，哪些环节必须限流。

后台任务是第三个失控点。文档解析、批量 embedding、批量总结、视频转写、图片理解都很耗资源。如果这些任务和在线请求抢 CPU、内存、GPU 或数据库连接，用户会感觉整个系统变慢。小团队应把后台任务放进队列，设置并发上限，区分高优先级和低优先级。在线请求需要优先，批量索引可以慢一点。系统要有暂停按钮，出现异常费用或资源压力时能立即停掉批处理。

容量规划还要关注上下文长度。长文档问答、长聊天记录总结、多文件分析都会推高 token 和延迟。不要让用户一次上传大量文件后同步等待全部处理。更好的方式是先接收任务，后台解析和索引，完成后通知用户。这样用户体验更稳定，系统也能控制并发。

GPU 机器要单独规划。显存比 CPU 更刚性，一个模型加载后会占用固定空间，并发请求还会增加 KV cache 压力。不要在同一张显卡上同时承诺多个大模型高并发。小团队可以把本地模型定位为隐私和低成本补充，把高峰复杂推理交给外部 API，等调用量稳定后再评估是否增加 GPU。

容量规划的输出不需要很厚，只要回答几个数字：磁盘按当前速度多久满，每天模型费用上限是多少，后台任务最大并发是多少，单个用户最多能上传多少文件，单个任务最长允许运行多久，服务异常时先停哪个任务。这些数字比抽象架构图更能保护系统。

十三、恢复演练：把“能备份”变成“能回来”

恢复演练要按用户路径验证，而不是只验证命令。一次完整演练可以这样做：在临时目录或备用机器上恢复数据库，恢复对象文件，恢复配置，启动服务，登录测试账号，打开一份历史上传文档，运行一次知识库检索，调用一次模型网关，生成一份报告，确认引用能指回原文。只有用户路径通了，才说明备份真正可用。

演练还要记录恢复时间。小团队不必追求分钟级恢复，但要知道真实数字。如果从空机器到可用需要六小时，就要向业务接受这个现实，并决定是否值得投入更多自动化。没有演练时，团队会高估恢复能力；真正出事时才发现缺少密钥、镜像版本不对、数据库扩展没装、对象路径变了。

恢复演练应覆盖两类事故。一类是机器损坏：需要在新机器上恢复全部服务。另一类是逻辑错误：某次批处理写坏数据，某个用户误删知识库，某次升级导致索引不一致。机器损坏靠最近备份恢复，逻辑错误可能需要恢复到过去某个时间点，并把部分数据合并回当前系统。只保留最近一次备份，无法处理逻辑错误。

演练后要修正文档。恢复过程中每遇到一步人工猜测，都说明文档或配置不够清楚。比如缺少环境变量说明，缺少初始化命令，缺少数据库扩展安装，缺少对象存储 bucket 创建，缺少 Caddy 域名配置。把这些补进运行手册，下次恢复才会更快。

恢复演练还会倒逼服务边界清晰。如果某个应用把文件路径写死在数据库里，迁到新机器后就会断。如果某个服务启动依赖手工创建目录，恢复时就容易漏。如果某个密钥只存在某个人本地，团队就无法独立恢复。演练暴露的问题，往往比平时运行中看到的更接近真实风险。

小团队可以把恢复演练做轻量化。每月做一次完整演练，每周做一次抽样恢复，每天检查备份任务和仓库可读性。演练不是形式，它是单机架构敢于上线的底气。

十四、什么时候该从单机迁出

单机不是信仰。出现以下信号时，就应该拆分。第一，数据库、向量检索和模型推理互相争抢资源，影响用户请求。第二，磁盘增长速度超过备份和恢复能力。第三，业务要求更短恢复时间，不能接受单机故障导致长时间不可用。第四，团队有多个应用共用基础设施，需要更清晰的多租户隔离。第五，模型推理负载需要多 GPU 或独立扩缩容。第六，安全或合规要求不允许所有数据集中在一台机器。

迁出顺序不要随意。通常先拆对象存储，因为文件增长快，迁移到 S3 兼容存储较自然。然后拆模型推理，把 GPU 服务独立出来。再拆向量库，让检索负载不影响主数据库。最后考虑数据库高可用和容器平台。不要一上来先拆 Kubernetes，因为 Kubernetes 解决的是编排规模问题，不会自动解决数据模型、备份、权限和成本。

迁出时要保持接口稳定。应用通过模型网关调用模型，就可以把 Ollama 换成 vLLM 或外部模型；应用通过对象存储接口读文件，就可以把本地卷换成 MinIO 或云 S3；应用通过检索服务读知识，就可以把 pgvector 换成 Qdrant。早期基础设施的好坏，常常体现在迁移时是否痛苦。

还要避免“拆出去就安全”的错觉。服务拆成多台机器后，网络、密钥、备份和监控更复杂。如果单机时代没有状态和备份纪律，多机只会扩大问题。迁出之前，先把数据边界、调用边界和恢复边界理清楚。

十五、常见误区

第一个误区是把 Kubernetes 当生产级通行证。Kubernetes 能管理复杂容器集群，但不会自动让 AI 应用可靠。小团队没有足够运维能力时，Kubernetes 可能把简单问题变成集群问题。

第二个误区是把本地模型等同于低成本。机器、电费、显卡、维护、吞吐、延迟、模型质量都要算成本。本地模型适合隐私、可控和部分低成本任务，但不是所有任务的最佳选择。

第三个误区是把向量库当知识库。向量只是索引，原文、权限、版本、来源和分块策略才构成知识资产。只备份向量不备份原文，是危险设计。

第四个误区是所有服务都暴露公网。为了方便管理而开放数据库、监控、对象存储和模型服务，会给系统带来不必要风险。管理入口应该走受控私网或强认证。

第五个误区是没有恢复演练。备份文件存在不代表能恢复。恢复需要数据库、文件、配置、密钥、服务版本和索引一起对齐。

第六个误区是让每个应用自己接模型。这样会导致密钥分散、费用不可控、质量不可比较、降级困难。模型网关应该尽早建立。

第七个误区是把日志当垃圾。AI 系统的失败原因复杂，缺少日志和 trace 时，团队只能凭感觉改提示词。可观测性不是大团队专属，而是小团队节省时间的工具。

第八个误区是追求一次到位。基础设施应该随业务增长演进。先把单机场景做扎实，再按瓶颈拆分，比一开始建设一套无人能维护的平台更可靠。

十六、检查清单

• 是否只有一个统一公网入口，内部服务是否默认不暴露公网？
• 是否使用 Docker Compose 或等价方式管理服务、网络、卷和配置？
• 是否有统一模型网关，能记录调用、成本、模型、用户和错误？
• 是否区分原始文件、解析文本、分块、向量、权限和知识库版本？
• 是否有数据库备份、文件备份、向量库快照和配置恢复方案？
• 是否做过恢复演练，而不只是看到备份任务成功？
• 是否能看到服务存活、错误率、延迟、磁盘、内存、CPU、GPU 和模型费用？
• 是否有请求 ID 或任务 ID 串起用户请求、后台任务、模型调用和工具调用？
• 是否限制后台任务并发，避免批处理拖垮在线请求？
• 是否有密钥轮换、权限隔离和管理入口私网访问？
• 是否知道单机架构的恢复时间和不可用风险，并向业务方说明？
• 是否定义了从单机迁出的触发条件和迁移顺序？

十七、结论

小团队 AI 基础设施的目标不是堆组件，而是用最少运维换到真实可靠。可靠不是永不宕机，而是入口清楚、状态清楚、文件清楚、模型调用清楚、错误清楚、备份清楚、恢复清楚。一台机器可以是严肃生产起点，只要团队承认它的边界，并把可恢复和可观测放在第一天。

最推荐的路径是：Caddy 或同类入口代理，Docker Compose 管服务，Postgres 管核心状态，pgvector 或 Qdrant 管检索，MinIO 或对象存储思路管文件，LiteLLM 或薄网关管模型，Ollama 或 vLLM 管本地推理，Prometheus、Loki、OpenTelemetry 逐步补齐观测，restic 或同类工具做异地备份。组件不必一次到位，但角色要完整。

小团队真正稀缺的不是机器，而是注意力。每增加一个服务，都要有人理解、更新、备份和排错。把基础设施做小、做清楚、做可恢复，团队才能把精力放回产品和用户，而不是天天救火。

参考资料与延伸阅读

• Docker Docs：Docker Compose https://docs.docker.com/compose
• Docker Docs：How Compose works https://docs.docker.com/compose/intro/compose-application-model/
• Caddy Documentation：Automatic HTTPS https://caddyserver.com/docs/automatic-https
• LiteLLM Docs：Getting Started / Proxy https://docs.litellm.ai/
• Ollama Docs：API Introduction https://docs.ollama.com/api/introduction
• vLLM Docs：OpenAI-Compatible Server https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
• pgvector README：Open-source vector similarity search for Postgres https://github.com/pgvector/pgvector
• Qdrant Documentation：Snapshots https://qdrant.tech/documentation/operations/snapshots/
• MinIO：Object Storage Overview https://min.io/product/overview
• Prometheus Docs：Getting started https://prometheus.io/docs/prometheus/latest/getting_started/
• Grafana Loki Documentation https://grafana.com/docs/loki/latest/
• OpenTelemetry Docs：What is OpenTelemetry? https://opentelemetry.io/docs/what-is-opentelemetry/
• restic：Backups done right https://restic.net/
• Tailscale Docs：ACL syntax https://tailscale.com/kb/1337/acl-syntax/
• NetBird Docs：Self-Hosting Quickstart Guide https://docs.netbird.io/selfhosted/selfhosted-quickstart

写作日期：2026-05-22