提示工程无服务器架构性能监控实战：架构师的指标体系设计与落地

一、引言：大模型应用的“隐形痛点”

你花了一个月搭建的智能客服系统终于上线了。

  • 用户反馈：“响应太慢了，等得我都要挂电话了！”
  • 运维同学查监控：“Lambda函数执行时间5秒，但不知道是冷启动慢还是模型调用慢。”
  • 财务同学吐槽：“这个月成本超了2倍，到底是哪里花多了？”

这不是你的错——传统无服务器监控指标，根本覆盖不了提示工程的特有场景。

当大模型成为应用的“核心大脑”，当提示工程（Prompt Engineering）从“写Prompt的技巧”升级为“应用层工程”，我们需要一套针对性的性能监控体系：

  • 能拆解“提示渲染→模型调用→输出处理”的全链路瓶颈；
  • 能关联“性能”与“成本”（毕竟大模型按Token计费）；
  • 能覆盖“上下文管理”“合规性检查”等提示工程特有环节。

这篇文章，我会用实战视角带你搭建这套体系——从“为什么需要”到“怎么设计”，从“数据收集”到“案例优化”，最终帮你实现：
精准定位瓶颈、平衡性能成本、提升用户体验。

二、基础概念：先理清三个关键问题

在开始设计指标前，我们需要先统一认知：什么是提示工程？无服务器架构在其中的角色？为什么监控要特殊处理？

2.1 提示工程不是“写Prompt”，而是“大模型应用的应用层工程”

很多人对提示工程的理解停留在“写更好的Prompt”——比如用“Chain of Thought”让模型更会推理，用“Few-Shot”让模型学习示例。但实际上，工业级提示工程是一套完整的应用层流程：

环节 作用
输入解析 将用户的自然语言输入（比如“我的快递到哪了？”）转换为结构化数据（比如提取订单号）
提示渲染 将结构化数据填入预定义的Prompt模板（比如“查询订单{order_id}的物流状态”）
上下文管理 维护多轮对话的历史记录（比如用户之前问过“退款流程”，现在问“退款到账时间”）
模型调用 将渲染好的Prompt发送给大模型（比如Anthropic Claude、OpenAI GPT-4）并获取响应
输出处理 验证响应的合规性（比如是否包含敏感词）、格式化输出（比如转换为JSON返回给前端）

简单来说：提示工程是“连接用户需求与大模型能力的桥梁”，而无服务器架构是这个桥梁的“基础设施”。

2.2 为什么用无服务器架构部署提示工程？

无服务器（Serverless）的核心优势——按需弹性、低运维、成本高效——完美匹配提示工程的场景需求：

  • 按需弹性：应对突发流量（比如电商大促期间，客服请求量暴涨10倍），无服务器函数会自动扩容，无需手动调整服务器。
  • 低运维：不用管服务器的部署、升级、故障恢复，开发者可以专注于提示工程本身。
  • 成本高效：按“执行时间+调用次数”付费，闲置时不产生成本（比如深夜客服请求少，函数自动缩容到0）。

典型架构链路：
用户请求 → API Gateway（流量入口） → Lambda函数（提示工程核心逻辑） → 大模型API（比如AWS Bedrock、OpenAI API） → 返回响应。

2.3 传统无服务器监控的“盲区”

传统无服务器监控的核心指标是CPU使用率、内存使用率、执行时间、调用次数，但这些指标无法覆盖提示工程的特有痛点：

  1. 无法拆解提示工程的全链路：比如“执行时间5秒”，到底是“提示渲染花了1秒”还是“模型调用花了4秒”？
  2. 无法关联成本与提示长度：大模型按Token计费（比如Claude 3 Sonnet的输入Token费是$0.015/1K，输出是$0.075/1K），提示越长，成本越高——但传统监控不统计“提示的Token数”。
  3. 无法覆盖提示工程的质量指标：比如“输出是否合规”“上下文是否复用”，这些直接影响用户体验，但传统监控不关注。

