AI 创业公司选择云平台时，已经不再只比较“能不能调用大模型”。真正影响产品毛利、交付速度和扩展能力的，是整套技术栈能否同时解决三件事：按任务选择模型、灵活调度 GPU 与 TPU，以及把智能体、数据、存储、安全和运行平台连接起来。
Google Cloud 近期披露的创业公司案例覆盖游戏、医疗、网络安全、代码审查、生成式媒体、机器人和金融分析。虽然这些案例带有平台方视角，但它们呈现出的架构趋势值得关注：AI 产品很少依靠一个模型或一种芯片完成所有工作，竞争正在从“接入模型”转向“编排完整系统”。
需求一：不是寻找最强模型，而是建立模型路由
推理能力、延迟和成本通常不能同时达到最优。医疗行政流程、代码审查和安全测试都可能包含不同等级的任务：
- 长时间、多步骤的规划需要更强的推理模型；
- 分类、摘要、字段提取适合低延迟模型；
- 图像、视频或语音工作流需要专门的多模态模型；
- 高并发在线请求还要考虑吞吐保障和单位请求成本。
来源中的多个案例都采用了类似思路：使用能力更强的模型处理复杂任务，再让快速模型承担边界清晰的子任务。这比把所有请求发送给旗舰模型更容易控制成本，也减少了高峰期的延迟压力。
模型路由不应散落在业务代码的多个 if 语句里。更稳妥的做法是建立统一路由层，并记录以下数据：
| 维度 | 建议记录的指标 |
|---|---|
| 质量 | 任务成功率、人工接受率、结构化输出通过率 |
| 性能 | 首 token 延迟、总响应时间、超时率 |
| 成本 | 单请求成本、每个成功任务的成本 |
| 稳定性 | 限流次数、重试次数、模型版本变化 |
可以这样实践：用任务等级选择 Gemini 模型
下面是一个可运行的最小示例。运行前需要安装 Google Gen AI SDK、完成应用默认身份认证，并把项目 ID、区域及模型名称换成当前账号可用的值。
python -m venv .venv
source .venv/bin/activate
pip install google-genai
gcloud auth application-default login
export GOOGLE_CLOUD_PROJECT="your-project-id"
export GOOGLE_CLOUD_LOCATION="global"
export GOOGLE_GENAI_USE_VERTEXAI="true"
export MODEL_FAST="gemini-2.0-flash"
export MODEL_DEEP="gemini-2.5-pro"
保存为 router.py：
import os
import sys
from google import genai
client = genai.Client()
MODELS = {
"fast": os.environ["MODEL_FAST"],
"deep": os.environ["MODEL_DEEP"],
}
def choose_tier(prompt: str) -> str:
complex_markers = ("比较", "规划", "根因", "权衡", "多步骤")
if len(prompt) > 500 or any(word in prompt for word in complex_markers):
return "deep"
return "fast"
def generate(prompt: str) -> str:
tier = choose_tier(prompt)
model = MODELS[tier]
response = client.models.generate_content(
model=model,
contents=prompt,
)
print(f"tier={tier} model={model}", file=sys.stderr)
return response.text
if __name__ == "__main__":
prompt = " ".join(sys.argv[1:]) or "用三句话总结模型路由的价值"
print(generate(prompt))
执行：
python router.py "比较两种智能体记忆架构，并说明成本、延迟与一致性的权衡"
这只是起点。生产环境中，路由依据应来自离线评测和线上指标，而不是简单关键词；同时还需要设置最大 token 数、超时、重试、内容安全策略和备用模型。
需求二：GPU 与 TPU 是资源池，而不是架构中心
训练、后训练和在线推理对硬件的要求不同。GPU 生态成熟，适合大量现有框架和自定义模型；TPU 则可以在适配的训练及推理负载中提供另一种价格性能选择。Google Cloud 强调其平台能够同时提供两类加速器，这对需要训练自有模型、运行多模态工作负载或处理物理 AI 的团队尤其重要。
但案例透露出的重点并不是“选哪一种芯片”，而是计算资源必须与其他服务共同工作。例如：
- 训练数据和检查点放在对象存储中；
- 批量特征、日志和评测结果进入 BigQuery；
- 稳定的容器工作负载运行在 GKE；
- 突发式 API 或后台任务运行在 Cloud Run；
- 模型端点需要配额、吞吐、监控和访问控制。
因此，早期团队不应过早把系统绑定到特定加速器。可以优先容器化训练和推理程序，把数据路径、模型版本和硬件规格放进配置，并持续测量“每个成功任务的总成本”，而不是只看芯片小时单价。
需求三：智能体真正依赖的是外围系统
智能体演示通常只展示一次漂亮的模型调用，生产系统却必须处理身份、状态、工具权限和失败恢复。来源中提到的医疗智能体会跨越排班、入职、合规、语音、短信和邮件；安全智能体需要执行长时间、多步骤任务；代码审查产品则必须理解一次改动对整个代码库的影响。
这些工作负载至少需要四层能力：
- 模型层：为规划、执行和多模态理解选择不同模型。
- 智能体层：管理工具调用、会话状态、任务拆分和人工审批。
- 数据层：连接对象存储、分析仓库、业务数据库与检索系统。
- 治理层：实施最小权限、审计、密钥管理、内容过滤和成本配额。
这解释了为什么创业公司在采用模型或加速器后，往往还会使用 Storage、BigQuery、GKE 或 Cloud Run。单独采购算力只能解决“程序在哪里运行”，无法回答“智能体能访问什么、如何恢复、怎样审计”。
落地时避免把“完整平台”变成“完整锁定”
平台整合可以降低早期工程成本，但也可能扩大迁移难度。建议在采用前完成以下检查：
- 为每类任务维护至少一个可替换模型，并建立固定评测集；
- 将模型调用封装在内部接口后面，避免业务代码直接依赖供应商响应格式；
- 分别核算模型 token、加速器、存储、网络和数据分析成本；
- 明确敏感数据能否进入模型上下文，以及日志需要保留多久；
- 为智能体工具设置最小权限、金额上限和人工确认点；
- 压测配额、冷启动、区域故障和模型限流场景；
- 对 GPU 与 TPU 使用真实工作负载基准测试，而不是只比较理论参数。
对 AI 创业公司而言，最有价值的技术栈不是组件最多的平台，而是能让团队持续替换模型、调度计算资源，并安全连接业务数据的平台。模型会快速更新，芯片供应也会变化；真正需要稳定下来的，是评测体系、路由策略、数据边界和运行治理。