跳至主要內容

第2290篇：Serverless AI架构——云函数与LLM调用的成本与延迟权衡

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

第2290篇：Serverless AI架构——云函数与LLM调用的成本与延迟权衡

适读人群：考虑用Serverless降低AI系统运维成本的工程师 | 阅读时长：约14分钟 | 核心价值：理解Serverless在AI场景下的真实成本结构，掌握冷启动优化的关键技巧

我有个朋友在一家初创公司，做AI写作助手，早期日活也就几百个用户。他用的是K8s集群部署，一直运行着几个Pod。我问他，这几个Pod每天大部分时间空载，费钱吗？他说：每月好几千。

AI应用的一个典型特征是流量极不均匀。用户可能白天密集使用，夜里完全没流量；或者某个功能偶尔爆发，平时冷清。传统的"始终保持Pod运行"模式，在低流量时期大量资源浪费。

这让Serverless（云函数）对AI应用很有吸引力——按调用次数付费，零流量零成本。但Serverless用在AI场景有一些独特的挑战，不了解就会踩坑。

Serverless的成本模型分析

以AWS Lambda为例，典型的成本构成：

  • 调用次数费用：$0.20/百万次请求
  • 计算时间费用：$0.0000166667/GB-秒

AI应用的每次LLM调用可能需要5-30秒，内存可能需要512MB-1GB。计算一下：

场景每次调用时长内存每次成本
简单问答5秒512MB~$0.00004
复杂分析30秒1GB~$0.0005
文档处理120秒（Lambda上限）2GB~$0.004

Lambda的最大执行时间是15分钟，但对于需要等待LLM响应的应用，如果模型响应超过30秒，用户体验已经很差了。

和EC2/K8s的成本对比：

方案月成本（100万次调用，每次10秒）零流量成本
Lambda~$166$0
1台t3.medium EC2~$30（实例费）$30
EKS集群（3节点）~$300+$300+

结论：当日均调用量很低（比如每天几千次）或流量极不均匀时，Serverless有显著成本优势。当流量持续高位时，EC2/K8s更划算。

冷启动：Serverless AI的最大挑战

冷启动是Serverless最让人头疼的问题，在AI应用里尤其突出。

Java Lambda的冷启动时间通常在2-5秒（甚至更长），加上AI模型调用的延迟，用户等待时间难以接受。冷启动的主要原因：

  1. JVM启动需要时间
  2. Spring容器初始化（如果用了Spring）
  3. 加载各种依赖库
  4. AI客户端的HTTP连接建立

解决方案一：GraalVM Native Image

把Java应用编译成本机可执行文件，冷启动时间降到200-500ms：

// Spring Boot + GraalVM Native编译配置
// pom.xml
<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <configuration>
        <imageName>ai-lambda</imageName>
        <buildArgs>
            <buildArg>--no-fallback</buildArg>
            <buildArg>-H:+ReportExceptionStackTraces</buildArg>
            <!-- 优化初始化时机，减少冷启动 -->
            <buildArg>--initialize-at-build-time=org.slf4j</buildArg>
        </buildArgs>
    </configuration>
</plugin>

但Native Image有个坑：很多Java库用了反射，与GraalVM兼容性差，需要提供反射配置文件。AI相关的HTTP客户端库通常需要额外配置。

解决方案二：最小化初始化

把能延迟初始化的东西都延迟：

// AWS Lambda Handler
public class AiLambdaHandler implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {
    
    // 静态字段：Lambda实例复用时不会重新初始化（热启动复用）
    private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();
    
    // 懒加载：第一次调用时才初始化，冷启动时不初始化
    private static volatile LlmClient llmClient;
    
    private static LlmClient getLlmClient() {
        if (llmClient == null) {
            synchronized (AiLambdaHandler.class) {
                if (llmClient == null) {
                    llmClient = new AnthropicClient(
                        System.getenv("ANTHROPIC_API_KEY")
                    );
                }
            }
        }
        return llmClient;
    }
    
    @Override
    public APIGatewayProxyResponseEvent handleRequest(
            APIGatewayProxyRequestEvent event,
            Context context) {
        
        try {
            AiRequest request = OBJECT_MAPPER.readValue(
                event.getBody(), AiRequest.class
            );
            
            // Lambda实例复用时，这里走热路径（不需要重新初始化客户端）
            String response = getLlmClient().complete(request.getPrompt());
            
            return success(response);
        } catch (Exception e) {
            log.error("处理请求失败", e);
            return error(e.getMessage());
        }
    }
}

解决方案三：Provisioned Concurrency（预置并发）

对于必须保证低延迟的端点，配置预置并发，让Lambda始终有N个实例处于热状态：

这个要花钱，但比EC2便宜很多，适合"平时有稳定流量、偶尔突发"的场景：

