建站兼跑AI，香港服务器与香港GPU服务器如何分担Web与推理任务？

一套同时承载官网、业务系统和 AI 推理的架构，通常不应让同一台机器承担全部工作。香港服务器更适合放置网站前端、API 网关、数据库连接、订单与会话处理；香港 GPU 服务器则负责模型加载、批量推理、图像生成或向量计算。两者通过内网或经过访问控制的加密接口通信，能够把网页访问高峰与 GPU 推理高峰分开处理。

如果业务以内容展示、会员登录、表单提交为主，AI 请求量较少，可以先以香港服务器承载 Web 和轻量推理；如果需要常驻大模型、处理并发对话、文生图或较长文本生成，则更适合采用“香港服务器接入业务，香港 GPU 服务器执行推理”的组合。真正需要确认的不是两种服务器谁更快，而是请求如何流转、哪一部分会形成瓶颈、数据是否需要跨公网，以及 GPU 是持续满载还是只在特定时段使用。

围绕这类Web与AI推理分工，A5数据提供香港物理服务器与香港GPU服务器资源：香港服务器覆盖入门建站、Xeon Gold、AMD EPYC等平台，配合SSD或NVMe存储，可承载网站、后台、数据库和接口；香港GPU系列提供A100 80GB、RTX 4090等选项，并配备相应CPU、内存及NVMe存储，为模型推理、图像处理和多任务部署提供计算基础。结合CN2等线路资源，可形成业务入口与AI计算节点的独立部署。

用户路径：一次网页请求如何到达模型

从访问页面到返回结果

一个典型的 AI 建站业务，可能同时存在三类请求：

• 普通网页请求，例如首页、文章页、商品页和帮助中心；
• 业务接口请求，例如登录、搜索、订单、会员权益和文件上传；
• AI 推理请求，例如智能问答、内容改写、图片识别、摘要生成或推荐结果计算。

这三类请求的资源特征并不相同。普通网页主要消耗 CPU、内存、磁盘读取和网络带宽；业务接口还会依赖数据库、缓存和文件存储；AI 请求则可能长时间占用 GPU 显存、计算单元和模型服务进程。

较清晰的访问路径可以设计为：

访问者
  ↓
DNS / CDN（按业务需要启用）
  ↓
香港服务器
  ├─ Nginx：HTTPS、静态文件、请求转发
  ├─ Web 应用：登录、订单、权限、任务创建
  ├─ 数据库或缓存连接
  └─ AI 网关：鉴权、限流、排队、结果查询
        ↓
香港 GPU 服务器
  ├─ 模型服务
  ├─ 推理队列
  └─ 模型权重、临时文件和运行日志
        ↓
返回同步结果，或写入异步任务结果

用户打开网页时，请求先由香港服务器处理。只有当页面触发 AI 功能，Web 应用才向 GPU 服务发起推理任务。这样可以避免所有静态资源请求都经过 GPU 服务器，也不会因为某个模型正在加载而拖慢首页和登录接口。

同步推理与异步任务

短文本问答、分类、关键词提取等请求，可以采用同步方式。用户提交内容后，Web 服务器向 GPU 服务发起请求，等待模型返回结果，再把结果展示在页面上。

但同步方式需要设置明确的等待边界。例如，页面接口等待时间设置为 15 秒，而模型在第 18 秒才返回，用户体验通常已经变差。更稳妥的做法是根据业务类型分层：

异步任务不应只返回一个“处理中”的页面。建议在创建任务时生成唯一 job_id，由香港服务器记录任务状态，再通过轮询、服务端推送或消息通知返回结果。GPU 服务器只负责执行，不直接管理用户登录态和订单状态。

一个简化的任务请求可以采用类似结构：

{
  "job_id": "ai-20250101-000001",
  "model": "text-generation",
  "input_type": "text",
  "input": "请将这段产品说明改写为简洁的网页文案。",
  "max_output_tokens": 500,
  "priority": "normal",
  "callback": false
}

实际接口还需要加入用户身份、权限、请求签名、超时时间和幂等标识。涉及付费额度时，扣费或扣次数动作应由 Web 服务器完成，不能仅依赖 GPU 返回结果，否则 GPU 重试或服务中断时可能出现重复扣减。

关键约束：两台服务器为什么不能只看配置表

访问量和推理并发不是同一个指标

网站日访问量较大，并不代表 GPU 推理并发一定很高。一个内容站每天可能有数万次页面访问，但只有少量用户使用 AI；也有一些内部系统页面访问量不高，却会在固定时间集中提交大量文件。

可以用一组示例条件理解两者的区别：

