企业官网建设流程全解析

1. 项目概述：当个人开发者遇上AI全栈

最近在折腾一个AI驱动的个人项目，从数据爬取、清洗、模型微调到最终的API部署和前端展示，整个流程跑下来，感觉像在玩一个大型的“打地鼠”游戏——这边刚把数据处理完，那边模型训练的资源又告急了。对于个人开发者或小团队来说，搭建一套完整的AI工作流，最大的拦路虎往往不是算法本身，而是算力成本和运维复杂度。

传统的做法要么是租用昂贵的云端GPU实例，账单看着就肉疼；要么是在本地用老旧的显卡吭哧吭哧地跑，效率低下还影响日常办公。直到我开始尝试用腾讯云的轻量应用服务器（Lighthouse），配合其云生态里的各种工具，意外地发现了一条高性价比的“通关路径”。这个项目的核心，就是验证如何用一台最基础的Lighthouse实例，串联起从数据到应用的全流程，我将其称为“OpenClaw”工作流。这里的“OpenClaw”并非指某个特定开源项目，而是一种工作流理念的比喻：像螃蟹的钳子一样，用轻量、灵活且低成本的方式，“抓取”并处理AI任务。

这套方案特别适合谁呢？如果你是学生、独立开发者、创业小团队的成员，或者是对AI应用开发感兴趣、希望以最低成本实践全流程的爱好者，那么接下来的内容就是为你准备的。我们将避开那些重型的、企业级的复杂架构，聚焦于如何用最务实、最“抠门”的方式，让一台轻量服务器发挥出最大效能。

2. 核心思路与架构设计：为什么是Lighthouse+云生态？

在深入实操之前，我们必须先理清选择这套技术栈背后的逻辑。这决定了我们后续每一步操作是否高效、是否经济。

2.1 算力需求分析与Lighthouse定位

一个完整的AI工作流，其算力需求是波峰波谷非常明显的：

1. 数据预处理与模型微调：这是算力消耗的“波峰”，需要较强的CPU和内存，如果涉及微调稍大的模型，GPU几乎是必须的。
2. 模型推理服务：这是“波峰”但相对平缓，需要稳定的CPU/GPU和网络I/O，对延迟敏感。
3. 任务调度、数据流管理：这是“波谷”，对算力要求不高，但需要稳定的运行环境和网络。

如果为每个阶段都配置专用高性能服务器，成本无法承受。我们的策略是：将高强度的计算任务“卸载”到云上按需使用的弹性资源，而将轻量、持久、需要稳定环境的核心调度与服务工作，部署在一台固定的、低成本的Lighthouse上。

Lighthouse在这里扮演的是“中枢神经”和“持久化基地”的角色。它的核心优势在于：

• 成本极低：相比云服务器CVM，同配置下Lighthouse价格优势明显，包年包月更划算，非常适合7x24小时运行的核心服务。
• 开箱即用：内置多种应用镜像（如Docker、WordPress），简化了基础环境部署。
• 带宽充足：对于个人项目，其提供的带宽完全足够应对模型下载、API调用和数据同步。
• 无缝集成腾讯云生态：可以非常方便地使用对象存储COS、容器服务TKE、云函数SCF等产品，形成联动。

2.2 “OpenClaw”工作流架构拆解

基于以上分析，我设计的架构如下图所示（注：此处为文字描述，实际博文中应避免使用Mermaid图表）：

整个工作流以一台Lighthouse为核心枢纽，它上面运行着几个关键服务：

1. 任务调度器：采用Celery+Redis。Celery负责分发异步任务，Redis作为消息代理和结果缓存。所有工作流的触发、步骤间的衔接，都由这里的调度器指挥。
2. 核心应用服务：使用Docker容器化部署。例如，一个用FastAPI编写的统一API网关，对外提供推理接口；或者一个简单的Flask/Django管理后台，用于监控任务状态和手动触发流程。
3. 数据与模型缓存：服务器本地SSD用于缓存热数据、预处理后的数据集以及下载好的轻量级模型。冷数据、原始数据集、训练好的大模型则存储在腾讯云对象存储COS中，按需拉取。
4. 监控与日志：使用Supervisor或Systemd托管核心进程，配合crontab进行定时任务。日志统一收集到本地文件，重要日志可同步至COS或CLS（腾讯云日志服务）。

