petaV3 双区域房地产 AI Engine 云 GPU 验证与私有化部署计划书

版本：v2.1

日期：2026-08-06

适用对象：PropertyLab / petaV3 管理层、工程团队、mentor、潜在 pilot 客户

代码核对基线：codex/xiaochengxu，HEAD 05ee8ae22b18

计划范围：现有代码核对、云 GPU POC、CN / Global 双区域部署、AI 飞轮、外部客户私有化交付

v2.1 在 v2.0 的双区域架构上补充阿里云国际站 Phase 0 落地方案、从 POC 首周开始的业务结果标签、500 美元预算硬门、准确的节费停机方式，以及模型镜像和 TLS 安全要求。评审输入来自 2026-08-06 分享材料；云产品事实以阿里云和 vLLM 官方文档为准。

1. 执行摘要

PropertyLab 不需要从零训练一个基础大模型。更合理的目标是建立一套可私有部署的 Real Estate AI Engine：

1. 复用 petaV3 已有的 AI gateway、业务数据和房地产工作流。
2. 在云 GPU 上验证自托管开源模型，再决定是否采购本地 GPU。
3. 建立中国区域和国际区域两个独立数据面。
4. 让 Worker 分析高频触点，区域 Orchestrator 生成销售判断和 Next Best Action。
5. 记录建议是否被采纳，并与预约、带看、booking、成交和丢单结果连接。
6. 只共享匿名聚合指标、评分方法和版本化方法包，不让原始客户数据跨区域。

老板所说的 “two servers structure” 在生产设计中应理解为两个完整的区域部署，而不是两台单机：

两个区域使用同一套 petaV3 代码、schema contract、prompt contract 和业务方法，但数据库、对象存储、向量库、密钥、模型端点和运行日志相互独立。

1.1 分阶段路线

1.2 核心决策

• 先租云 GPU，不立即购买本地 GPU。
• 先接入现有 AiClient，不建立第二套业务 AI SDK。
• 先做 RAG、工作流和评测，不从零预训练。
• 先做 draft / recommendation，由人确认；自动发送必须逐场景放行。
• 先将原始数据留在所属区域，再讨论任何跨区域聚合。
• Phase 2 首批客户优先采用独立部署，不把现有 group_id 当作法律意义上的 tenant 隔离。
• Phase 0 选用阿里云国际站，吉隆坡 ap-southeast-3 优先，新加坡 ap-southeast-1 仅作库存或能力备选。
• 阿里云吉隆坡仍属于 Global Data Plane；它不能承载被定义为中国大陆区的真实客户数据。
• Phase 0 的核心资产是“输入 + AI 建议 + 人工操作 + 业务结果”的可审计标签链，不是 GPU 本身。

2. 本次代码核对结论

2.1 petaV3 已经实现的 AI 底座

2.2 当前已经使用 AI 的业务

2.3 数据底座已经具备的部分

• countries、projects.country_id、catalog_projects.country_id 和 property_analyses.country_id 已支持市场国家维度。
• catalogue ingestion adapter 明确要求 providerCode() 和 countryIso2()。
• catalog_project_sources 保存 provider-specific 来源记录和 raw payload，canonical catalogue 保持 source-agnostic。
• 香港 reference adapters 已能从 petaV2 reference connection 读取 HK 数据。
• engagements 已保存每个 lead × project 的销售生命周期，包括 won / lost、lost_stage 和时间。
• bookings 已保存 booking、SPA、leader review、取消原因和金额。
• WhatsApp message 已保存方向、发送、送达、已读、失败状态；AI 自动回复会标记 generated、trigger、provider 和 model。
• 小程序侧已有受控的 AI conversation 状态和 inquiry 持久化：候选楼盘由应用层约束，AI 不直接拥有数据库工具；AI 不可用时，咨询提交仍有确定性摘要和两阶段写入兜底。

2.4 尚未实现的关键能力

3. 产品定义

3.1 Real Estate AI Engine 的组成