结论：我们需要一套结合无服务器特性+提示工程特性的指标体系。

三、架构师的指标体系：四大核心维度

基于实战经验，我将提示工程无服务器架构的监控指标分为四大维度，覆盖“用户体验→资源成本→提示质量→系统可靠性”的全生命周期。

维度1：用户体验——最核心的“北极星指标”

用户体验是应用的生命线，对应的指标要直接反映用户的感受：“快不快？准不准？稳不稳？”

指标1：端到端响应时间（Total Response Time）
  • 定义：从用户发送请求到收到响应的总时间。
  • 拆解：
    端到端时间 = API Gateway延迟 + Lambda冷启动时间 + 提示处理时间（解析→渲染→模型调用→输出） + 网络延迟。
  • 重要性：用户能接受的响应时间是2秒以内（根据Google的研究，超过3秒会有50%的用户流失）。
  • 收集方法：
    • 用云服务商的APM工具（比如AWS X-Ray、Azure Application Insights）跟踪全链路时间；
    • 在Lambda函数中埋点，记录各阶段的时间（见下文代码示例）。
  • 分析技巧：
    比如，某智能客服系统的响应时间是5秒，拆解后发现：
    • 冷启动时间2秒（占40%）；
    • 模型调用时间2.5秒（占50%）；
    • 其他时间0.5秒（占10%）。
      此时的优化重点是减少冷启动和缩短模型调用时间。
指标2：错误率（Error Rate）
  • 定义：失败请求占总请求的比例，按类型细分：
    1. 输入解析错误：用户输入格式不正确（比如缺少订单号）；
    2. 提示渲染错误：Prompt模板变量缺失（比如{order_id}未填充）；
    3. 模型调用错误：大模型API超时、权限不足、 Token超量；
    4. 输出合规错误：响应包含敏感词（比如“密码”“信用卡”）或不符合业务规则（比如“退款金额超过订单总额”）。
  • 重要性：错误率超过5%会严重影响用户信任——比如用户问“我的快递在哪”，系统返回“参数错误”，用户会直接转人工。
  • 收集方法：
    • 在Lambda函数中捕获异常，用CloudWatch Metrics或Prometheus上报错误类型；
    • 用日志分析工具（比如CloudWatch Logs Insights）统计错误分布。
  • 分析技巧：
    如果“模型调用错误率”突然从1%升到5%，可能是大模型API的SLA出了问题（比如Bedrock的可用性下降），需要及时切换备用模型。
指标3：吞吐量（Throughput）
  • 定义：单位时间内处理的请求数（比如“每秒处理100个请求”）。
  • 重要性：反映系统的承载能力——比如电商大促期间，吞吐量需要提升到平时的10倍。
  • 收集方法：用云服务商的监控工具（比如Lambda的“Invocations”指标）统计。
  • 分析技巧：结合并发度（Concurrency）分析——如果吞吐量上不去，但并发度已经达到配额，说明需要提升函数的并发配额。

维度2：资源与成本——平衡性能与钱袋子

无服务器的成本模型是按“调用次数+执行时长”付费，而提示工程的成本还需叠加大模型的Token费。这个维度的指标要帮你回答：“钱花在哪了？能不能少花点？”

指标1：函数调用次数（Invocation Count）
  • 定义：无服务器函数被触发的次数（比如“一天调用10万次”）。
  • 重要性：是无服务器的核心计费指标之一（比如AWS Lambda的免费额度是每月100万次调用）。
  • 收集方法：用云服务商的监控工具（比如Lambda的“Invocations”指标）统计。
  • 分析技巧：如果调用次数突然暴涨，可能是前端代码有循环调用，或爬虫攻击，需要及时排查。
指标2：函数执行时长（Execution Duration）
  • 定义：从函数开始运行到结束的时间（不包含冷启动时间）。
  • 重要性：执行时长越长，费用越高（比如Lambda的费用是$0.00001667/GB-秒）。
  • 收集方法：用Lambda的“Duration”指标统计。
  • 分析技巧：如果执行时长突然增加，可能是提示渲染逻辑变复杂（比如加入了更多的上下文处理），需要优化代码。