• 每天普通页面访问约 5,000 次；
• 高峰期页面并发连接约 80；
• 每天产生 3,000 次 AI 请求；
• AI 请求的平均处理时间约 8 秒；
• 短时间内可能达到每秒 3 个 AI 请求。

按照排队系统的基本估算，高峰并发数约等于“到达速率 × 平均处理时间”，因此：

3 次/秒 × 8 秒 ≈ 24 个同时处理中的 AI 请求

这只是业务层面的待处理数量，不等于一块 GPU 就一定能同时完成 24 个请求。模型大小、输入长度、输出长度、量化方式、批处理策略和推理框架都会改变实际吞吐。这个估算的价值在于提醒架构设计者：不能只用每日请求量选 GPU，还要观察高峰期每秒请求数和单次处理时间。

Web 服务器和 GPU 服务器的容量关注点不同

香港服务器需要重点观察：

• CPU 核数和单核处理能力；
• 内存是否能够容纳应用、缓存和连接池；
• 系统盘和数据盘的随机读写性能；
• 并发连接数和网络端口；
• 公网带宽、流量计费方式及出方向费用；
• 数据库、对象存储和备份的连接方式；
• 是否支持弹性扩容或更换实例规格。

GPU 服务器则要重点确认：

• GPU 型号、数量和显存容量；
• 驱动、CUDA、推理框架与目标模型的兼容性；
• GPU 是独享、切分还是共享；
• 模型权重是否可以常驻显存；
• CPU 内存是否足以完成模型加载和预处理；
• 本地磁盘是否足够放置模型、缓存和临时文件；
• 多 GPU 是否支持目标框架的并行方式；
• GPU 按小时、按月还是按实际占用计费；
• 停机后资源是否释放，模型数据是否保留；
• GPU 与 Web 服务器之间是否存在可用的私有网络。

其中，GPU 显存不是越大越能直接解决所有问题。以参数规模作初步估算时，7B 参数模型使用 FP16 存储，模型权重约需要：

7 × 10^9 × 2 字节 ≈ 14GB

如果采用 4-bit 量化，权重本身约为 3.5GB，但还要为运行时缓冲区、KV Cache、框架开销和输入输出空间预留容量。因此，权重能够放入显存，不代表长上下文、高并发或批处理一定能够稳定运行。模型大小只能用于初筛，最终仍应使用目标模型和典型输入进行验证。

网络延迟只是其中一个变量

香港服务器和香港 GPU 服务器位于同一地区，并不自动意味着两者之间一定有低延迟或免费内网。采购时应确认：

• 两台机器是否在同一数据中心或同一可用区；
• 是否提供私有网络、内网地址或专用互联；
• 私有网络是否按流量收费；
• 内网带宽是否与公网带宽分开计算；
• GPU 服务是否只能通过公网地址访问；
• 是否支持安全组、访问控制列表或固定来源地址；
• 故障时是否可以更换公网 IP 或迁移实例。

如果两台服务器只能通过公网通信，GPU 服务端口不应直接对所有地址开放。可以通过固定来源 IP、TLS、请求签名和应用层鉴权限制访问范围。若服务商提供私有网络，则优先让 Web 服务器调用 GPU 的内网地址，同时保留加密和身份校验。

对于文字模型，单次请求和响应通常不会带来很大的带宽压力，但图片和视频任务会迅速改变结果。仍以示例估算：

• 每次文字请求约 2KB，返回约 20KB；
• 每天 3,000 次请求；
• 请求和响应合计约 22KB。

按十进制单位计算：

3,000 × 22KB = 66,000KB ≈ 66MB/天
66MB × 30天 ≈ 1.98GB/月

如果每次返回一张 2MB 图片，则只计算图片结果：

3,000 × 2MB = 6,000MB ≈ 6GB/天
6GB × 30天 ≈ 180GB/月

这里的 MB 和 GB 按十进制计算，实际还会增加 HTTPS、接口封装、重试和日志上传等开销。文字推理更需要关注排队和响应时间，图像生成则需要同时关注带宽、对象存储和出方向流量费用。

数据合规和数据留存也会影响分工

如果用户提交的是合同、身份证明、医疗资料、企业内部文件或其他敏感内容，不能因为 GPU 服务器与 Web 服务器在同一地区，就默认数据流转没有风险。需要明确：

• 哪些字段会发送到 GPU 服务；
• 是否可以先在 Web 服务器脱敏；
• 推理日志是否保存原文；
• 模型服务是否会将输入写入临时目录；
• 任务完成后临时文件何时删除；
• 备份中是否包含用户原始文件；
• 不同租户之间是否有独立的任务和存储空间；
• 服务商是否允许自行管理密钥和日志。

