私有化架构的核心不是组件名称，而是边界可解释：谁能访问入口、认证在哪里发生、文件落到哪里、哪个服务调用模型、算力如何分配、日志和备份由谁管理。只有把这些路径画清楚，才能检查数据是否真的不出域，并为容量、故障和审计制定方案。
六个逻辑层
| 层 | 主要组件 | 职责 |
|---|---|---|
| 访问层 | 用户浏览器、内网 DNS、TLS 入口 | 提供 Web 访问，执行网络准入与证书终结；终端不直接连接数据库或模型 |
| 网关与身份层 | API 网关、账号与组织服务 | 认证请求、传递用户上下文、执行 API 路由与账号组织管理 |
| 业务与处理层 | 知识、文档、文档解析、音频等微服务 | 处理上传、元数据、解析任务、检索、问答、写作、审核和会议 |
| 算力编排层 | 私有异构算力调度平台、容器集群、镜像与实例管理 | 统一管理节点、加速卡、资源池、镜像、实例、存储和访问入口 |
| 模型层 | vLLM 路由及本地模型服务 | 为大模型、视觉、向量、精排和语音链路提供内网推理能力 |
| 数据层 | MySQL、MinIO | 保存账号与业务结构数据，以及文档、音频、附件、镜像元数据和处理产物 |
实际部署需要结合服务器与加速卡型号、驱动和框架版本、资源池划分、访问方式及存储条件确认具体组件和容量。
平台模型与用户实例采用不同边界
平台模型池
承载知识问答、文稿、审核和会议等产品能力所需的模型服务。平台统一管理版本、路由与健康状态，通过受控接口供业务能力调用。
用户自助实例
面向授权用户或团队的开发、推理与实验工作负载。实例在隔离的运行空间中启动，通过网关或受控端口访问，不自动加入平台模型路由。
两类负载可以共享底层节点与加速卡资产，但资源池、镜像来源、网络入口、存储目录和权限策略需要分别治理，避免用户实例影响平台核心服务。
一份文档的典型数据流
- 用户通过浏览器和 TLS 入口登录，API 网关验证身份后把上传请求转给业务服务。
- 文档原文件写入 MinIO，文档元数据与处理状态写入 MySQL；业务服务派发解析任务。
- 解析服务从对象存储读取文件，按类型执行文本、Office、PDF 或 VLM-OCR 处理，并写回结构化结果与产物。
- 完成的内容进入索引和检索范围；用户提问时，知识服务在授权范围内召回材料并通过内网模型服务组织回答。
- 回答携带引用信息，用户可回看原文；操作与保留信息按照部署和审计策略管理。
持久化与无状态边界
业务微服务本身不依赖各自的本地数据盘，持久数据集中写入 MySQL 和 MinIO。这有利于重建应用 Pod，但不意味着系统天然高可用：如果数据库、对象存储或其底层磁盘仍是单点，应用副本增加也无法避免数据层中断。生产方案需要根据可用性目标设计数据库与对象存储冗余、磁盘故障域、备份和恢复。
K3s 中声明的存储容量不一定等于物理硬配额。磁盘扩容、监控告警和容量隔离要结合实际存储实现确认。
网络与安全设计清单
入口边界
确定内外网入口、TLS、域名、反向代理、访问控制与上传大小 / 超时策略；模型和数据服务不直接暴露给终端。
服务边界
限制命名空间和服务间访问，保护数据库、对象存储和模型接口凭据，避免把内部管理接口暴露为公网路由。
身份与权限
建立账号、组织、知识库和管理员职责矩阵；对离职、调岗、共享账号与高权限操作建立复核流程。
恢复与升级
数据库和对象存储需要一致的备份策略；离线升级前验证包完整性、版本兼容、备份可恢复和回滚路径。
高可用不是默认标签
当前部署可按项目规模从单节点起步，也可结合既有集群设计多节点，但副本数、数据库拓扑、对象存储拓扑、GPU 服务冗余、入口负载均衡和机房故障域必须逐项确认。对关键业务，应基于恢复时间目标（RTO）与恢复点目标（RPO）做故障演练，而不是仅凭“容器化”判断系统具备高可用。