Real Estate AI Engine 不是一个模型名称，而是一套产品能力：

1. Model Gateway：统一调用外部模型和自托管模型。
2. Regional Workers：抽取消息、通话、会议、portal 和现场触点中的结构化信号。
3. Regional Orchestrator：按 lead 汇总事实、验证冲突、更新画像并给出 Next Best Action。
4. Private RAG：在权限和区域边界内检索客户、楼盘、流程和知识文档。
5. Recommendation Sensor：记录建议展示、采纳、编辑、发送、执行或拒绝。
6. Outcome Join：把建议连接到 appointment、engagement、booking、SPA、won/lost。
7. Method Control Plane：版本化管理 prompt、评分规则、workflow 和安全策略。
8. Audit and Evaluation：记录质量、延迟、成本、错误、采纳率和业务提升率。

3.2 非目标

• 不从零预训练基础大模型。
• 不在 Test 阶段本地化所有视频、图片和语音模型。
• 不让中国原始客户数据进入国际模型 API。
• 不将 embedding 视为可自由跨境的匿名数据。
• 不在没有采纳与结果证据前宣传“提升成交率”。
• 不在没有 tenant 重构或独立部署前销售共享数据库多租户方案。

4. 目标架构

                         PETA Method Control Plane
                  prompt / workflow / score / policy versions
                    aggregate benchmark / release registry
                         NO raw customer data
                          /              \
              signed method package    signed method package
                       /                    \
          CN Regional Data Plane       Global Regional Data Plane
        -------------------------      ---------------------------
        China channel adapters         WhatsApp / LINE / Zoom / CRM
        Regional API + queue            Regional API + queue
        Operational database            Operational database
        Private object storage          Private object storage
        Regional vector store           Regional vector store
        CN model gateway / GPU           Global model gateway / GPU
        Worker + Orchestrator            Worker + Orchestrator
        Regional AI audit logs          Regional AI audit logs

4.1 Meta LOOP 在 petaV3 中的映射

模型名称不是架构。Worker、Orchestrator 和 Advisor 必须使用稳定接口，底层模型按区域、成本、质量和合规要求替换。

4.2 “一个大脑”的正确工程含义

“一个大脑”不等于把所有原始数据汇入一个数据库。它应表示：

• 一套统一的信号 schema。
• 一套统一的评分和工作流 contract。
• 一套版本化 prompt / policy 发布机制。
• 两个区域独立运行相同方法。
• 只通过受控 export 汇总非敏感评测结果。

4.3 数据路由规则

路由不能只根据房产国家决定。系统至少要区分：

中国中介销售香港房产时：

• 香港楼盘 catalogue 的 market_country 是 HK。
• 中国中介、企微客户、对话、录音和 AI 分析的 data_region 是 CN。
• 获得授权的公开楼盘产品资料可以发布一个只读 projection 到 CN。
• 中国客户原始数据、向量和录音不能因房产位于香港而写入 Global。

5. 数据结构更新方向

本节是 proposal 级别的目标 contract；具体 column、迁移顺序和删除项应与 Database Redesign 文档统一。

5.1 可复用现有表

5.2 建议新增的区域 contract

对于每客户独立部署，deployment_region 可由环境配置固定；对于未来共享平台，才需要 tenant 表和 row-level tenant key。

5.3 建议新增的飞轮表

ai_recommendations

• uuid
• ai_request_id
• lead_id
• engagement_id
• conversation_id
• recommendation_type
• payload
• deployment_region
• prompt_version
• model
• generated_at

ai_recommendation_events

Append-only event log：

• recommendation_id
• event_type: generated / shown / accepted / edited / sent / executed / dismissed / expired
• actor_id
• message_id
• metadata
• occurred_at

ai_outcome_links

• recommendation_id
• engagement_id
• booking_id
• outcome_type: appointment / booked / spa_signed / won / lost / cancelled
• outcome_at
• attribution_window
• metadata

现有 engagements 和 bookings 仍是业务结果 source of truth；新表只负责记录 AI 推荐和结果之间的可审计关系。