对不需要上下文的任务，可以只向 GPU 发送必要字段。例如，分类任务不必传递完整用户资料；文档问答可以先提取文本片段，再发送与当前问题相关的内容。这样既能减少网络传输，也能缩小敏感数据暴露范围。

方案选择：让香港服务器负责业务，让 GPU 服务器负责计算

基础组合：一台香港服务器加一台香港 GPU 服务器

对于已经明确需要在线推理的业务，较容易落地的基础组合是：

这种组合的好处是故障边界清楚。GPU 服务临时不可用时，官网、登录和历史任务仍可以正常访问；Web 侧出现流量高峰时，也不会直接杀死模型进程。后续需要增加 GPU 或替换模型时，业务接口无需整体迁移。

轻量场景：先由香港服务器承载 Web 和 CPU 推理

不是所有 AI 功能都需要 GPU。以下情况可以先使用香港服务器的 CPU 处理：

• 文本量较短的关键词提取；
• 规则与小模型结合的分类；
• 低频的内容审核预处理；
• 向量维度较小、批量不大的离线任务；
• AI 仅作为后台辅助工具，用户不要求即时返回。

这种方式适合验证业务流程，但需要设置边界。CPU 推理如果占满处理器，可能拖慢 Nginx、数据库连接和登录接口。可以把推理进程限制在独立的 CPU 核心或容器资源范围内，并将低优先级任务放入队列。

当出现以下信号时，通常就需要把推理迁移到 GPU：

• 模型加载后占用大量内存，影响 Web 应用；
• AI 请求高峰导致页面接口延迟一起上升；
• 单次推理时间明显超过页面可接受等待时间；
• CPU 长时间接近满载，但模型吞吐仍不足；
• 需要处理图像、音频或较长上下文；
• 模型需要常驻显存以减少反复加载。

多模型场景：按模型或任务拆分 GPU

当业务同时使用文本生成、图像生成和视觉识别时，不建议把所有模型都塞入一台 GPU 服务器。不同模型的显存占用、启动时间和并发特征不同，混部可能导致频繁卸载模型或出现显存碎片。

可以按任务划分：

• 文本模型使用一组持续运行的推理实例；
• 图像模型使用独立 GPU，按照任务量开启；
• 视觉识别或 OCR 使用另一类适配的推理节点；
• 低频模型采用按需启动，但要向用户说明首次任务可能更慢；
• 高优先级任务和批量任务进入不同队列。

香港服务器只需要根据任务类型选择目标服务，不必知道每张 GPU 的内部细节。GPU 服务可以通过统一接口返回状态、耗时、错误类型和模型版本，便于后续替换硬件或推理框架。

网页请求和 AI 请求必须分开限流

常见问题是所有请求共用一个应用进程和连接池。当 AI 请求等待时间较长时，数据库连接、线程或反向代理连接被占用，最终普通网页也变慢。

更合理的分层方式包括：

• 页面和登录接口使用独立连接池；
• AI 创建任务接口只负责校验和入队；
• GPU 结果查询接口设置较短处理时间；
• 每个用户设置并发任务上限；
• 每个模型设置独立队列；
• 超过队列长度后返回明确的繁忙状态；
• 低优先级任务不抢占付费或实时任务；
• 重试只针对可确认的临时错误。

对于已经创建的任务，重试必须具备幂等机制。可以使用 job_id 或请求指纹判断任务是否已经提交，避免 GPU 短暂超时后，Web 服务器重复创建相同任务。

运行观察：上线后要看哪些信号

Web 层、队列层和 GPU 层分别监控

只看服务器 CPU 利用率，无法判断 AI 服务是否健康。建议至少建立三层指标。

GPU 利用率低，不一定代表 GPU 资源充足。如果显存已经接近上限、模型频繁加载，或者请求大量停留在队列中，实际服务能力仍可能不足。反过来，GPU 利用率较高也不代表必须立即扩容，还要结合队列等待时间、错误率和用户可接受的响应时间判断。

建议为每个任务记录以下字段：

job_id
user_id 或租户标识
model_version
created_at
queued_at
started_at
finished_at
input_size
output_size
status
error_code
retry_count

通过这些时间点可以区分问题发生在 Web 接入、排队、模型启动、实际推理还是结果写入。比如：

排队时间 = started_at - queued_at
推理时间 = finished_at - started_at
端到端时间 = finished_at - created_at