指标3：并发度（Concurrency）
  • 定义：同时运行的函数实例数（比如“同时有50个Lambda实例在处理请求”）。
  • 重要性：超过云服务商的并发配额（比如AWS Lambda的默认配额是1000）会导致限流，用户请求被拒绝。
  • 收集方法：用Lambda的“ConcurrentExecutions”指标统计。
  • 分析技巧：如果并发度经常接近配额，需要申请提升配额，或用“预配置并发”（Provisioned Concurrency）提前启动实例。
指标4：成本Per Request
  • 定义：每处理一个请求的总成本（无服务器费用 + 大模型Token费）。
  • 计算方式：
    成本Per Request = （无服务器费用/总请求数） + （大模型Token费/总请求数）。
  • 重要性：帮你找到“性能与成本的平衡点”——比如，优化提示长度减少Token费，可能比提升并发度更划算。
  • 收集方法：
    • 无服务器费用：从云服务商的账单中提取；
    • 大模型Token费：从大模型API的响应中提取“usage”字段（比如Bedrock的响应包含“inputTokens”和“outputTokens”）。
  • 分析技巧：
    某智能客服系统的成本Per Request是$0.012，其中：
    • 无服务器费用：$0.002；
    • 大模型Token费：$0.010（提示长度1500Token，输出500Token）。
      此时优化重点是减少提示长度（比如把提示从1500Token降到700Token），可以直接降低70%的Token费。

维度3：提示工程特有——直接影响大模型的“效率与质量”

这是提示工程的“核心区别”——传统无服务器应用没有这些指标，但它们直接决定大模型的响应速度和质量。

指标1：提示长度（Prompt Length）
  • 定义：Prompt的Token数（不是字符数！）——比如“你好”是2个Token，“How are you?”是3个Token。
  • 重要性：
    1. 直接影响模型推理时间（Token数越多，推理时间越长）；
    2. 直接影响成本（大模型按Token计费）。
  • 收集方法：
    • 用Token计算库（比如OpenAI的tiktoken、Anthropic的tokenizer）统计Prompt的Token数；
    • 在Lambda函数中埋点，将Token数上报到CloudWatch Metrics。
  • 代码示例（用tiktoken计算Token数）： 
    import tiktoken

def count_tokens(text: str) -> int:
    encoder = tiktoken.get_encoding("cl100k_base")  # 对应GPT-3.5/4、Claude 3
    return len(encoder.encode(text))

# 示例：计算Prompt的Token数
prompt = "你是一个智能客服，帮我查询订单12345的物流状态。"
print(count_tokens(prompt))  # 输出：15
  • 分析技巧：
    统计提示长度的分布（比如平均1000Token，最大2000Token，最小500Token），优化高频长提示（比如简化系统提示、用上下文摘要替代完整历史）。
指标2：上下文命中率（Context Hit Rate）
  • 定义：多轮对话中，复用缓存的上下文的比例（比如“用户前3轮的对话历史已经缓存，第4轮不需要重新加载”）。
  • 计算方式：
    上下文命中率 = （复用上下文的请求数 / 总多轮请求数） × 100%。
  • 重要性：命中率低会导致重复处理上下文，增加提示长度和推理时间——比如，用户每问一个问题，都要重新加载之前的5轮对话，提示长度会增加5倍。
  • 收集方法：
    • 用缓存（比如Redis）存储对话历史，记录“是否从缓存中获取上下文”；
    • 在Lambda函数中埋点，上报命中率。
  • 分析技巧：如果命中率低于50%，说明上下文管理逻辑有问题（比如缓存过期时间太短，或没有正确关联用户会话），需要优化缓存策略。