5.4 方法论控制表

Phase 2 再增加：

• method_packages
• method_package_versions
• method_package_deployments
• regional_export_batches

方法包可以包含 prompt、JSON schema、评分参数、workflow definition 和兼容模型列表，但不得包含客户原始样本。

5.5 区域数据库原则

• CN 和 Global 不建立数据库级 foreign key。
• 不做跨区域实时 Join。
• 不复制 leads、消息、录音、原始文档或 embeddings。
• catalogue 只能通过明确的 publish/export 流程复制。
• 聚合指标必须达到去标识化和最小样本门槛，再进入控制层。
• 每次方法包发布和聚合导出都要留下版本、操作者、hash 和时间。

6. Test / Phase 0：云 GPU 与双区域可行性验证

建议周期：4 周。

建议范围：一个 Global 云 GPU、两个隔离测试环境、合成或脱敏数据。

Phase 0 的目标是验证部署、接入、质量、成本和数据边界，不进行从零预训练或蒸馏。只有当真实业务评测证明通用模型无法达到目标，且已经积累足够的高质量标签数据，才进入微调或蒸馏评估。

6.1 Week 0：数据准备和基线

执行：

1. 选定 3 个首批任务：conversation analysis、WhatsApp draft、lead Next Best Action。
2. 从真实业务中抽取代表性样本，经授权后脱敏。
3. 为每个样本建立人工 gold answer 和评分 rubric；在任何 prompt 调优前固定 blind evaluation set。
4. 标记数据来源、客户类型、语言、市场国家、允许区域和 consent / retention 状态。
5. 从第一周开始记录可验证结果：appointment booked、viewing completed、booking、SPA signed、won/lost、发生时间、金额、标签来源和证据记录。
6. 无法确认的结果必须记为 unknown，不得用模型推断替代事实标签。
7. 建立外部 provider 当前质量、延迟和成本基线。

验收：

• 目标至少 100 个 conversation analysis 样本，其中冻结 20-50 个经双人复核的 blind evaluation 样本；数据不足时以 50 个为 POC 最低起点并记录局限。
• 目标至少 100 个 WhatsApp draft 样本和 50 个 lead/NBA 场景。
• blind evaluation set 的关键字段和已知业务结果标签完整率达到 90%；未知结果单独统计，不进入 uplift 分母。
• 样本不得包含未获授权的身份证、账户、完整电话或录音。

6.2 Week 1：部署云 GPU

执行：

1. 使用公司阿里云国际站账号；创建最小权限 RAM 运维用户，不共享主账号。若 bootstrap 临时使用宽权限，服务器创建后立即收窄。
2. 优先检查吉隆坡 ap-southeast-3 的实时库存和报价；缺货或规格不可用时才评估新加坡 ap-southeast-1，并记录选择原因。
3. 首选 ecs.gn8is.2xlarge（1 × NVIDIA L20 48GB、8 vCPU、64 GiB）；若目标区域没有 L20，备选 A10 24GB 级实例并运行 Qwen3-14B AWQ。任何具体规格都必须以创建页当日库存为准。
4. 选择按量付费、VPC、300-500GB ESSD 和磁盘加密。跨云访问时才使用 EIP；可以走 VPN / 私网互联时不开放公共入口。
5. 安全组只允许 petaV3 出站源访问 443；SSH 只允许 bastion / VPN 或工程师固定 IP；8000 对公网和 VPC 其他主机均不开放。
6. 安装 NVIDIA driver、Docker 和 NVIDIA Container Toolkit。
7. 用固定 vLLM tag 和批准的 image digest 启动服务；模型 repository revision、tokenizer revision、量化文件 checksum 同时写入 deployment manifest。
8. L20 先跑 Qwen3-14B BF16；A10 备选跑经过质量验证的 14B AWQ。首轮把 structured extraction 作为主要判定任务。
9. vLLM 仅绑定 localhost，并启用独立 service API key；对 petaV3 暴露的 Gateway 使用有效 CA 证书或私网 mTLS，禁止自签证书配合 verify=false。
10. 建立 500 美元 POC 硬预算，在 50%、80%、100% 设置告警；费用估算必须保存当日 calculator / order 页面证据。
11. 用 OOS 定时任务或 ECS API StopInstance 的 StoppedMode=StopCharging 在非工作时段停机。Linux shutdown / poweroff 不会触发节省停机模式，不得作为成本控制方案。
12. 记录模型版本、量化方式、GPU、显存、启动参数、EIP / 磁盘持续费用和实际每日成本。