如果排队时间持续增加而推理时间稳定，通常是 GPU 并发或调度能力不足；如果排队时间不长但推理时间突然变长，应检查输入长度、模型切换、显存回收和运行环境。

为 GPU 中断设计降级路径

GPU 服务器重启、驱动异常、模型进程退出或显存不足时，Web 服务器不应一直等待。可以设计以下处理方式：

• 同步请求超过时间上限后转为异步任务；
• GPU 健康检查失败时，暂停新任务进入；
• 已提交任务保留为“等待恢复”或“执行失败”；
• 页面继续提供普通内容和历史结果；
• 对不依赖生成内容的页面提供规则结果或人工处理入口；
• 恢复后先处理积压任务，再逐步开放新请求。

健康检查最好分为两级。进程级检查只能确认接口端口还在监听，模型级检查则需要确认目标模型已经加载并能完成一条轻量测试请求。两者不能混为一谈，否则端口正常但模型不可用时，Web 侧仍会不断提交任务。

模型加载时间要纳入用户体验

冷启动是 GPU 方案中容易被忽略的部分。模型第一次加载可能需要读取多个 GB 的权重，耗时取决于磁盘、内存、模型格式和推理框架。若业务只在每天某个时段使用 AI，可以接受首次任务较慢；若用户随时发起对话，则应让常用模型常驻显存。

运行策略可以分为：

• 高频模型常驻；
• 低频模型按需加载；
• 相同模型请求尽量批处理；
• 不同模型避免频繁交替占用同一块 GPU；
• 模型版本切换采用新旧实例并行，再切换流量；
• 模型文件使用校验值，避免下载不完整文件后启动。

模型升级时，不应直接覆盖正在运行的模型文件。更安全的做法是保存独立版本目录，先在非生产实例完成加载和样本验证，再切换服务入口。旧版本保留到新版本稳定后再清理，避免升级失败时无法回退。

产品核对：两类服务器分别验收什么

香港服务器的采购与交付检查

香港服务器主要承担 Web 和业务入口，验收重点应围绕网络、系统资源和稳定运行条件，而不是 GPU 参数。

可以核对：

• CPU、内存和磁盘规格是否与订单一致；
• 系统盘和数据盘是否分离；
• 公网 IPv4、IPv6 是否按需求提供；
• 入方向、出方向带宽和流量计费口径是否明确；
• 备份是否独立于主机磁盘；
• 重装系统、快照、救援和远程控制方式；
• 安全组和防火墙默认规则；
• 是否支持私有网络连接 GPU 服务器；
• 数据中心区域是否与业务数据要求相符；
• 资源是独享还是共享，以及超售限制如何处理。

带宽的“峰值”与长期可用吞吐不能简单等同。应使用实际业务文件和典型接口，在不同时间段验证连接建立、上传、下载和持续传输表现。对于图片站、文件站和视频类业务，还要单独核对出方向流量费用，不能只关注端口带宽数字。

香港 GPU 服务器的采购与交付检查

GPU 服务器需要把硬件、软件和计费方式一起确认：

• GPU 型号、数量和显存容量；
• 是否为独享 GPU，是否存在显存切分；
• 驱动版本和 CUDA 版本；
• 是否可以自行安装目标推理框架；
• CPU 内存、系统盘和模型盘容量；
• 模型文件能否长期保留；
• GPU 使用时长如何计费；
• 关机、暂停和释放资源的区别；
• GPU 服务器重启后模型是否自动恢复；
• 是否提供内网地址和固定来源访问控制；
• 计算、磁盘、流量和公网 IP 是否分别计费。

在 Linux 和 NVIDIA 驱动正常安装的前提下，可以使用非破坏性命令核验 GPU 基本信息：

nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv
free -h
df -h

命令只能确认当前系统看到的资源，不能证明目标模型一定兼容。交付验收还应使用业务模型完成一组代表性测试，包括短输入、长输入、并发请求、连续运行和异常中断恢复。验收结果应记录模型版本、输入长度、输出长度、响应时间、显存占用和错误信息。

成本要按“占用方式”而不是只看月租

香港服务器的成本通常包括实例或物理机费用、系统盘和数据盘、IPv4 地址、备份、流量以及可能的安全服务费用。GPU 服务器除基础资源外，还要考虑模型存储、GPU 使用时长、出方向流量、快照和空闲占用。

可以用下面的方式估算：

Web 总成本
= 主机资源 + 磁盘 + 公网地址 + 备份 + 流量 + 增值服务

GPU 总成本
= GPU 资源 + CPU/内存 + 模型磁盘 + 备份 + 流量 + 空闲占用