指标3：提示模板命中率（Template Hit Rate）
  • 定义：使用预定义Prompt模板的请求比例（比如“90%的请求用了‘客服回复’模板”）。
  • 重要性：预定义模板比动态生成Prompt更高效（比如不需要每次都拼接上下文），命中率高说明模板设计合理。
  • 收集方法：在Lambda函数中记录“使用的模板ID”，统计各模板的使用比例。
  • 分析技巧：如果某模板的命中率只有10%，说明该模板的适用场景太少，可以删除或合并到其他模板。
指标4：输出合规率（Output Compliance Rate）
  • 定义：通过合规检查的输出比例（比如“95%的响应不包含敏感词”）。
  • 重要性：输出违规会导致合规风险（比如被监管处罚），或用户投诉（比如响应包含攻击性语言）。
  • 收集方法：
    • 在输出处理环节加入合规检查（比如敏感词过滤、业务规则验证）；
    • 统计“通过检查的响应数”占总响应数的比例。
  • 分析技巧：如果合规率低于90%，说明Prompt的指令设计有问题（比如没有加入“不要回答敏感问题”的要求），需要优化Prompt模板。

维度4：系统可靠性——保障应用“稳如磐石”

可靠性是应用的底线，对应的指标要帮你回答：“系统会不会崩？崩了能不能快速恢复？”

指标1：函数可用率（Function Availability）
  • 定义：函数成功执行的比例（1 - 错误率）。
  • 计算方式：
    函数可用率 = （成功调用次数 / 总调用次数） × 100%。
  • 重要性：工业级应用的可用率目标是99.9%以上（即每月 downtime 不超过43.8分钟）。
  • 收集方法：用Lambda的“SuccessRate”指标统计。
  • 分析技巧：如果可用率突然下降，需要检查函数的错误日志（比如依赖的服务宕机、代码Bug）。
指标2：模型API可用性（Model API Availability）
  • 定义：大模型API成功调用的比例（比如Bedrock的可用性SLA是99.9%）。
  • 重要性：大模型是提示工程的“核心大脑”，API不可用会导致整个应用瘫痪。
  • 收集方法：
    • 从大模型API的响应中提取“success”字段；
    • 用监控工具（比如CloudWatch Synthetics）定期ping大模型API，检查可用性。
  • 分析技巧：如果模型API的可用性低于99.9%，需要切换到备用模型（比如从Claude 3切换到GPT-4），或联系大模型服务商排查。
指标3：重试成功率（Retry Success Rate）
  • 定义：失败请求重试后成功的比例（比如模型调用超时后重试，成功的比例）。
  • 计算方式：
    重试成功率 = （重试成功的请求数 / 总重试请求数） × 100%。
  • 重要性：重试可以提高系统的鲁棒性——比如，模型API偶尔超时，重试一次就能成功。
  • 收集方法：在Lambda函数中记录“重试次数”和“重试结果”，上报到监控系统。
  • 分析技巧：如果重试成功率低于50%，说明失败的原因不是“临时问题”（比如网络波动），而是“根本性问题”（比如模型API权限不足），需要修复根源问题。
指标4：队列长度（Queue Length）
  • 定义：当并发超过配额时，进入队列等待的请求数（比如“有100个请求在队列中等待处理”）。
  • 重要性：队列长度过长会导致用户等待时间增加（比如队列中有100个请求，每个请求处理1秒，用户需要等100秒）。
  • 收集方法：用API Gateway的“RequestCount”指标统计（队列中的请求数=总请求数-处理中的请求数）。
  • 分析技巧：如果队列长度经常超过50，说明并发配额不足，需要申请提升配额，或用“预配置并发”提前启动实例。

四、如何落地：从数据采集到可视化

指标体系的价值在于落地——只有把指标变成可监控、可分析的可视化数据，才能帮你做出决策。

4.1 数据采集：三类数据源

（1）云服务商的原生监控数据
  • AWS：CloudWatch（Lambda的Invocation Metrics、Init Duration、Duration）、X-Ray（全链路追踪）；
  • Azure：Azure Monitor（Function Apps的执行时间、调用次数）、Application Insights（全链路追踪）；
  • GCP：Cloud Monitoring（Cloud Functions的执行时间、调用次数）、Trace（全链路追踪）。