验收：

• /v1/models 和 /v1/chat/completions 可从授权 petaV3 环境访问。
• endpoint 不对公网匿名开放。
• JSON response、streaming、timeout 和错误状态可重复测试。
• GPU、token throughput、首 token latency 和显存可监控。
• 500 美元预算告警已测试，非工作时段自动进入节省停机模式；同时记录该模式恢复时可能因库存不足而启动失败的风险。
• TLS 验证开启，客户端不包含 verify=false，部署清单中没有浮动 latest tag。

6.3 Week 2：接入 petaV3 internal_ai

现有代码允许复用 OpenAiTransport，但仍需正式注册 provider：

1. 在 AiCredential 增加 PROVIDER_INTERNAL_AI。
2. 将其加入 provider catalog 和 chat provider 列表。
3. 在 config/ai.php 增加 label、base URL、verify path、chat path、model catalog 和估算成本。
4. base URL 使用环境变量；service token 继续通过 encrypted ai_credentials 管理。
5. 为 POC 模型增加 admin-selectable model id。
6. 验证 AiKeyService model resolution 和 prompt pin。
7. 验证 prompt()、chat()、stream()、JSON mode 和失败日志。
8. 增加 provider、transport、model validation 和 request-log 测试。

验收：

• Manage AI Providers 可配置内部 endpoint token。
• Manage AI Prompts 可把指定 prompt pin 到 internal_ai。
• ai_requests 正确记录 provider、model、prompt、token、duration 和 error。
• 现有 OpenAI / Gemini / Anthropic / DeepSeek 行为不回归。

6.4 Week 3：Worker + Orchestrator 最小闭环

Worker：

1. 将 conversation_analysis prompt pin 到 internal_ai。
2. 运行 Call / F2F / Zoom 标准化 schema。
3. 与当前外部 provider 做 blind comparison，重点计算预算、异议、偏好、意图和 next action 的字段级准确率。

Orchestrator：

1. 增加一个注册 prompt key，例如 regional_orchestrator.
2. 输入只使用结构化 Worker 输出、lead facts 和当前 engagement。
3. 输出固定 JSON：temperature、buyer profile、lifecycle stage、risks、next action、confidence、evidence。
4. evidence 必须引用本区域内已有事实，不允许模型虚构来源。
5. 将结果保存为 recommendation，而不是只保存在 AI response text。
6. 每条 recommendation 预留 shown / accepted / edited / sent / dismissed / executed 事件，并连接 Week 0 定义的结果标签。

验收：

• 同一 lead 可以从 transcript 进入 Worker，再进入 Orchestrator。
• 输出 schema 可验证、可审计、可重放。
• 错误不会触发自动客户消息。

6.5 Week 4：双区域边界演练与 Go / No-Go

建立 CN-test 和 Global-test 两套隔离环境：

• 不同数据库。
• 不同对象存储。
• 不同 vector endpoint。
• 不同 AI endpoint allowlist。
• 不同密钥。
• 相同代码版本和 schema。

演练：

1. CN tenant 的 synthetic lead 只能进入 CN-test。
2. Global tenant 的 synthetic lead 只能进入 Global-test。
3. HK catalogue projection 可经批准发布到 CN-test。
4. CN raw lead、message、recording、embedding 不得出现在 Global-test。
5. 只导出聚合评测指标到 method control layer。

Go / No-Go 最低标准：