# serverless.yml
functions:
  aiHandler:
    handler: com.example.AiLambdaHandler
    memorySize: 1024
    timeout: 60
    provisionedConcurrency: 5  # 始终保持5个热实例
    environment:
      ANTHROPIC_API_KEY: ${env:ANTHROPIC_API_KEY}

流式响应在Serverless的挑战

LLM的流式输出（streaming）在Serverless里很难做，因为标准的Lambda调用是请求-响应模式，不支持中间的数据流。

解决方案：Lambda + WebSocket API Gateway 或者 Lambda Response Streaming（AWS较新的功能）：

// 使用Lambda Response Streaming（需要aws-lambda-java-runtime-interface-client >= 2.3.0）
@LambdaHandler
public StreamingOutput streamAiResponse(String prompt) {
    
    return outputStream -> {
        PrintWriter writer = new PrintWriter(outputStream, true);
        
        // 流式调用LLM
        llmClient.streamComplete(prompt, chunk -> {
            // 每收到一个chunk就写入输出流
            writer.println("data: " + chunk.toJson() + "\n");
            writer.flush();
        });
        
        writer.println("data: [DONE]");
    };
}

另一个方案是异步模式：Lambda接收请求后，立刻返回一个任务ID，AI处理完后通过WebSocket或轮询通知用户：

@Override
public APIGatewayProxyResponseEvent handleRequest(
        APIGatewayProxyRequestEvent event, Context context) {
    
    AiRequest request = parseRequest(event);
    String taskId = UUID.randomUUID().toString();
    
    // 把任务推入SQS，由另一个Lambda异步处理
    sqsClient.sendMessage(SendMessageRequest.builder()
        .queueUrl(TASK_QUEUE_URL)
        .messageBody(OBJECT_MAPPER.writeValueAsString(request))
        .messageAttributes(Map.of(
            "TaskId", MessageAttributeValue.builder()
                .stringValue(taskId)
                .dataType("String")
                .build()
        ))
        .build());
    
    // 立刻返回任务ID
    return accepted(Map.of("taskId", taskId));
}

状态管理：Serverless是无状态的

Serverless函数是无状态的，而AI对话是有状态的。对话历史的存储需要外化：

@Service
public class ServerlessConversationManager {
    
    private final DynamoDbClient dynamoDb;
    private final String TABLE_NAME = "ai-conversations";
    
    /**
     * 从DynamoDB加载对话历史
     * DynamoDB适合Serverless：按量计费，无需管理服务器
     */
    public List<ChatMessage> loadHistory(String conversationId) {
        QueryRequest request = QueryRequest.builder()
            .tableName(TABLE_NAME)
            .keyConditionExpression("conversationId = :cid")
            .expressionAttributeValues(Map.of(
                ":cid", AttributeValue.builder().s(conversationId).build()
            ))
            .limit(20)  // 只取最近20条
            .scanIndexForward(false)  // 最新的在前
            .build();
        
        return dynamoDb.query(request).items().stream()
            .map(this::mapToMessage)
            .collect(Collectors.toList());
    }
    
    /**
     * 保存新消息
     */
    public void saveMessage(String conversationId, ChatMessage message) {
        Map<String, AttributeValue> item = new HashMap<>();
        item.put("conversationId", AttributeValue.builder().s(conversationId).build());
        item.put("messageId", AttributeValue.builder().s(message.getId()).build());
        item.put("role", AttributeValue.builder().s(message.getRole()).build());
        item.put("content", AttributeValue.builder().s(message.getContent()).build());
        item.put("timestamp", AttributeValue.builder().n(String.valueOf(System.currentTimeMillis())).build());
        
        // TTL 30天（自动删除旧对话）
        long ttl = Instant.now().plus(30, ChronoUnit.DAYS).getEpochSecond();
        item.put("ttl", AttributeValue.builder().n(String.valueOf(ttl)).build());
        
        dynamoDb.putItem(PutItemRequest.builder()
            .tableName(TABLE_NAME)
            .item(item)
            .build());
    }
}

什么时候选Serverless，什么时候不选

选Serverless的场景：

  • 早期产品，用户量不确定，需要控制固定成本
  • 功能性AI特性（比如内容审核、意图识别），调用频率不高
  • 内部工具，使用时间集中（比如工作日9-18点）
  • 需要快速上线，不想管运维

不选Serverless的场景：

  • 需要持续流式输出（Streaming）的对话应用
  • 需要加载大型模型文件（Lambda包大小有限）
  • 高并发持续请求（成本反而高于EC2）
  • 对P99延迟有严格要求（冷启动无法完全消除）

Serverless不是银弹，但对于刚起步的AI应用来说，它是控制基础设施成本、快速验证想法的好工具。

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