跳至主要內容

第1656篇：Serverless架构下的AI函数——冷启动挑战与预热策略

老张2026/4/30大约 11 分钟

第1656篇：Serverless架构下的AI函数——冷启动挑战与预热策略

去年做一个内部智能问答工具，需求很简单：员工提问，AI回答，日均调用量大概几百次，高峰在工作日上午。

最开始的方案是用AWS Lambda包一个调用OpenAI的函数，部署简单，不用管服务器，也不用操心弹性扩缩容。看起来很美好。

上线第一天，就有同事反映："怎么有时候问一下要等好久？"

这就是Serverless AI函数绕不过去的坑：冷启动。那天花了整个下午研究，发现冷启动在AI场景里远比普通Web函数复杂。这篇文章把我的研究和解法都写出来。

冷启动是什么，为什么AI场景更严重

Serverless的运行逻辑是：当有请求进来时，平台创建一个容器实例来处理这个请求；如果一段时间没有请求（通常是几分钟到十几分钟），这个实例会被销毁。

下次有请求进来，如果没有现成的实例，就需要重新创建——这个创建过程就是"冷启动"，会增加额外的延迟。

普通Lambda函数（Node.js或Python的轻量函数）冷启动可能只需要100-500ms，用户感知不明显。但AI函数不一样：

模型加载时间。即使不在Lambda里加载本地模型（直接调OpenAI），Java运行时的初始化、Spring上下文的启动也要几秒甚至十几秒。如果Lambda是Python + HuggingFace模型，冷启动轻松10秒+。

大内存配置导致启动慢。AI函数通常需要配置大内存（Lambda最大10GB），大内存实例的分配本身就比小实例慢。

依赖包体积大。Lambda的部署包如果包含PyTorch等大型库，光是加载这些库就要几秒。

VPC网络初始化。如果Lambda需要访问VPC内的资源（向量数据库、私有模型服务），VPC配置会增加额外的冷启动时间（AWS Lambda的VPC冷启动历史上是个大坑，虽然现在好多了）。

先量化你的冷启动问题

在想解法之前，先搞清楚冷启动频率和时间。盲目优化是浪费。

在Java Lambda里测量冷启动时间

public class AiInferenceLambda implements RequestHandler<APIGatewayProxyRequestEvent,
                                                           APIGatewayProxyResponseEvent> {

    private static final long COLD_START_TIME = System.currentTimeMillis();
    private static boolean isColdStart = true;  // static变量，容器内只初始化一次
    private static long instanceCreatedAt;

    // 静态初始化块：只在冷启动时执行一次
    static {
        instanceCreatedAt = System.currentTimeMillis();
        System.out.println("COLD_START: 实例初始化时间=" + instanceCreatedAt);

        // 初始化OpenAI客户端（重用实例，避免每次请求都创建）
        initOpenAIClient();
    }

    @Override
    public APIGatewayProxyResponseEvent handleRequest(
            APIGatewayProxyRequestEvent input, Context context) {

        long requestStartTime = System.currentTimeMillis();

        if (isColdStart) {
            long coldStartLatency = requestStartTime - instanceCreatedAt;
            // 记录冷启动指标
            emitMetric("lambda.cold_start_latency", coldStartLatency);
            emitMetric("lambda.cold_start", 1.0);
            System.out.println("COLD_START: 冷启动延迟=" + coldStartLatency + "ms");
            isColdStart = false;
        } else {
            emitMetric("lambda.warm_start", 1.0);
        }

        // 处理请求
        try {
            String response = processAiRequest(input.getBody());
            return buildSuccessResponse(response);
        } catch (Exception e) {
            return buildErrorResponse(e.getMessage());
        }
    }

    private void emitMetric(String metricName, double value) {
        // 通过CloudWatch Embedded Metrics Format上报
        System.out.println(String.format(
            "{\"_aws\":{\"Timestamp\":%d,\"CloudWatchMetrics\":[{" +
            "\"Namespace\":\"AiLambda\",\"Dimensions\":[[\"FunctionName\"]]," +
            "\"Metrics\":[{\"Name\":\"%s\",\"Unit\":\"Milliseconds\"}]}]}," +
            "\"FunctionName\":\"%s\",\"%s\":%f}",
            System.currentTimeMillis(),
            metricName,
            System.getenv("AWS_LAMBDA_FUNCTION_NAME"),
            metricName, value
        ));
    }
}