Go / No-Go 应按任务拆分：Qwen3-14B 是否适合结构化抽取，与它是否适合中英双语销售语气是两个结论。结构化抽取失败可阻止首轮接入；draft 质量不足时可继续保持 human-review 辅助模式，不能因此否定整个部署可行性。

7. Phase 1：PropertyLab 内部区域大脑与飞轮

建议周期：6-10 周。

7.1 数据接入

第一批：

• lead profile 和 enrichment。
• WhatsApp 对话。
• Call / F2F / Zoom transcript 和 analysis。
• engagement、appointment 和 booking。
• working project 和已发布 catalogue facts。
• 经批准的内部销售 SOP。

第二批：

• portal 行为。
• campaign 和广告触点。
• 智能工牌/带看现场信号。
• 财富规划和 property analysis。

7.2 RAG 管道

1. 定义每类 document 的 owner、region、retention 和 permission。
2. 只从区域内 source database 或 object storage 读取。
3. 清洗、分段并删除不需要进入检索的敏感字段。
4. 在所属区域生成 embedding。
5. 写入区域 vector store。
6. payload 至少保存 region、lead、group/tenant、document type、source id、permission 和 version。
7. 查询时先做权限 filter，再做向量检索。
8. 返回结果必须保留 source citation。
9. 数据删除或权限改变时同步删除/重建向量。
10. 对 prompt injection 文档做隔离、标记和测试。

7.3 采纳传感器

以 WhatsApp draft 为第一条完整链路：

1. AI 生成 recommendation。
2. UI 展示时记录 shown。
3. Use 记录 accepted，不能再与 Dismiss 共用同一个无语义 API。
4. 如果经纪修改文字，记录 edited 和差异指标，不保存不必要的敏感副本。
5. 真正发送后记录 sent 和 outbound message id。
6. Dismiss 记录 dismissed。
7. 超时未处理记录 expired。

7.4 结果回填

1. 将 appointment、engagement status、booking、SPA、won/lost 作为结果事件。
2. 以 lead × project 的 engagement 为主要业务关联。
3. 定义 attribution window，避免把很久以后的结果强行归因给一次建议。
4. 记录没有采纳建议的对照组。
5. 按语言、市场、团队、任务类型和 model version 分层评测。

7.5 Phase 1 输出

• 内部 AI Brain 可用版本。
• 区域 RAG 和删除/权限同步。
• recommendation / adoption / outcome 数据链。
• 技术质量 dashboard。
• adoption、conversion 和 uplift dashboard。
• 至少一个内部 case study。
• 本地 GPU 采购 Go / No-Go 报告。

8. Phase 2：外部客户与 CN / Global 正式部署

8.1 推荐交付模式

8.2 中国区域正式上线前置条件

1. 确认中国云、网络、域名、备案和合同主体要求。
2. 由合规/法律顾问确认 PIPL、数据出境和录音处理要求。
3. 选择中国区域可用且满足客户政策的模型或 GPU 服务。
4. 完成企微等中国渠道适配器。
5. 建立 CN object storage、vector store、backup、KMS 和 monitoring。
6. 建立对 Global endpoint 的 egress deny / allowlist。
7. 完成 aggregate export 审批和审计。

8.3 中国中介销售香港房产 pilot

建议 demo 流程：

1. 在 Global catalogue 中维护 HK canonical project。
2. 将获授权、可销售的 HK catalogue projection 发布到 CN。
3. 中国经纪通过中国端 CRM / 企微触达客户。
4. Worker 在 CN 分析消息、通话和会议。
5. CN Orchestrator 给出楼盘匹配、异议处理和 Next Best Action。
6. 经纪采纳、编辑或拒绝建议。
7. appointment、booking 和 lost reason 留在 CN。
8. 只把达到门槛的匿名聚合结果用于方法论复盘。

8.4 外部 pilot 实施步骤

1. Data Processing / Security Discovery。
2. 数据清单和区域分类。
3. 选择 2-3 个高价值 use case。
4. 部署独立环境。
5. 配置 channel adapters 和 SSO / roles。
6. 导入获批知识和 catalogue。
7. shadow mode 测试。
8. human-in-the-loop pilot。
9. adoption / outcome evaluation。
10. 上线评审、SLA 和 support handover。

