部署大模型时如何做日志监控、调用统计和成本控制？
这道题考的是LLM部署的可观测性体系，说白了就是：你部署的大模型上线后，怎么知道它运行得好不好、花了多少钱、出了问题怎么查。是大厂面试的标配综合题。
一、日志监控该记什么？五大维度缺一不可
大模型的日志记录就像飞机的黑匣子。你以为只要记个"调用成功/失败"就够了？太天真了。
线上出问题了，你得能还原真相：用户问了什么、模型答了什么、用了多少Token、响应耗时多久、哪里可能有瓶颈。这些信息缺任何一块，问题排查就像破案缺证据。
大模型日志必须覆盖五大维度：
| 维度 | 记录内容 |
|---|---|
| 请求信息 | 调用方IP、请求ID、时间戳、接口版本 |
| Prompt信息 | 原始用户输入、系统提示词、few-shot示例 |
| Token信息 | 输入Token数、输出Token数、总Token数 |
| 性能信息 | TTFT首Token时间、总响应时间、队列等待时间 |
| 结果信息 | 模型返回内容、错误码、是否命中缓存 |
这五块信息是串联的。从用户发起请求开始，到拿到模型响应结束，每个环节都得留痕。
实际落地有个细节要强调：Prompt信息一定要脱敏处理。用户输入可能包含手机号、身份证、银行卡这些敏感数据，上传日志系统前必须做 masking。不然就是数据泄露事故，等着上新闻吧。
二、调用统计的核心——Token计费与延迟分析
Token数量直接决定你给云厂商交多少钱。这事没商量余地，必须盯死。
主流大模型都是按Token计费的，GPT-4o举例：输入$5/1M Token，输出$15/1M Token。输出比输入贵3倍。业务里可能80%的成本都花在输出上，你如果不区分统计，根本不知道钱花哪儿了。
统计时必须拆开记录：
# 错误示范
total_tokens = input_tokens + output_tokens # 混在一起
# 正确做法
input_token_count{type="prompt"}
output_token_count{type="completion"}延迟分析也很关键。要区分两个指标：
- TTFT（Time To First Token）：用户发起请求到拿到第一个字的时间。决定"模型是不是开始响应了"
- 总响应时间：用户拿到完整回答的时间。决定"等得烦不烦"
用户体验的瓶颈往往在TTFT。流式输出能大幅降低感知延迟——用户看到字一个个蹦出来，比干等30秒再一次性显示，体验好太多。但技术实现也更复杂，需要配合SSE或者WebSocket。
三、成本控制三板斧——缓存、路由、预算告警
成本控制不是"省着点用"这么简单，是要在用户体验和成本之间找平衡。
第一板斧：语义缓存
相同或相似的用户问题，第二次直接返回缓存结果，不调模型。
原理很简单：计算用户Prompt的语义向量，用向量数据库做相似度搜索。相似度超过阈值（比如0.95）就直接返回缓存的答案。
命中缓存的好处：零延迟、零Token消耗。省下来的都是真金白银。
根据我们的业务数据，缓存命中率能到30%-40%。一天10万次调用，缓存扛3-4万次，这成本节省很可观。
第二板斧：智能路由
不同问题用不同成本的模型处理。
小问题（查天气、问时间）用便宜的小模型（GPT-4o-mini），成本降90%。复杂问题（代码生成、长文本摘要）用大模型。模型选择逻辑可以是规则匹配，也可以用LLM自己判断。
这叫模型路由，像医院的分诊台：小病去小诊所，大病去大医院。
第三板斧：预算告警
设置Token消耗阈值，超了立即告警。
比如设置"单日Token消耗超过1000万"触发告警，防止突发流量把预算烧穿。配合限流策略，超了直接拒绝请求或者排队。
四、技术选型——云服务 vs 自建
选什么方案看团队规模和需求。
初创团队、快速验证：直接用云服务，比如Datadog、New Relic、阿里云日志服务。配置简单，Dashboard现成的，开箱即用。缺点是贵，数据在别人那里。
中大型企业、有定制需求：自建ELK（Elasticsearch+Logstash+Kibana）或者Loki。部署运维成本高，但完全可控，数据在自己机房。想加什么字段、做什么分析，自己说了算。
有个实战经验：不要一开始就把架构做得很复杂。先用最简单的方案跑起来，等业务规模上来了再逐步升级。很多团队上来就搞全套ELK，结果80%的功能永远用不上。
面试怎么答？
基础版
部署大模型时，日志监控需要覆盖五大维度：请求信息、Prompt信息、Token信息、性能信息、结果信息。Token计费要区分输入和输出，分别统计。延迟分析要关注TTFT首Token时间和总响应时间。成本控制主要靠三个手段：一是语义缓存，相同问题直接返回缓存结果；二是智能路由，按问题难度选择合适的模型；三是设置Token消耗阈值告警，防止超预算。
加分版
除了基础维度，我还会关注日志的采集架构设计：Agent采集→缓冲队列→聚合服务→Dashboard。语义缓存用向量数据库做相似度匹配，命中率能做到30%-40%。技术选型上，初创团队用云日志服务快速上手，中大型企业自建ELK支持定制化。我之前做过一个估算，缓存命中能节省40%的Token消耗，这直接反映在成本上。
一句话总结
大模型可观测性的核心：日志记全五大维度、Token成本盯死输入输出、延迟区分TTFT和总时间、成本靠缓存路由告警三板斧。