当需要进行数据清洗、模型训练/微调等重计算任务时，Lighthouse上的调度器不会自己硬扛，而是会通过腾讯云API，动态创建一台按量计费的GPU云服务器CVM，或者发起一个云函数SCF任务，亦或是提交一个容器服务TKE的Job。计算完成后，结果自动存回COS，并通知Lighthouse上的服务。推理阶段，如果是轻量模型，可直接在Lighthouse上部署；如果是大模型，同样可以调用云上专门的GPU推理服务。

这样，Lighthouse始终保持轻量运行，承担低功耗的协调和服务工作，而昂贵的计算资源只在需要时才按秒计费，实现了成本的最优控制。

2.3 工具选型背后的“抠门”哲学

• 为什么用Celery？因为它轻量、异步、可靠，与Python生态无缝集成，非常适合构建复杂的任务流水线。相比重量级的Airflow，Celery在资源有限的Lighthouse上运行得更从容。
• 为什么用Docker？容器化确保了环境的一致性，避免了“在我机器上能跑”的噩梦。更重要的是，它为将来可能的扩展（比如将某个服务快速迁移到K8s集群）奠定了基础。
• 为什么重度依赖COS？对象存储几乎是无限容量的“硬盘”，成本极低，并且与腾讯云其他服务（如CVM、SCF）内网互通，数据传输免费且高速，是连接各个计算环节的“血管”。
• 为什么选择腾讯云全家桶？生态内集成带来的便利是巨大的。所有服务在同一个VPC内网中，安全且高速；使用同一个账号管理，权限和账单清晰；API调用风格一致，开发效率高。避免了跨云服务商带来的配置复杂度和网络延迟问题。

注意：这套架构的灵活性很高。你可以根据实际项目复杂度增减组件。例如，初期可以完全在Lighthouse上完成所有轻量任务，仅把最耗时的训练放到云GPU上。随着项目发展，再逐步引入更复杂的调度和云服务。

3. 环境准备与基础服务搭建

理论清晰后，我们开始动手。首先需要初始化我们的Lighthouse，并将其打造成一个稳固的“基地”。

3.1 Lighthouse初始化与安全加固

购买并登录Lighthouse后，第一件事不是急着装软件，而是做好安全加固，这是所有生产级应用的第一步。

1. 更新系统与创建用户：

   # 以root登录后，更新系统 sudo apt update && sudo apt upgrade -y # 创建一个新的普通用户，例如命名为 `dev` sudo adduser dev # 将用户加入sudo组 sudo usermod -aG sudo dev

2. 配置SSH密钥登录，禁用密码登录（至关重要）：

   # 在本地机器生成SSH密钥（如果还没有） # ssh-keygen -t rsa -b 4096 -C "your_email@example.com" # 将公钥上传到服务器 # 在本地执行：ssh-copy-id dev@your_lighthouse_ip # 如果不行，手动操作： # 1. 本地查看公钥：cat ~/.ssh/id_rsa.pub # 2. 在服务器上：su - dev，然后 vim ~/.ssh/authorized_keys，粘贴公钥。 # 备份并修改SSH配置 sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup sudo vim /etc/ssh/sshd_config

   找到并修改以下几行：

   PubkeyAuthentication yes PasswordAuthentication no # 改为no，禁用密码登录 PermitRootLogin no # 禁止root直接登录

   保存后重启SSH服务：sudo systemctl restart sshd。务必在重启前，用新窗口测试密钥登录是否成功，否则可能被锁在服务器外！