9. 模型与 GPU 策略

9.1 模型分层

9.2 云 GPU 起步

Phase 0 的参考组合是阿里云国际站吉隆坡 ecs.gn8is.2xlarge + L20 48GB + Qwen3-14B BF16；若实时库存不支持，则按顺序评估新加坡同规格，以及 A10 24GB + Qwen3-14B AWQ。阿里云官方说明 gn8is 只在部分地域 / 可用区提供，因此本方案不承诺固定地域一定有货。

POC 不追求一次选出“最终模型”。Qwen3-14B 先证明 structured extraction、JSON schema 和成本；销售语气、复杂双语 draft 继续与现有 frontier provider 对照。若内部模型输出需要较多人工改写，但没有高风险承诺且能节省分析时间，可以定义为 Conditional Go。

记录：

• model revision。
• quantization。
• context length。
• max concurrency。
• tokens/second。
• P50 / P95 latency。
• GPU utilization / memory。
• 每任务成本。

9.3 何时购买本地硬件

同时满足以下条件再采购：

• Phase 0 和 Phase 1 达标。
• 有稳定日均 token 和并发数据。
• 12-24 个月 TCO 明显优于云。
• 有机房、电力、散热、网络、备份和运维人员。
• 本地部署是客户合同或合规要求，而不是展示性采购。

10. 评测体系

10.1 离线质量

• JSON/schema validity。
• 人工事实准确率。
• hallucination rate。
• evidence coverage。
• 多语言质量。
• 安全违规率。
• 与当前 provider 的 blind comparison。
• structured extraction 的字段级 precision / recall / F1。
• WhatsApp draft 的 edit distance / edit rate 和高风险承诺数；不把单一主观总分当成唯一门槛。

10.2 在线技术指标

• request success / failure。
• queue wait。
• first-token / total latency。
• input / output token。
• cost per task。
• GPU utilization。
• fallback rate。
• region routing violations。

10.3 业务飞轮指标

• recommendation shown rate。
• adoption rate。
• edit rate。
• sent / executed rate。
• appointment rate。
• booking / SPA / won rate。
• lost / cancellation reason。
• 采纳组与未采纳组的 uplift。

不能只用静态“答案好不好”证明商业价值。真正的北极星指标是：在可解释的对照下，使用建议是否提高有效业务结果。

11. 安全与合规

• 所有 endpoint 使用 private network、TLS、service authentication 和 allowlist。
• API key 继续使用 petaV3 encrypted credential 机制。
• 原始消息、录音、文件、embedding、prompt log 和模型输出都按敏感数据处理。
• ai_requests.response_raw 和 request body 需要 retention、redaction 和最小权限。
• 管理员能看到 AI log 不代表所有员工都能看到。
• RAG 必须先授权过滤，再检索。
• 每个区域独立 backup、KMS、incident log 和 restore test。
• 禁止开发人员用真实客户数据测试个人 AI 账号。
• 方法包与 aggregate export 要签名、版本化和审计。
• 法律和合规结论必须由专业顾问确认，本计划不是法律意见。

12. 运维设计

12.1 服务组件

每个区域至少包括：

• petaV3 application / API。
• web and queue workers。
• operational database。
• Redis / queue。
• private object storage。
• vector store。
• model gateway / vLLM or approved provider。
• monitoring、centralized logs 和 alerting。

12.2 故障策略

• internal model 不可用时，CN 不得自动 fallback 到 Global provider。
• Global 是否 fallback 到外部 provider 由 prompt policy 决定。
• interactive chat 可 fail soft。
• queue job 使用现有 retry / breaker。
• recommendation 失败不得阻断 CRM 核心流程。
• 自动客户消息默认关闭，直到单独批准。

12.3 发布

