从零搭建 AI 中台一个百人团队的真实踩坑记录基础设施不需要漂亮话。过去 8 个月我参与了一个百人规模的 AI 中台搭建项目从零开始到最终支持 20 业务线调用。过程中踩了大量坑有些是技术债有些是组织架构问题还有些是纯粹的选型失误。这篇文章记录的是真实踩坑过程不是方法论不是最佳实践就是一份故障复盘。一、背景为什么要建 AI 中台2024 年底公司内部 AI 需求爆发。最开始是三个业务线各自接入大模型 API很快变成十个、二十个。问题逐层暴露成本失控每个业务线各自采购 API没有集中采购单价高月度账单从 5 万涨到 80 万。重复建设每个团队都在写自己的 Prompt 管理、调用封装、结果缓存代码重复率极高。合规风险部分业务线直接把用户数据发给第三方 API安全团队介入后叫停了 6 个项目。性能瓶颈高峰期并发请求打爆了单实例部署的模型服务多个业务线互相影响。技术委员会讨论后决定建一个统一的 AI 中台提供模型接入、推理服务、Prompt 管理、成本控制、安全审计五项核心能力。决策很快执行很难。二、架构选型我们为什么没选托管方案初期有三个方案全托管Azure OpenAI Vertex AI半托管K8s 开源模型混合架构托管 API 自建推理集群最终选了方案 3原因是成本和安全合规双重约束。混合架构的核心设计踩坑 1网关成了单点瓶颈最初版本用 Go 写了一个简单网关负责 API Key 管理、请求路由、限流。上线第一周就出问题QPS 到 2000 时延迟从 50ms 飙到 800ms。排查发现是连接池配置问题。标准库http.Client默认MaxConnsPerHost无限速但我们的网关还加了业务层限流导致大量请求排队。改成分层限流连接级 请求级后解决但这个过程花了 3 天期间多个业务线投诉。教训网关层的性能测试必须在真实流量下做压测环境的 QPS 要按峰值的 3 倍设计。三、模型接入统一接口比想象中难AI 中台的核心价值之一是统一接口。业务方只需要调用一个 API中台负责背后路由到不同的模型提供商。理想很丰满现实很骨感。各家 API 的接口规范差异比预期大维度OpenAIClaude文心一言自建 Llama认证方式Bearer Tokenx-api-keyAPI Key Secret内部 IAM流式响应SSESSE自定义协议自定义错误码HTTP 状态码自定义 JSON自定义 JSON自定义计费维度TokenToken调用次数不计费我们花了一个月写适配器层最终定义了内部统一接口规范。但代价是Adapter 代码量比核心网关还多而且每次第三方 API 升级都要跟进适配。踩坑 2适配层变成了维护地狱第 3 个月Claude API 升级到 3.0接口规范大改。我们的适配器层没有做好版本管理导致线上服务中断 2 小时。之后重构了适配器架构引入版本化 Adapter 管理type ModelAdapter interface { Chat(ctx context.Context, req *ChatRequest) (*ChatResponse, error) Embedding(ctx context.Context, req *EmbedRequest) (*EmbedResponse, error) Version() string } var adapterRegistry map[string]map[string]ModelAdapter{ claude: { 2.0: ClaudeV2Adapter{}, 3.0: ClaudeV3Adapter{}, }, }四、成本控制从账单失控到精确到部门成本控制是 AI 中台的核心价值但也是最难做好的部分。我们最初的成本统计很粗糙每天拉一次各提供商的账单 CSV人工汇总。这种方式的问题是延迟高、精度低等业务方发现成本超支钱已经花出去了。最终方案是实时计费 预算告警踩坑 3实时计费的性能开销最初版本是同步计费每次推理完成后网关同步调用计费模块写入数据库。这导致 P99 延迟增加了 120ms。优化方案是把计费改成异步网关只做轻量级计数基于 Token 预估详细计费交给后台 Worker 批量处理。最终精度损失在 5% 以内但延迟问题彻底解决。五、总结如果重来一次8 个月上线20 业务线接入月度 AI 成本从 80 万降到 45 万。数字看起来不错但过程中有些决策如果重来我会做得不一样尽早引入 Kafka 做异步解耦初期为了简单用了 HTTP 直调后期重构成本高。网关层必须用成熟方案自研网关踩的坑用 Envoy 自研插件可以避免。成本控制要从 Day 1 做起后期接入成本系统比从零搭建还难因为要补历史数据。适配器层必须版本化管理这是血泪教训API 升级是常态不是例外。AI 中台不是银弹。它解决的是规模化问题但引入的复杂度需要团队有能力消化。如果你们团队规模小于 50 人我建议先用好托管方案等规模上来了再考虑自建。基础设施不需要漂亮话能用、稳定、成本低就是好方案。
从零搭建 AI 中台一个百人团队的真实踩坑记录基础设施不需要漂亮话。过去 8 个月我参与了一个百人规模的 AI 中台搭建项目从零开始到最终支持 20 业务线调用。过程中踩了大量坑有些是技术债有些是组织架构问题还有些是纯粹的选型失误。这篇文章记录的是真实踩坑过程不是方法论不是最佳实践就是一份故障复盘。一、背景为什么要建 AI 中台2024 年底公司内部 AI 需求爆发。最开始是三个业务线各自接入大模型 API很快变成十个、二十个。问题逐层暴露成本失控每个业务线各自采购 API没有集中采购单价高月度账单从 5 万涨到 80 万。重复建设每个团队都在写自己的 Prompt 管理、调用封装、结果缓存代码重复率极高。合规风险部分业务线直接把用户数据发给第三方 API安全团队介入后叫停了 6 个项目。性能瓶颈高峰期并发请求打爆了单实例部署的模型服务多个业务线互相影响。技术委员会讨论后决定建一个统一的 AI 中台提供模型接入、推理服务、Prompt 管理、成本控制、安全审计五项核心能力。决策很快执行很难。二、架构选型我们为什么没选托管方案初期有三个方案全托管Azure OpenAI Vertex AI半托管K8s 开源模型混合架构托管 API 自建推理集群最终选了方案 3原因是成本和安全合规双重约束。混合架构的核心设计踩坑 1网关成了单点瓶颈最初版本用 Go 写了一个简单网关负责 API Key 管理、请求路由、限流。上线第一周就出问题QPS 到 2000 时延迟从 50ms 飙到 800ms。排查发现是连接池配置问题。标准库http.Client默认MaxConnsPerHost无限速但我们的网关还加了业务层限流导致大量请求排队。改成分层限流连接级 请求级后解决但这个过程花了 3 天期间多个业务线投诉。教训网关层的性能测试必须在真实流量下做压测环境的 QPS 要按峰值的 3 倍设计。三、模型接入统一接口比想象中难AI 中台的核心价值之一是统一接口。业务方只需要调用一个 API中台负责背后路由到不同的模型提供商。理想很丰满现实很骨感。各家 API 的接口规范差异比预期大维度OpenAIClaude文心一言自建 Llama认证方式Bearer Tokenx-api-keyAPI Key Secret内部 IAM流式响应SSESSE自定义协议自定义错误码HTTP 状态码自定义 JSON自定义 JSON自定义计费维度TokenToken调用次数不计费我们花了一个月写适配器层最终定义了内部统一接口规范。但代价是Adapter 代码量比核心网关还多而且每次第三方 API 升级都要跟进适配。踩坑 2适配层变成了维护地狱第 3 个月Claude API 升级到 3.0接口规范大改。我们的适配器层没有做好版本管理导致线上服务中断 2 小时。之后重构了适配器架构引入版本化 Adapter 管理type ModelAdapter interface { Chat(ctx context.Context, req *ChatRequest) (*ChatResponse, error) Embedding(ctx context.Context, req *EmbedRequest) (*EmbedResponse, error) Version() string } var adapterRegistry map[string]map[string]ModelAdapter{ claude: { 2.0: ClaudeV2Adapter{}, 3.0: ClaudeV3Adapter{}, }, }四、成本控制从账单失控到精确到部门成本控制是 AI 中台的核心价值但也是最难做好的部分。我们最初的成本统计很粗糙每天拉一次各提供商的账单 CSV人工汇总。这种方式的问题是延迟高、精度低等业务方发现成本超支钱已经花出去了。最终方案是实时计费 预算告警踩坑 3实时计费的性能开销最初版本是同步计费每次推理完成后网关同步调用计费模块写入数据库。这导致 P99 延迟增加了 120ms。优化方案是把计费改成异步网关只做轻量级计数基于 Token 预估详细计费交给后台 Worker 批量处理。最终精度损失在 5% 以内但延迟问题彻底解决。五、总结如果重来一次8 个月上线20 业务线接入月度 AI 成本从 80 万降到 45 万。数字看起来不错但过程中有些决策如果重来我会做得不一样尽早引入 Kafka 做异步解耦初期为了简单用了 HTTP 直调后期重构成本高。网关层必须用成熟方案自研网关踩的坑用 Envoy 自研插件可以避免。成本控制要从 Day 1 做起后期接入成本系统比从零搭建还难因为要补历史数据。适配器层必须版本化管理这是血泪教训API 升级是常态不是例外。AI 中台不是银弹。它解决的是规模化问题但引入的复杂度需要团队有能力消化。如果你们团队规模小于 50 人我建议先用好托管方案等规模上来了再考虑自建。基础设施不需要漂亮话能用、稳定、成本低就是好方案。
![【光照】Unity[经验模型]和[物理模型]](http://pic.xiahunao.cn/yaotu/【光照】Unity[经验模型]和[物理模型])
双梁正问题 【 torch 实战】（Python代码实现）)