3. 配置基础防火墙： Lighthouse控制台有防火墙功能，建议只开放必要的端口（如22, 80, 443）。也可以在系统内用ufw：

   sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw --force enable

3.2 核心依赖安装：Docker与Python环境

我们将使用Docker来隔离主要应用环境，但宿主机上也需要一个干净的Python环境来运行一些管理脚本和Celery的Worker。

1. 安装Docker与Docker Compose：

   # 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER # 将当前用户加入docker组，需重新登录生效 # 安装Docker Compose (v2) sudo apt install docker-compose-plugin -y # 验证安装 docker --version docker compose version

2. 配置Python虚拟环境：

   sudo apt install python3-pip python3-venv -y cd ~ python3 -m venv openclaw-env source openclaw-env/bin/activate # 安装基础包 pip install --upgrade pip pip install celery redis flower # flower是Celery的Web监控工具

3.3 消息队列与缓存：Redis部署

Redis是Celery的消息代理，也是我们工作流中重要的缓存组件。用Docker部署最为方便。

1. 创建Docker Compose文件： 在~/openclaw目录下创建docker-compose.yml：

   version: '3.8' services: redis: image: redis:7-alpine container_name: openclaw-redis restart: always ports: - "6379:6379" command: redis-server --appendonly yes --requirepass your_strong_password_here # 务必设置强密码！ volumes: - ./data/redis:/data networks: - openclaw-net # 后续可以在这里添加PostgreSQL、MinIO等服务 # postgres: # image: postgres:15 # ... networks: openclaw-net: driver: bridge

2. 启动Redis：

   cd ~/openclaw docker compose up -d redis docker compose logs -f redis # 查看日志，确认启动成功

   使用docker exec -it openclaw-redis redis-cli -a your_password ping测试连接，应返回PONG。

实操心得：在Lighthouse上，所有持久化数据（如Redis的AOF文件、PostgreSQL数据、应用日志）一定要通过volumes映射到宿主机的目录（如~/openclaw/data）。这样即使容器崩溃或重建，数据也不会丢失。同时，定期将整个data目录备份到腾讯云COS，是成本极低的容灾方案。

4. 核心工作流实现：从任务调度到计算卸载

现在，我们的“基地”已经就绪。接下来构建工作流的核心——任务调度系统，并实现将重计算任务卸载到腾讯云弹性资源。

4.1 构建Celery异步任务系统

Celery将是我们工作流的大脑。我们创建一个简单的项目结构。

1. 项目结构：

   ~/openclaw/ ├── docker-compose.yml ├── tasks/ │ ├── __init__.py │ ├── celery_app.py # Celery应用定义 │ ├── data_tasks.py # 数据相关任务 │ └── model_tasks.py # 模型相关任务 ├── workers/ # 存放启动worker的脚本 └── requirements.txt

2. 定义Celery应用(tasks/celery_app.py)：

   from celery import Celery import os # 从环境变量读取Redis密码，更安全 redis_password = os.getenv('REDIS_PASSWORD', 'your_strong_password_here') redis_url = f'redis://:{redis_password}@localhost:6379/0' app = Celery( 'openclaw', broker=redis_url, backend=redis_url, include=['tasks.data_tasks', 'tasks.model_tasks'] # 注册任务模块 ) # 配置 app.conf.update( task_serializer='json', accept_content=['json'], result_serializer='json', timezone='Asia/Shanghai', enable_utc=True, # 设置任务路由（可选，用于区分CPU/GPU任务） task_routes = { 'tasks.data_tasks.*': {'queue': 'cpu_queue'}, 'tasks.model_tasks.train_heavy_model': {'queue': 'gpu_queue'}, }, )