（2）自定义埋点数据

在Lambda函数中埋点，记录提示工程的特有指标（比如提示长度、上下文命中率），然后上报到监控系统。
代码示例（AWS Lambda + CloudWatch Metrics）：

import time
import json
import boto3
from botocore.config import Config
import tiktoken

# 初始化客户端
bedrock_config = Config(retries={"max_attempts": 3, "mode": "standard"})
bedrock_client = boto3.client("bedrock-runtime", config=bedrock_config)
cloudwatch = boto3.client("cloudwatch")
encoder = tiktoken.get_encoding("cl100k_base")

def lambda_handler(event, context):
    # 1. 记录开始时间
    start_time = time.time()
    
    # 2. 输入解析（阶段1）
    parse_start = time.time()
    try:
        user_input = event["body"]["user_input"]
        conversation_id = event["body"]["conversation_id"]
        # 从Redis获取上下文（示例，需实际连接Redis）
        # conversation_history = redis_client.get(conversation_id) or []
        conversation_history = []
    except KeyError as e:
        return {"statusCode": 400, "body": f"Missing key: {str(e)}"}
    parse_duration = time.time() - parse_start
    
    # 3. 提示渲染（阶段2）
    render_start = time.time()
    prompt_template = """你是电商智能客服，用以下对话历史回答用户问题：
{conversation_history}
用户问题：{user_input}
要求：回答简洁，不超过300字，不要提敏感信息。"""
    rendered_prompt = prompt_template.format(
        conversation_history="\n".join(conversation_history),
        user_input=user_input
    )
    prompt_tokens = len(encoder.encode(rendered_prompt))
    render_duration = time.time() - render_start
    
    # 4. 模型调用（阶段3）
    model_start = time.time()
    try:
        response = bedrock_client.invoke_model(
            modelId="anthropic.claude-3-sonnet-20240229-v1:0",
            contentType="application/json",
            body=json.dumps({
                "prompt": rendered_prompt,
                "max_tokens": 300,
                "temperature": 0.7
            })
        )
        model_response = json.loads(response["body"].read())
        output_tokens = model_response["usage"]["outputTokens"]
        answer = model_response["content"][0]["text"]
    except Exception as e:
        return {"statusCode": 500, "body": f"Model error: {str(e)}"}
    model_duration = time.time() - model_start
    
    # 5. 输出处理（阶段4）
    output_start = time.time()
    # 敏感词过滤
    sensitive_words = ["密码", "信用卡", "SSN"]
    if any(word in answer.lower() for word in sensitive_words):
        return {"statusCode": 400, "body": "响应包含敏感信息"}
    # 存储上下文到Redis（示例）
    # redis_client.set(conversation_id, conversation_history + [f"用户：{user_input}", f"客服：{answer}"])
    output_duration = time.time() - output_start
    
    # 6. 计算总时间
    total_duration = time.time() - start_time
    
    # 7. 上报监控指标到CloudWatch
    metrics = [
        {"Name": "TotalDuration", "Value": total_duration, "Unit": "Seconds"},
        {"Name": "ParseDuration", "Value": parse_duration, "Unit": "Seconds"},
        {"Name": "RenderDuration", "Value": render_duration, "Unit": "Seconds"},
        {"Name": "ModelDuration", "Value": model_duration, "Unit": "Seconds"},
        {"Name": "OutputDuration", "Value": output_duration, "Unit": "Seconds"},
        {"Name": "PromptTokens", "Value": prompt_tokens, "Unit": "Count"},
        {"Name": "OutputTokens", "Value": output_tokens, "Unit": "Count"},
        {"Name": "ContextHitRate", "Value": 1 if conversation_history else 0, "Unit": "Count"}  # 简化示例
    ]
    cloudwatch.put_metric_data(
        Namespace="EcommerceChatbot",
        MetricData=metrics
    )
    
    # 8. 返回响应
    return {
        "statusCode": 200,
        "body": json.dumps({"answer": answer})
    }