跑一段时间，统计冷启动频率（冷启动占总请求的比例）和冷启动时间（P50、P99）。如果冷启动比例低于5%，P99冷启动时间在3秒以内，其实影响不大，不用过度优化。

解法一：预热（Provisioned Concurrency）

最直接的方案是用云厂商提供的"预留并发"（AWS叫Provisioned Concurrency，Google Cloud Functions叫Min Instances）。

预留并发的原理是：让平台保持指定数量的函数实例始终处于热状态，当请求来时直接使用这些实例，不需要冷启动。

AWS Lambda的配置：

# 设置函数别名
aws lambda create-alias \
  --function-name ai-inference \
  --name prod \
  --function-version 5

# 给别名配置2个预留并发实例
aws lambda put-provisioned-concurrency-config \
  --function-name ai-inference \
  --qualifier prod \
  --provisioned-concurrent-executions 2

对应的Java代码需要利用好预热初始化机制：

public class AiInferenceLambda implements RequestHandler<Map<String, Object>,
                                                          Map<String, Object>> {

    // 在预留并发下，这些静态对象会被预先初始化好
    private static final OpenAIClient openAIClient;
    private static final VectorStoreClient vectorStoreClient;
    private static final EmbeddingCache embeddingCache;

    static {
        System.out.println("开始初始化AI组件...");
        long start = System.currentTimeMillis();

        // 初始化OpenAI客户端
        openAIClient = OpenAIClient.builder()
            .apiKey(System.getenv("OPENAI_API_KEY"))
            .connectionTimeout(Duration.ofSeconds(5))
            .readTimeout(Duration.ofSeconds(120))
            .build();

        // 初始化向量库连接（建立TCP连接池）
        vectorStoreClient = VectorStoreClient.connect(
            System.getenv("VECTOR_DB_HOST"),
            Integer.parseInt(System.getenv("VECTOR_DB_PORT"))
        );

        // 预热嵌入缓存
        embeddingCache = new EmbeddingCache(1000);

        System.out.println("AI组件初始化完成，耗时: " +
            (System.currentTimeMillis() - start) + "ms");
    }

    @Override
    public Map<String, Object> handleRequest(Map<String, Object> event, Context context) {
        // 处理请求，openAIClient等已经初始化好
        String question = (String) event.get("question");
        String answer = generateAnswer(question);
        return Map.of("answer", answer, "model", "gpt-4");
    }
}

预留并发的代价：钱。预留并发不管有没有请求，都一直计费。2个实例24小时不间断，费用不低。需要权衡冷启动体验和成本。

按时间段动态调整预留并发

前面说了，内部问答工具的使用高峰是工作日上午。那么在高峰期才开启预留并发，其他时间关掉，就能在成本和体验之间找到平衡。

用EventBridge定时调整：

# CloudFormation / Serverless Framework配置
Events:
  # 工作日早上8:30开启预留并发
  ScaleUpMorning:
    Type: Schedule
    Properties:
      Schedule: cron(30 0 ? * MON-FRI *)    # UTC 00:30 = 北京时间 08:30
      Input: '{"action": "scale_up", "count": 5}'

  # 工作日晚上7点关闭预留并发
  ScaleDownEvening:
    Type: Schedule
    Properties:
      Schedule: cron(0 11 ? * MON-FRI *)    # UTC 11:00 = 北京时间 19:00
      Input: '{"action": "scale_down", "count": 0}'

对应的Lambda处理函数：

import boto3

