把选型拆成可核对的问题
「要不要自建」这个问法太笼统，容易变成立场之争。更有效的做法是拆成六个能查证的问题：数据能否出域、并发峰值多大、延迟要求多严、模型是否需要可控、团队能否值班、预算偏一次性投入还是按量付费。六项里只要有一项是硬约束，选型方向基本就定了，剩下的才是成本精算。
取舍核对表
| 维度 | 云 API 更合适 | 私有化更合适 |
|---|---|---|
| 数据合规 | 无敏感数据，可接受出域 | 数据不能出域或需留存境内 |
| 用量规模 | 用量小或波动大 | 长期稳定的大用量 |
| 延迟要求 | 可接受公网往返延迟 | 内网低延迟、链路可控 |
| 模型定制 | 现成商用模型即可 | 需微调、自有权重或指定量化 |
| 运维能力 | 无专职 GPU 运维 | 有值班与硬件排障能力 |
| 预算形态 | 按量付费，跟随业务波动 | 一次性采购，按折旧摊算 |
自建侧的隐藏成本
| 人力 | GPU 运维、驱动升级、故障值班都算成本，不只是电费 |
|---|---|
| 利用率 | 业务有波谷，闲时算力仍在折旧，利用率低于一半时单位成本偏高 |
| 配套 | 机柜、带宽、备份与监控系统都要补齐 |
| 迁移成本 | 提示词模板与采样参数在两侧不通用，迁移需要回归 |
选型要做的验证动作
- 在目标并发与上下文长度下压测，而不是只看单请求演示效果
- 用真实业务提示词做对照，比较输出风格与稳定性是否可接受
- 测算平衡点：按当前用量与增长速度估算自建成本的覆盖门槛
- 确认权重许可允许商用，并核对量化版本的授权限制
- 验证混合方案可行性：网关能否在不改业务代码的前提下切换出口
验证网络延迟
验证网络延迟
# 连通性与往返延迟
ping api.openai.com
# 连接建立与总耗时分解，观察是否长期偏高
curl -o /dev/null -s -w 'connect=%{time_connect}s total=%{time_total}s\n' https://api.openai.com/v1/models
# 自建侧同样的口径测一次，比较两者差距采样参数的默认值在云端与本地实现之间可能不同：迁移之后需要回归对比输出质量，特别是抽取、分类这类对稳定性敏感的功能。
把演示效果当作选型依据风险很高：演示通常在低并发、短上下文下进行，而线上是另一回事，要在真实形状下测。