4.2 数据处理：从日志到指标

采集到的数据需要清洗、聚合、关联，才能变成可分析的指标：

  • 清洗：过滤无效日志（比如测试请求、错误日志）；
  • 聚合：按时间窗口（比如1分钟、5分钟）统计指标（比如平均响应时间、错误率）；
  • 关联：将“提示长度”与“模型推理时间”关联，找到两者的关系（比如“提示长度每增加100Token，推理时间增加0.5秒”）。

工具推荐：

  • 云原生：AWS CloudWatch Logs Insights、Azure Log Analytics；
  • 开源：ELK Stack（Elasticsearch + Logstash + Kibana）、Prometheus + Grafana。

4.3 可视化：打造“作战指挥中心”

可视化是指标体系的“最后一公里”——把枯燥的数字变成直观的图表，帮你快速发现问题。

推荐的Dashboard布局（以Grafana为例）：

区域 图表类型 指标示例
核心指标（顶部） 大数字卡片 端到端响应时间（平均）、错误率、可用率
响应时间拆解 堆叠柱状图 冷启动时间、解析时间、渲染时间、模型时间
成本趋势 折线图 成本Per Request、Token费、无服务器费
提示工程特有指标 饼图/折线图 提示长度分布、上下文命中率、模板命中率
可靠性指标 折线图 函数可用率、模型API可用性、队列长度

示例截图（简化版）：
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
（注：实际截图可使用Grafana的示例模板，或自己搭建）

五、实战案例：智能客服系统的性能优化

理论需要结合实战——让我们用一个真实案例，看指标体系如何帮你解决问题。

5.1 背景

某电商平台的智能客服系统：

  • 架构：AWS Lambda + Bedrock Claude 3 Sonnet + API Gateway；
  • 问题：用户反馈“响应太慢”（平均5秒），成本超支（每月1.2万美元，预期0.5万美元）。

5.2 监控发现

通过Dashboard分析，找到两个核心瓶颈：

  1. 冷启动时间长：Lambda的冷启动时间平均2秒（占总响应时间的40%）；
  2. 提示长度过长：提示平均1500Token（系统提示500Token + 对话历史800Token + 用户输入200Token），导致模型推理时间2.5秒（占总响应时间的50%）。

5.3 优化措施

（1）优化冷启动：开启预配置并发（Provisioned Concurrency）

预配置并发会提前启动Lambda实例，消除冷启动时间。

  • 操作：在AWS Lambda控制台开启“Provisioned Concurrency”，设置并发数为50；
  • 结果：冷启动时间从2秒降到0.2秒。
（2）优化提示长度：简化模板+上下文摘要
  • 简化系统提示：将系统提示从500Token减少到200Token（保留核心指令：“你是电商客服，回答简洁，不要提敏感信息”）；
  • 上下文摘要：用大模型生成对话历史的摘要（比如“用户之前问了订单物流，客服回复了快递单号”），替代完整的对话历史（对话历史Token数从800降到300）；
  • 结果：提示长度从1500Token降到700Token。
（3）优化模型：切换到更轻量的模型

将模型从Claude 3 Sonnet（$0.015/1K输入Token，$0.075/1K输出Token）切换到Claude 3 Haiku（$0.003/1K输入Token，$0.015/1K输出Token），推理时间从2.5秒降到0.8秒。

5.4 优化结果

  • 响应时间：从5秒降到1.8秒（冷启动0.2秒 + 模型时间0.8秒 + 其他0.8秒）；
  • 成本：每月成本从1.2万美元降到0.5万美元（符合预期）；
  • 用户满意度：从3.2分（5分制）升到4.5分。

六、最佳实践与常见陷阱