3. 编写一个示例任务(tasks/data_tasks.py)：

   from .celery_app import app import requests from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.cvm.v20170312 import cvm_client, models import json import time @app.task(bind=True, name='data.process_raw_dataset') def process_raw_dataset(self, cos_url): """一个模拟的数据处理任务：从COS下载数据，清洗，再传回COS""" task_id = self.request.id print(f'[{task_id}] 开始处理数据: {cos_url}') # 模拟耗时操作 time.sleep(10) # 这里可以添加实际的下载、清洗逻辑 # 例如使用腾讯云COS SDK processed_url = f'processed_{cos_url}' print(f'[{task_id}] 数据处理完成，结果位于: {processed_url}') return {'status': 'success', 'processed_url': processed_url} @app.task(bind=True, name='compute.create_gpu_instance') def create_gpu_instance(self, instance_type='GPU', script_url=''): """关键任务：调用腾讯云API，创建一台GPU实例执行计算脚本""" # 1. 初始化腾讯云客户端（需提前配置SecretId和SecretKey到环境变量） cred = credential.Credential( os.getenv('TENCENTCLOUD_SECRET_ID'), os.getenv('TENCENTCLOUD_SECRET_KEY') ) httpProfile = HttpProfile() httpProfile.endpoint = "cvm.tencentcloudapi.com" clientProfile = ClientProfile() clientProfile.httpProfile = httpProfile client = cvm_client.CvmClient(cred, "ap-guangzhou", clientProfile) # 2. 组装创建实例的请求参数 req = models.RunInstancesRequest() params = { "InstanceChargeType": "SPOTPAID", # 使用抢占式实例，价格极低 "Placement": { "Zone": "ap-guangzhou-3", }, "InstanceType": "GN7.2XLARGE32", # 示例GPU机型，按需选择 "ImageId": "img-xxxxxxx", # 选择一个预装好CUDA和Python的镜像 "InstanceName": f"gpu-worker-{self.request.id[:8]}", "LoginSettings": { "KeyIds": ["skey-xxxxxxx"] # 使用密钥对登录 }, # 在UserData中传入初始化脚本，实例启动后自动执行 "UserData": f"""#!/bin/bash # 从COS下载任务脚本 wget -O /root/task_script.py {script_url} # 执行任务 python3 /root/task_script.py # 任务完成后，将结果上传到COS，并调用一个Webhook通知Lighthouse # ... # 最后，自行销毁实例（通过API或脚本） """ } req.from_json_string(json.dumps(params)) # 3. 发起创建请求 resp = client.RunInstances(req) instance_id_set = resp.InstanceIdSet print(f'GPU实例创建请求已发出，实例ID: {instance_id_set}') return {'status': 'submitted', 'instance_ids': instance_id_set}

4. 启动Celery Worker： 在~/openclaw/workers目录下创建启动脚本start_cpu_worker.sh：

   #!/bin/bash source ~/openclaw-env/bin/activate cd ~/openclaw celery -A tasks.celery_app worker --loglevel=info --queues=cpu_queue --concurrency=2

   使用Supervisor来管理这个worker进程，确保它一直在运行。

4.2 与腾讯云生态集成：COS与SCF实战

Lighthouse上的任务需要与云上资源交互。这里以对象存储COS和云函数SCF为例。

1. 集成腾讯云COS SDK： 在虚拟环境中安装SDK：pip install cos-python-sdk-v5。 编写一个工具模块utils/cos_helper.py，封装上传、下载、生成预签名URL等常用操作。将COS的SecretId和SecretKey存储在Lighthouse的环境变量或配置文件中，切勿硬编码在代码里。

2. 使用云函数SCF处理事件驱动任务： 有些任务不需要持久化的服务器，比如一个每晚定时运行的模型验证任务，或者一个由文件上传触发的数据预处理任务。SCF（Serverless Cloud Function）是完美选择。

   • 场景：当用户通过前端上传一个数据文件到COS的特定目录时，自动触发一个SCF函数。
   • 实现：在腾讯云控制台创建一个SCF函数，触发器设置为COS文件上传事件。函数代码从事件中获取文件信息，进行快速处理（如格式验证、生成缩略图、提取元数据），然后将处理结果写回COS或发送消息到Lighthouse的Redis队列。
   • 优势：SCF按调用次数和运行时间计费，对于低频、短时任务，成本几乎可以忽略不计。Lighthouse无需常驻进程来监听这类事件。