def scale_handler(event, context):
    lambda_client = boto3.client('lambda')
    action = event['action']
    count = event['count']

    if action == 'scale_up':
        lambda_client.put_provisioned_concurrency_config(
            FunctionName='ai-inference',
            Qualifier='prod',
            ProvisionedConcurrentExecutions=count
        )
        print(f"已设置预留并发: {count}")
    elif action == 'scale_down':
        lambda_client.delete_provisioned_concurrency_config(
            FunctionName='ai-inference',
            Qualifier='prod'
        )
        print("已关闭预留并发")

解法二：定时Ping，保持实例热状态

比预留并发便宜很多的方案是用定时请求轮询来防止实例被回收。

Lambda通常在15-20分钟无请求后才会回收实例。所以每10分钟发一个"心跳请求"，就能让实例保持热状态。

# 每10分钟触发一次keep-alive ping
Events:
  WarmingPing:
    Type: Schedule
    Properties:
      Schedule: rate(10 minutes)
      Input: '{"source": "warming-ping", "action": "ping"}'

Java Lambda处理ping请求：

@Override
public Map<String, Object> handleRequest(Map<String, Object> event, Context context) {
    // 识别心跳请求，快速返回
    String source = (String) event.get("source");
    if ("warming-ping".equals(source)) {
        System.out.println("收到心跳Ping，实例保持热状态");
        // 可以顺便做一些轻量的预热操作
        performLightWarmup();
        return Map.of("status", "warm", "timestamp", System.currentTimeMillis());
    }

    // 正常业务请求处理
    return handleBusinessRequest(event);
}

private void performLightWarmup() {
    // 可以做一些轻量的预热：
    // 1. 刷新Token（如果有过期的认证Token）
    // 2. 检查连接池状态
    // 3. 清理一些过期缓存
    vectorStoreClient.ping();
}

定时Ping的局限是：它只能维持当前已有的实例，不能保证特定数量的实例存活。如果你的Lambda从来没被调用过，或者上一个实例被回收了，Ping没法从零开始创建新实例。所以它适合流量稳定但有低谷期的场景，不适合完全冷启动的场景。

解法三：减少初始化时间

除了"防止冷启动"，也应该努力"让冷启动更快"。

分离初始化的必要性

Lambda的初始化分两个阶段：

  1. 平台层初始化（下载部署包、创建容器环境）：这个你控制不了，但可以通过减小部署包来加速
  2. 函数层初始化（执行static块、初始化Spring容器等）：这个可以优化

把那些"第一次请求时才需要"的初始化推迟到实际请求处理时：

public class AiInferenceLambda implements RequestHandler<...> {

    // 这些在所有请求都需要的，才在静态块初始化
    private static final ObjectMapper objectMapper = new ObjectMapper();
    private static final String OPENAI_API_KEY = System.getenv("OPENAI_API_KEY");

    // 这些按需懒加载
    private static volatile OpenAIClient openAIClient;
    private static volatile VectorStoreClient vectorStoreClient;
    private static final Object clientLock = new Object();

    private OpenAIClient getOpenAIClient() {
        if (openAIClient == null) {
            synchronized (clientLock) {
                if (openAIClient == null) {
                    openAIClient = initOpenAIClient();
                }
            }
        }
        return openAIClient;
    }
}

注意这里用了双重检查锁（DCL），因为多个并发请求可能同时触发懒加载（Lambda的并发请求共享同一个实例）。

减小部署包体积

Lambda的部署包越大，平台下载和解压的时间越长，冷启动越慢。

使用Lambda Layer：把不常变化的大型依赖（比如AWS SDK、常用工具库）放到Lambda Layer，和函数代码分开。Layer可以被多个函数复用，平台会缓存Layer，减少下载时间。