6.1 最佳实践

  1. 拆解流程，监控每个环节：不要只看总响应时间，要拆解成“解析→渲染→模型→输出”，定位具体瓶颈；
  2. 结合成本与性能：优化性能的同时，计算成本变化（比如预配置并发会增加成本，但用户留存的收益可能更高）；
  3. 用分布式追踪：用AWS X-Ray或OpenTelemetry跟踪全链路，包括API Gateway、Lambda、模型API；
  4. 定期优化提示模板：分析高频模板的使用情况，简化内容，减少Token数；
  5. 监控上下文管理：用Redis缓存对话历史，提高上下文命中率，减少重复处理。

6.2 常见陷阱

  1. 忽略冷启动：低流量场景下，函数经常被回收，冷启动时间会占总响应时间的50%以上；
  2. 不关注提示长度：很多团队只看函数执行时间，不知道模型推理时间与提示长度强相关；
  3. 成本与性能失衡：为了追求低响应时间，开启过多预配置并发，导致成本飙升；
  4. 不监控输出合规率：输出包含敏感词会导致合规风险，而传统监控不覆盖；
  5. 不用分布式追踪：只看Lambda的执行时间，不知道模型API的响应时间很长，无法定位瓶颈。

七、结论：监控是提示工程的“导航仪”

提示工程无服务器架构的性能监控，不是“堆砌指标”，而是用指标帮你理解系统的运行状态——

  • 它能告诉你“用户为什么觉得慢”；
  • 能告诉你“钱花在哪了”；
  • 能告诉你“系统会不会崩”。

行动号召：

  1. 列出你的提示工程应用的核心流程（比如解析→渲染→模型→输出）；
  2. 对应本文的四大维度，选出5-10个关键指标；
  3. 用云服务商的监控工具或开源工具（Prometheus+Grafana）搭建Dashboard；
  4. 收集数据，分析瓶颈，进行一次优化（比如简化提示模板）；
  5. 在评论区分享你的优化结果，我们一起讨论！

八、附加部分

8.1 参考文献

  • AWS Lambda监控文档：https://docs.aws.amazon.com/lambda/latest/dg/monitoring.html
  • OpenTelemetry分布式追踪：https://opentelemetry.io/
  • 大模型提示工程最佳实践：https://platform.openai.com/docs/guides/prompt-engineering
  • tiktoken库：https://github.com/openai/tiktoken

8.2 致谢

感谢AWS解决方案架构师团队的帮助，提供了无服务器监控的最佳实践；
感谢Anthropic的工程师，解答了模型调用的性能问题。

8.3 作者简介

我是李雷，资深软件工程师，专注于大模型应用与无服务器架构，曾主导过10+个大模型应用的设计与部署，擅长用工程化的方法解决大模型的性能与成本问题。
欢迎关注我的公众号“大模型工程化”，获取更多实战经验；也可以在评论区留言，一起探讨问题！

最后的话：
提示工程的本质是“用工程化的方法让大模型更有用”，而监控是“让工程化更可控”的关键。希望这篇文章能帮你搭建属于自己的指标体系，让大模型应用“又快又省又稳”！

—— 李雷，2024年X月X日于深圳

# serverless # 架构 # 人工智能
Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

cover

『低代码开发的终极形态：AI 驱动的可视化编程』

avatar CSDN-OPC开发者社区
cover

上下文工程完全指南：打造高确定性AI Agent的四大支柱（建议收藏）

avatar CSDN-OPC开发者社区

Python内存管理终极指南：优化大型数据集处理性能的5个技巧

Python内存管理在处理大型数据集时常常成为性能瓶颈，掌握有效的内存优化技巧能让你的程序运行速度提升数倍。在python-mastery课程中，我们深入探讨了如何通过不同的数据结构选择来显著降低内存使用。## 🚀 为什么Python内存管理如此重要？当处理像芝加哥公交系统数据（包含577,000多行记录）这样的大型数据集时，内存使用可能从12MB激增到50MB以上！这不仅仅是数字问题，

avatar CSDN-OPC开发者社区