3. 统一API网关与任务触发： 在Lighthouse上，我们用FastAPI快速搭建一个API服务 (app/main.py)。

   from fastapi import FastAPI, BackgroundTasks from tasks.data_tasks import process_raw_dataset, create_gpu_instance import uuid app = FastAPI(title="OpenClaw Workflow API") @app.post("/trigger/data-process") async def trigger_data_process(cos_url: str, background_tasks: BackgroundTasks): task = process_raw_dataset.delay(cos_url) return {"message": "Data processing task submitted", "task_id": task.id} @app.post("/trigger/model-training") async def trigger_model_training(config: dict, background_tasks: BackgroundTasks): # config中包含模型类型、数据路径、超参数等 # 判断任务类型：轻量训练本地执行，重量训练提交到云GPU if config['model_size'] == 'heavy': # 将训练脚本和配置上传到COS script_url = upload_to_cos(config) # 调用Celery任务，创建GPU实例 task = create_gpu_instance.delay('GPU', script_url) return {"message": "Heavy training submitted to cloud GPU", "task_id": task.id} else: # 轻量训练，提交到本地队列 task = train_light_model.delay(config) return {"message": "Light training task submitted locally", "task_id": task.id}

   这个API运行在Lighthouse上，对外提供统一的触发接口。前端或外部系统只需调用这些API，复杂的任务编排和资源调度在后台自动完成。

5. 模型部署与推理服务优化

工作流的最后一步，是将训练好的模型部署成可用的服务。根据模型大小和性能要求，我们有多种策略。

5.1 轻量模型本地部署：FastAPI + ONNX Runtime

对于参数量较小（如几百MB以内）的模型，完全可以直接部署在Lighthouse上。

1. 模型优化与转换： 使用onnxruntime或TensorRT等工具将PyTorch/TensorFlow模型转换为优化后的格式，能显著提升推理速度并减少资源占用。

   # 示例：安装ONNX Runtime pip install onnxruntime # 在训练脚本中导出模型为ONNX格式

2. 构建高效的推理API：

   from fastapi import FastAPI, File, UploadFile import onnxruntime as ort import numpy as np from PIL import Image import io app = FastAPI() # 启动时加载模型 sess = ort.InferenceSession('model.onnx', providers=['CPUExecutionProvider']) @app.post("/predict") async def predict(image: UploadFile = File(...)): contents = await image.read() img = Image.open(io.BytesIO(contents)) # 预处理图像 input_tensor = preprocess(img) # 推理 outputs = sess.run(None, {'input': input_tensor}) # 后处理 result = postprocess(outputs) return {"prediction": result}

3. 使用Gunicorn管理服务： 在生产环境，用Gunicorn这样的WSGI服务器来运行FastAPI应用，性能更稳定。

   pip install gunicorn gunicorn -w 2 -k uvicorn.workers.UvicornWorker main:app --bind 0.0.0.0:8000

   同样，用Supervisor来托管Gunicorn进程。

5.2 重量模型云上部署：TKE/云函数+API网关

对于大模型（如LLaMA、ChatGLM等），部署在Lighthouse上不现实。此时，腾讯云容器服务TKE或专门优化的GPU推理实例是更好的选择。

1. TKE部署方案：

   • 将模型和推理代码打包成Docker镜像，推送到腾讯云容器镜像服务TCR。
   • 在TKE集群中创建一个Deployment和Service，暴露推理服务。
   • 利用TKE的HPA（水平自动扩缩容）功能，根据请求量自动调整Pod副本数。
   • Lighthouse上的API网关，通过内网域名或负载均衡器地址，将大模型的预测请求转发到TKE服务。

2. Serverless推理方案： 对于请求量波动大、偶发性的推理需求，可以使用云函数SCF的GPU版本或腾讯云TI-Platform的弹性推理服务。它们都支持按请求计费，在无请求时不产生费用，非常适合初创项目或测试阶段。