# 把常用依赖打成Layer
mkdir -p java-lib-layer/lib
cp target/dependency/*.jar java-lib-layer/lib/
zip -r java-lib-layer.zip java-lib-layer/

aws lambda publish-layer-version \
  --layer-name java-common-libs \
  --zip-file fileb://java-lib-layer.zip \
  --compatible-runtimes java17

# 函数部署包只包含业务代码
aws lambda update-function-configuration \
  --function-name ai-inference \
  --layers arn:aws:lambda:us-east-1:ACCOUNT:layer:java-common-libs:1

对应的Maven配置，把依赖和业务代码分开打包：

<!-- 只打业务代码，不打依赖 -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <mainClass>com.company.ai.LambdaHandler</mainClass>
            </manifest>
        </archive>
    </configuration>
</plugin>

<!-- 单独打一个dependency层 -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/dependency</outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

使用GraalVM Native Image（高级但有效）

对于冷启动要求很高的场景，可以把Java应用编译成Native Image。Native Image是提前编译（AOT Compile）的，去掉了JVM解释执行的开销，启动时间可以从秒级降到毫秒级。

但Native Image对AI应用有限制：很多通过反射使用的库（Spring、Jackson）需要额外配置，PyTorch/CUDA无法在Native Image里使用（需要JNI，需要额外配置）。所以Native Image更适合"调用外部AI API的包装函数"，而不是"运行本地模型的推理函数"。

<!-- Spring Boot 3.x的GraalVM Native Image支持 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <configuration>
        <imageName>ai-lambda-native</imageName>
        <buildArgs>
            <buildArg>--no-fallback</buildArg>
            <buildArg>-H:+ReportExceptionStackTraces</buildArg>
        </buildArgs>
    </configuration>
</plugin>

解法四：SnapStart（AWS Java Lambda专属）

AWS在2022年推出了Lambda SnapStart，专门针对Java冷启动问题。

原理是：当你发布一个新版本时，Lambda会提前执行一次函数的初始化逻辑，把初始化后的内存状态（JVM堆、已加载的类等）打一个快照。之后创建新实例时，直接从这个快照恢复，不需要重新执行初始化代码。

启用SnapStart：

# SAM模板
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  AiInferenceFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: com.company.ai.LambdaHandler::handleRequest
      Runtime: java17
      SnapStart:
        ApplyOn: PublishedVersions
      MemorySize: 3008
      Timeout: 300

SnapStart有一个重要的注意事项：快照是在某个时间点创建的，但实际请求处理在另一个时间点。如果你在静态块里生成了一个随机数、读取了当前时间戳、建立了TCP连接，这些"时间敏感"的资源在快照恢复后可能已经失效。

需要实现CRaC（Checkpoint/Restore in Java）接口来处理这种情况：

public class AiInferenceLambda implements RequestHandler<...>,
        org.crac.Resource {

    static {
        Core.getGlobalContext().register(new AiInferenceLambda());
    }

    // 在创建快照前调用：把需要持久化的状态保存好，释放不能持久化的资源
    @Override
    public void beforeCheckpoint(org.crac.Context<? extends Resource> context)
            throws Exception {
        System.out.println("快照创建前：关闭TCP连接");
        // 关闭数据库连接、TCP socket等
        if (vectorStoreClient != null) {
            vectorStoreClient.close();
            vectorStoreClient = null;
        }
    }

    // 从快照恢复后调用：重建在快照前释放的资源
    @Override
    public void afterRestore(org.crac.Context<? extends Resource> context)
            throws Exception {
        System.out.println("从快照恢复后：重建TCP连接");
        // 重新建立连接
        vectorStoreClient = VectorStoreClient.connect(
            System.getenv("VECTOR_DB_HOST"),
            Integer.parseInt(System.getenv("VECTOR_DB_PORT"))
        );
    }
}

架构层面的取舍

最后说一个更宏观的观点：Serverless对AI函数来说，不是所有场景都适合。

对于调用外部LLM API的轻量AI函数，Serverless非常合适，省去了运维开销，成本随调用量线性增长。

对于需要加载本地大模型的推理函数，Serverless的冷启动问题很严重，而且大内存Lambda的费用比一台常驻GPU实例贵很多。这种场景更适合容器化部署在K8s上。

做技术选型时，不要被"Serverless真省心"或者"Serverless冷启动太烂"这两种极端论断左右，根据具体的调用频率、延迟要求和成本预算来判断。

编辑此页
最近更新:
贡献者: xiaozhangge