Windows Server+Caddy+FastAPI+llama.cpp+Qwen实现AI聊天机器人技术架构（2）摘要：从个人自用升级为公共服务架构的AI聊天机器人技术方案。架构采用分层设计：前端Android App通过HTTPS访问API网关（Caddy/Nginx），后端由无状态FastAPI服务、推理调度层和Worker池（llama.cpp/vLLM）组成，支持水平扩展。关键改进包括：1) 从单用户限制改为可配置的并发控制；2) 采用流式响应和有限队列保护系统；3) 抽象推理层接口便于后续切换GPU方案；4) 增加监控告警体系。初期可在4GB内存Windows服务器部署llama.cpp运行Qwen小模型，随用户增长可逐步升级为多节点CPU/GPU集群，通过负载均衡、Redis队列和数据库支撑规模化服务。架构特别强调无会话状态设计，避免上下文依赖以提升扩展性，同时保持必要的限流和安全防护措施。这次的架构设计 （1）“个人自用小服务”不是一个级别了。现在的项目定位变成：Android App 对外发布，用户数量不确定；早期用 4GB 内存、2 核 CPU 的 VPS 起步，后续用户增长后可以扩容。服务端要设计成可演进、可扩展的公共聊天机器人后端，而不是写死单用户使用。所以这次架构设计的重点应该从：单机低配能跑起来升级为：单机可启动，后续可平滑扩容为多实例、多推理节点、可观测、可限流、可运营的公共服务架构一、先给总体结论推荐采用：Android App ↓ HTTPS ↓ Caddy / API Gateway / 负载均衡 ↓ FastAPI API 服务层，无状态 ↓ 推理调度层 / Inference Router ↓ llama.cpp / vLLM / 推理 Worker 池 ↓ Qwen 小模型 / 后续更大模型核心原则是：FastAPI 层保持无状态，聊天不保留上下文，推理服务独立出来，后续通过增加 API 实例和推理 Worker 实例实现横向扩容。早期可以单机部署：Caddy + FastAPI + llama.cpp + Qwen后期可以演进为：CDN/WAF + 负载均衡 + 多个 FastAPI 实例 + 多个推理节点 + Redis + 数据库 + 监控系统二、重新设计后的总体架构1. 公共服务版总体架构Android App ↓ HTTPS REST / Streaming API ↓ CDN / WAF，可选 ↓ Caddy / Nginx / 云负载均衡 ↓ FastAPI API Service，多个实例 ↓ Inference Router / 推理调度层 ↓ Inference Worker Pool ├── llama.cpp Worker 1 ├── llama.cpp Worker 2 ├── llama.cpp Worker 3 └── 后续 GPU Worker / vLLM Worker ↓ Qwen GGUF / Qwen 模型辅助组件：Redis：限流、队列、任务状态、临时缓存 Database：用户、设备、套餐、调用统计，不存聊天上下文 Object Storage：日志归档、模型文件，可选 Monitoring：Prometheus / Grafana / 日志系统 Admin：后台管理，可选三、和之前单用户方案最大的区别之前单用户方案强调：只能一个请求推理 其他请求等待或拒绝现在公共服务架构不能这么设计成固定规则。新的设计应该是：1. 不在代码里写死“只能一个用户使用” 2. 并发能力由配置决定 3. 推理能力由 Worker 数量决定 4. 用户多了就增加 Worker 5. 请求高峰时通过队列、限流、降级保护系统 6. FastAPI 本身保持无状态，便于水平扩容也就是说：不是取消所有限制，而是把限制从“写死的单用户限制”改成“可配置、可扩容、可运营的容量控制”。公共服务一定仍然需要限流和容量保护，否则被刷几分钟，服务器就可能崩掉。区别是：限流不再是“只能一个人用”，而是根据当前机器能力动态配置。四、核心架构分层推荐服务端分成 5 层。第 1 层：入口层组件：Caddy / Nginx / 云负载均衡 / API Gateway早期可以用：Caddy后期用户多了，可以升级为：云负载均衡 SLB / ALB + Caddy / Nginx + CDN / WAF入口层负责：1. HTTPS 2. 域名访问 3. TLS 证书 4. 反向代理 5. 请求体大小限制 6. WAF 防护，可选 7. 基础访问日志 8. 转发流式响应不负责：不做模型推理 不保存聊天记录 不做复杂业务第 2 层：API 服务层组件：FastAPIAPI 层负责： Windows Server+Caddy+FastAPI+llama.cpp+Qwen实现AI聊天机器人技术架构（2）
Windows Server+Caddy+FastAPI+llama.cpp+Qwen实现AI聊天机器人技术架构（2）摘要：从个人自用升级为公共服务架构的AI聊天机器人技术方案。架构采用分层设计：前端Android App通过HTTPS访问API网关（Caddy/Nginx），后端由无状态FastAPI服务、推理调度层和Worker池（llama.cpp/vLLM）组成，支持水平扩展。关键改进包括：1) 从单用户限制改为可配置的并发控制；2) 采用流式响应和有限队列保护系统；3) 抽象推理层接口便于后续切换GPU方案；4) 增加监控告警体系。初期可在4GB内存Windows服务器部署llama.cpp运行Qwen小模型，随用户增长可逐步升级为多节点CPU/GPU集群，通过负载均衡、Redis队列和数据库支撑规模化服务。架构特别强调无会话状态设计，避免上下文依赖以提升扩展性，同时保持必要的限流和安全防护措施。这次的架构设计 （1）“个人自用小服务”不是一个级别了。现在的项目定位变成：Android App 对外发布，用户数量不确定；早期用 4GB 内存、2 核 CPU 的 VPS 起步，后续用户增长后可以扩容。服务端要设计成可演进、可扩展的公共聊天机器人后端，而不是写死单用户使用。所以这次架构设计的重点应该从：单机低配能跑起来升级为：单机可启动，后续可平滑扩容为多实例、多推理节点、可观测、可限流、可运营的公共服务架构一、先给总体结论推荐采用：Android App ↓ HTTPS ↓ Caddy / API Gateway / 负载均衡 ↓ FastAPI API 服务层，无状态 ↓ 推理调度层 / Inference Router ↓ llama.cpp / vLLM / 推理 Worker 池 ↓ Qwen 小模型 / 后续更大模型核心原则是：FastAPI 层保持无状态，聊天不保留上下文，推理服务独立出来，后续通过增加 API 实例和推理 Worker 实例实现横向扩容。早期可以单机部署：Caddy + FastAPI + llama.cpp + Qwen后期可以演进为：CDN/WAF + 负载均衡 + 多个 FastAPI 实例 + 多个推理节点 + Redis + 数据库 + 监控系统二、重新设计后的总体架构1. 公共服务版总体架构Android App ↓ HTTPS REST / Streaming API ↓ CDN / WAF，可选 ↓ Caddy / Nginx / 云负载均衡 ↓ FastAPI API Service，多个实例 ↓ Inference Router / 推理调度层 ↓ Inference Worker Pool ├── llama.cpp Worker 1 ├── llama.cpp Worker 2 ├── llama.cpp Worker 3 └── 后续 GPU Worker / vLLM Worker ↓ Qwen GGUF / Qwen 模型辅助组件：Redis：限流、队列、任务状态、临时缓存 Database：用户、设备、套餐、调用统计，不存聊天上下文 Object Storage：日志归档、模型文件，可选 Monitoring：Prometheus / Grafana / 日志系统 Admin：后台管理，可选三、和之前单用户方案最大的区别之前单用户方案强调：只能一个请求推理 其他请求等待或拒绝现在公共服务架构不能这么设计成固定规则。新的设计应该是：1. 不在代码里写死“只能一个用户使用” 2. 并发能力由配置决定 3. 推理能力由 Worker 数量决定 4. 用户多了就增加 Worker 5. 请求高峰时通过队列、限流、降级保护系统 6. FastAPI 本身保持无状态，便于水平扩容也就是说：不是取消所有限制，而是把限制从“写死的单用户限制”改成“可配置、可扩容、可运营的容量控制”。公共服务一定仍然需要限流和容量保护，否则被刷几分钟，服务器就可能崩掉。区别是：限流不再是“只能一个人用”，而是根据当前机器能力动态配置。四、核心架构分层推荐服务端分成 5 层。第 1 层：入口层组件：Caddy / Nginx / 云负载均衡 / API Gateway早期可以用：Caddy后期用户多了，可以升级为：云负载均衡 SLB / ALB + Caddy / Nginx + CDN / WAF入口层负责：1. HTTPS 2. 域名访问 3. TLS 证书 4. 反向代理 5. 请求体大小限制 6. WAF 防护，可选 7. 基础访问日志 8. 转发流式响应不负责：不做模型推理 不保存聊天记录 不做复杂业务第 2 层：API 服务层组件：FastAPIAPI 层负责：