3. 统一网关路由： 最终，对前端暴露的只有一个API网关地址（可以是Lighthouse上的Nginx反代，也可以是腾讯云API网关）。网关根据请求路径进行路由：

   • /api/v1/light/predict-> 路由到Lighthouse本地的FastAPI服务。
   • /api/v1/heavy/predict-> 路由到TKE集群或云函数的大模型服务。 这样，对外接口统一，内部架构灵活伸缩。

6. 监控、运维与成本控制实战

系统跑起来只是第一步，如何让它稳定、可控、不超预算，才是长期运营的关键。

6.1 基础监控与日志收集

1. 进程监控：使用Supervisor不仅管理进程，还能查看其运行状态和日志。配置supervisorctl status可以快速查看所有托管服务（Celery worker, Gunicorn, Redis等）是否健康。
2. 资源监控：Lighthouse控制台提供了基础的CPU、内存、带宽监控。对于更细粒度的监控，可以安装Prometheus Node Exporter，并用Grafana在一个轻量级容器中展示仪表盘。
3. 应用日志：所有应用（FastAPI, Celery）的日志应输出到标准输出和文件。使用logrotate工具定期切割和清理日志文件，避免撑满磁盘。关键业务日志可以同时发送到腾讯云CLS，便于集中查询和分析。

6.2 成本控制技巧与账单分析

这是本方案的精髓所在，务必时刻关注。

1. Lighthouse成本固定：选择包年包月套餐，这是沉没成本，可以安心用作中枢。
2. 弹性计算资源成本动态：
   • 抢占式实例：对于训练任务，务必使用抢占式实例（Spot Instance），价格通常为按量计费的10%-20%。虽然可能被回收，但训练任务通常可以设计成可中断续训的（Checkpoint），性价比无敌。
   • 云函数SCF：对于短时、事件驱动的任务，SCF成本极低。每月有免费额度，对于轻量应用几乎免费。
   • COS存储成本：采用低频存储或归档存储存储冷数据，成本极低。注意控制API请求次数和数据取回量。
3. 设置预算告警：在腾讯云“费用中心”设置月度预算告警。例如，设置弹性资源（CVM、SCF）的月度预算为100元，超过80元即发送短信或邮件告警。
4. 定期清理资源：编写一个定时任务（Crontab），定期检查并清理云上闲置的GPU实例、过期的COS文件等。避免忘记关机或删除测试资源导致的“账单惊喜”。

6.3 自动化运维脚本示例

分享几个我常用的脚本：

1. 清理闲置GPU实例脚本(scripts/cleanup_gpu_instances.py)：

   # 调用CVM API，查询所有名为“gpu-worker-*”的抢占式实例 # 如果实例状态为“运行中”但创建时间超过6小时，则强制关机或销毁。 # 可以将此脚本加入Celery定时任务或Crontab，每天凌晨执行。

2. 备份与同步脚本(scripts/backup_to_cos.sh)：

   #!/bin/bash # 使用COSCMD工具，将Lighthouse上~/openclaw/data目录同步到COS coscmd config -a $SECRET_ID -s $SECRET_KEY -b $BUCKET -r $REGION coscmd upload -r ~/openclaw/data/ /backups/$(date +%Y%m%d)/ # 保留最近7天的备份，删除更早的

   这个脚本可以设置为每周执行一次。

7. 常见问题与排查技巧实录

在实际搭建和运行过程中，我踩过不少坑。这里把一些典型问题和解决方法记录下来，希望能帮你节省时间。

7.1 网络与连接问题

• 问题：Lighthouse上的服务无法内网访问COS或其他腾讯云产品，速度慢。
• 排查：
  1. 确认Lighthouse实例是否和COS/SCF/CVM在同一个地域。同地域内网访问免费且高速，跨地域则走公网，产生流量费用且速度慢。
  2. 检查Lighthouse的私有网络VPC配置。确保所有云资源都在同一个VPC内，或者配置了对等连接/云联网。
  3. 使用telnet或curl测试内网域名或IP的连通性。