1. 同一 commit 构建区域 image。
2. 使用区域独立配置和 secrets。
3. 先部署 shadow / canary。
4. 跑 region boundary tests。
5. 跑 prompt regression suite。
6. 检查 schema / model compatibility。
7. 才放行 production traffic。

13. 商业化方案

13.1 可售卖内容

• AI readiness assessment。
• 私有 Real Estate AI Engine 部署。
• channel / CRM integration。
• RAG knowledge setup。
• sales conversation intelligence。
• Next Best Action 和 agent copilot。
• AI governance、audit 和 evaluation dashboard。
• managed model / GPU operations。
• quarterly method package update。

13.2 收费结构

不建议在没有可靠 uplift 数据时直接承诺纯效果付费。可以在 pilot 后增加有上限、有明确定义的 performance component。

14. 团队与责任

15. 时间线

Phase 0 设置 500 美元云支出硬上限，但这不是月度长期报价。预算应按创建实例当日的阿里云 calculator / order 页面、模型选择、运行时长、磁盘、快照、EIP 和流量重新测算；工程与标注人工成本必须单独报告。

16. 主要风险与应对

17. 近期行动清单

本周

1. 确认 v2.1 架构、两个区域定义，以及吉隆坡仅属于 Global 的边界。
2. 完成 AI Data Readiness Audit。
3. 选择 3 个 POC 任务、gold dataset owner 和业务结果标签 owner。
4. 建立 internal_ai provider 技术 ticket。
5. 定义 recommendation / event / outcome schema。
6. 建立阿里云公司账号、RAM 最小权限、500 美元预算与告警。
7. 获取吉隆坡 L20 和备选规格的实时库存 / 报价证据。
8. 确认 CN pilot 的目标渠道是企微、电话、会议中的哪些。

两周内

1. 启动云 GPU 和 vLLM。
2. 完成 petaV3 provider 接入和测试。
3. 跑 conversation analysis 基线对比。
4. 建立 CN-test / Global-test 边界测试。
5. 输出第一版成本、延迟、质量报告。

一个月内

1. 完成 Worker → Orchestrator POC。
2. 完成双区域数据泄漏测试。
3. 做 Go / No-Go review。
4. 确定 Phase 1 RAG 和飞轮 implementation backlog。
5. 准备中国中介销售香港房产的 demo 脚本。

18. 最终结论

petaV3 已经拥有比 v1.0 proposal 假设更成熟的 AI gateway、prompt 管理、审计、队列韧性、多国家 catalogue 和销售结果数据。因此 Phase 0 不需要重新设计 AI 基础调用层，重点应是正式注册 internal_ai、部署云 GPU、建立区域边界，并验证一个 Worker 到 Orchestrator 的闭环。

真正的护城河也不是“我们有一个本地模型”，而是：

• 房地产专属数据 contract。
• 区域内的多触点 Worker。
• 可审计的 Next Best Action。
• 建议采纳与业务结果 Join。
• CN / Global 原始数据隔离。
• 可版本化、可下发、可验证的方法论。

19. 官方参考资料

• 阿里云地域代码：Malaysia (Kuala Lumpur) ap-southeast-3，Singapore ap-southeast-1：https://www.alibabacloud.com/help/en/user-center/developer-reference/common-region-id-reference
• 阿里云 GPU 实例族，含 gn8is / L20 48GB 规格与地域可用性说明：https://www.alibabacloud.com/help/en/ecs/user-guide/gpu-accelerated-compute-optimized-and-vgpu-accelerated-instance-families-1
• 阿里云 ECS 节省停机模式、计费边界和 StopInstance 要求：https://www.alibabacloud.com/help/en/ecs/user-guide/economical-mode
• vLLM OpenAI-compatible server 与 API key：https://docs.vllm.ai/en/latest/serving/online_serving/openai_compatible_server/
• vLLM 官方 Docker 部署说明：https://docs.vllm.ai/en/latest/deployment/docker/

云 GPU 只是验证工具；Real Estate AI Engine、数据飞轮和可复制的私有化交付能力才是最终产品。