如果 GPU 每天只处理少量任务，却必须全天保持模型常驻，成本重点就不是单次推理速度，而是空闲时段的占用。此时可以比较按需启动、定时运行或共享推理池，但要把冷启动时间纳入业务承诺。

如果模型需要持续在线、请求存在明显高峰且不能接受启动等待，则常驻 GPU 更容易控制响应时间。若业务是每日批处理，可以将任务集中到固定窗口，减少 GPU 长时间空转。两种方式没有统一答案，应根据任务时间分布、允许等待时间和数据保留要求选择。

扩展边界：什么时候需要重新设计架构

适合保持两台服务器分工的范围

“香港服务器加香港 GPU 服务器”的组合，适合以下业务阶段：

• Web 访问量已经需要独立承载；
• AI 功能是业务的一部分，但不是全部业务；
• 模型数量有限，推理接口可以统一；
• 需要让网站和 GPU 计算独立扩容；
• 用户主要分布在亚洲及周边地区，需要集中部署；
• 团队希望先控制架构复杂度，再逐步增加节点。

在这一阶段，Web 服务器可以继续作为统一入口，GPU 服务器按照模型和任务类型扩充。数据库、缓存和对象存储则应尽量独立，避免把主机本地磁盘当成长期业务数据仓库。

不适合直接套用的范围

以下情况需要重新评估，而不是简单增加一台 GPU：

• 需要训练大模型或进行大规模微调；
• 模型权重远超单卡显存，并且需要多 GPU 并行；
• 需要极低延迟的实时视频或语音处理；
• 输入数据量很大，跨服务器传输成为主要耗时；
• 多个租户需要严格隔离 GPU、存储和日志；
• AI 任务包含长时间批处理，队列规模远大于 Web 访问规模；
• 对数据驻留、审计和删除证明有严格要求；
• 业务需要跨地区容灾，而单一香港区域无法满足恢复目标。

例如，视觉任务每次需要上传数百 MB 的原始视频时，Web 服务器和 GPU 服务器之间的网络就可能成为主要瓶颈。此时应考虑让文件先进入靠近 GPU 的对象存储，再由推理服务读取，结果只返回任务状态和结果地址，而不是让所有大文件经过 Web 应用中转。

可执行的扩展路径

业务量增长后，可以按以下顺序扩展：

1. 先将 Web、AI 网关和 GPU 服务的监控指标分开；
2. 再拆分同步接口与异步队列，避免长请求占用 Web 连接；
3. 为不同模型建立独立队列和并发上限；
4. 增加第二台 Web 服务器，并把会话和任务状态外置；
5. 增加 GPU 节点，由任务调度器分配模型和负载；
6. 将模型文件、用户文件和生成结果迁移到独立存储；
7. 对关键服务增加备份、故障转移和跨节点恢复方案。

扩展时不要只复制服务器数量，还要确认状态是否真正无状态。登录会话、任务状态、额度扣减和生成文件如果仍保存在单台 Web 服务器本地，增加第二台机器后可能出现用户登录丢失、任务查询不到或结果无法展示的问题。

上线前的一组验收问题

在确定方案前，可以分别向香港服务器和香港 GPU 服务器供应方确认以下内容：

• Web 服务器的 CPU、内存、磁盘和带宽是否为独享或共享；
• 公网流量、内网流量和 GPU 出方向流量如何计费；
• 两台服务器能否使用私有网络互通；
• GPU 型号、显存、驱动和软件环境是否支持目标模型；
• GPU 是独享还是共享，重启后资源是否变化；
• 模型文件能否保留，系统重装是否会清除；
• 是否支持快照、备份、救援和远程控制；
• 资源不足时能否升配，升配是否需要停机；
• 发生硬件故障时如何更换，数据如何恢复；
• 订单状态、推理日志和用户文件分别保存在哪里。

下一步可以先整理一份业务基线：普通页面峰值并发、AI 每日请求量、每秒峰值请求、单次输入输出大小、允许等待时间、模型参数规模、显存需求、数据敏感程度和可接受的月度资源成本。再用代表性模型进行短文本、长文本、并发和连续运行测试。

如果测试结果显示 Web 延迟稳定，但 GPU 队列持续增长，应优先调整 GPU 并发、模型批处理或增加推理节点；如果 GPU 仍有余量而页面变慢，则应检查 Web 服务器的连接池、数据库和磁盘；如果两者之间的传输占据主要耗时，则应优先优化私有网络、文件存储和数据流向。按照这些业务条件逐项验证，香港服务器与香港 GPU 服务器的分工才能从“硬件组合”变成可持续运行的业务架构。