• 解决：将所有相关资源创建在同一个地域（如广州）的同一个VPC下。使用内网Endpoint进行连接（如COS的内网域名cos.ap-guangzhou.myqcloud.com）。

7.2 Celery任务卡住或失败

• 问题：任务长时间处于PENDING状态，或者Worker报连接Redis错误。
• 排查：
  1. 检查Redis：docker compose logs redis查看Redis日志。用redis-cli连接后，执行KEYS celery*查看是否有相关键。
  2. 检查Worker：supervisorctl tail -f celery_worker查看Worker日志。常见错误是任务代码有语法错误或导入模块失败。
  3. 检查任务序列化：确保任务参数是可JSON序列化的。复杂对象（如自定义类实例）无法直接传递。
• 解决：
  1. 确保Redis密码正确，且Lighthouse防火墙开放了6379端口（仅对内网）。
  2. 在Worker启动命令中增加--loglevel=debug获取更详细日志。
  3. 将复杂参数转换为基本数据类型（如字典、列表、字符串）再传递。

7.3 Docker容器资源占用过高

• 问题：Lighthouse内存或CPU使用率莫名飙升，导致服务响应慢。
• 排查：
  1. docker stats命令查看各个容器的实时资源占用。
  2. docker compose logs [service_name]查看异常日志。
  3. 可能是某个容器内应用内存泄漏，或日志文件未切割导致磁盘IO高。
• 解决：
  1. 在docker-compose.yml中为服务设置资源限制：

     services: my_app: image: my_image deploy: resources: limits: cpus: '1.0' memory: 512M

  2. 配置应用日志的滚动策略，或使用json-file日志驱动并设置大小限制。
  3. 定期使用docker system prune -a清理无用的镜像、容器和卷，释放磁盘空间。

7.4 云API调用失败或超时

• 问题：调用腾讯云API创建CVM或触发SCF时失败。
• 排查：
  1. 权限问题：检查使用的SecretId和SecretKey是否有对应操作的权限（如CVM全读写、SCF调用等）。在“访问管理CAM”中创建子账号并授予最小必要权限，比直接使用主账号密钥更安全。
  2. 配额问题：检查账号下CVM、GPU实例的配额是否已用完。在控制台相应页面可以申请提升配额。
  3. 参数错误：仔细检查API请求参数，特别是镜像ID、实例类型、地域等是否可用。使用SDK的from_json_string方法时，确保JSON格式正确。
  4. 网络超时：适当增加SDK客户端的超时时间。
• 解决：
  1. 在代码中增加详细的异常捕获和日志记录，打印出错的API名称和错误信息。
  2. 先在腾讯云API Explorer中调试API调用，确认参数正确无误后再写入代码。
  3. 对于异步操作（如创建实例），调用API后通常返回的是请求ID，需要再调用DescribeInstances等查询接口来确认最终状态，不要假设一次调用就100%成功。

这套“一台Lighthouse撑起AI全栈工作流”的方案，我已经在几个个人项目和一个小型团队内部工具上稳定运行了半年多。最大的体会是，它完美地平衡了灵活性、功能性和成本。你不再需要为了一个偶尔跑一下的训练任务而长期持有一张昂贵的显卡，也不再需要维护一个复杂的K8s集群来部署几个简单的服务。所有组件都清晰、可控，出了问题也容易定位。

当然，这套架构并非银弹。当你的项目用户量激增，需要处理高并发推理请求时，Lighthouse本身的性能会成为瓶颈，那时就需要将核心的API网关和无状态服务也容器化，并部署到更强大的集群中。但在此之前，这套方案足以支撑你从想法到原型，再到早期产品的完整闭环。最重要的是，它让你能专注于AI应用逻辑本身，而不是繁琐的基础设施运维。