AI 面试模块
Token、成本、服务器与部署面试模块
讲清 Token 计费、模型调用成本、缓存、限流、GPU/服务器选型、AutoDL 与推理部署的工程问题。
视频中提到 Token 扣费、服务器和 AutoDL。面试里这类问题能很好地区分“只会 Demo”和“考虑生产成本”的候选人。
#Token 成本基础
Token 可以理解为模型处理文本的基本计费单位。一次调用通常包含输入 Token 和输出 Token，长上下文、检索片段、历史对话和冗长回答都会增加成本。多轮 Agent 因为会反复调用模型和工具，成本更容易失控。
#高频问题与参考回答
#为什么同一个问题成本可能差很多？
因为输入上下文不同、检索片段数量不同、模型不同、输出长度不同、是否多轮工具调用也不同。一个 RAG 问答如果塞入 20 个长片段，比只塞入 5 个高相关片段贵很多；一个 Agent 如果循环 10 步，也会比单次问答贵很多。
#如何控制 Token 成本？
可以从四层控制：第一，输入层做上下文压缩、去重和片段筛选；第二，模型层做分级路由，简单任务用小模型；第三，系统层做缓存、限流和预算；第四，产品层限制最大轮次、最大输出长度和高成本功能使用范围。
#什么时候需要自己部署模型？
当数据安全、成本、延迟、可控性或定制模型成为核心约束时，可以考虑自部署。但自部署不是免费：要承担 GPU、显存、推理框架、模型量化、并发、监控、扩缩容和故障恢复。中小团队通常先用 API 验证价值，再评估自部署。
#服务器选型看什么？
看模型大小、显存需求、并发、延迟和预算。推理常关注 GPU 显存、吞吐、KV Cache、量化方式和批处理；应用服务还要看 CPU、内存、网络、磁盘和带宽。AutoDL 这类平台适合学习、实验和短期训练/推理，但生产部署要评估稳定性和运维能力。
#成本控制方案
| 层级 | 手段 | 风险 |
|---|---|---|
| Prompt | 压缩上下文、限制输出 | 过度压缩会丢信息 |
| RAG | TopK 控制、重排、去重 | 召回不足会答不准 |
| 模型 | 大小模型路由 | 小模型可能能力不足 |
| 缓存 | 问题缓存、片段缓存、结果缓存 | 数据更新后缓存可能过期 |
| Agent | 限制步骤、预算中断 | 复杂任务可能做不完 |
| 监控 | Token、费用、失败率告警 | 指标口径要统一 |
#项目追问
- 你们平均每次请求多少 Token？
- P95 延迟和成本是多少？
- 是否做模型分级路由？
- 缓存命中率是多少？
- Agent 最大执行轮数是多少？
- 单用户预算和全局预算怎么设置？
- 模型服务失败后怎么降级？
#可讲落地案例
一个知识库问答系统上线后发现成本偏高，可以通过减少低相关片段、加入重排、限制回答长度、缓存热门问题、简单问题使用小模型来优化。回答时最好给出优化前后的指标，例如单次请求成本下降、平均延迟下降、人工满意度没有明显下降。
#Token 成本拆账方法
面试中可以把一次请求成本拆成：系统 Prompt、用户输入、历史对话、检索片段、工具结果、模型输出和重试成本。RAG 系统常见成本大头是检索片段太多；Agent 系统常见成本大头是多轮循环和工具结果过长；报告生成系统常见成本大头是长输出。拆账后才能针对性优化。
#缓存策略
缓存不是只缓存最终答案。可以缓存 Embedding、文档解析结果、检索结果、问题改写结果、模型中间结果和最终答案。最终答案缓存要小心数据权限和知识更新；Embedding 缓存要和模型版本绑定；检索结果缓存要和索引版本绑定。回答时要说明缓存失效策略，否则容易出现旧知识回答新问题。
#模型部署选型
| 方案 | 优点 | 风险 |
|---|---|---|
| 第三方 API | 上手快、质量稳定、少运维 | 成本、数据合规、供应商依赖 |
| 云上托管模型 | 可控性更强，集成云监控 | 配置复杂，成本仍需优化 |
| 自建推理服务 | 数据可控，可深度优化 | GPU、运维、扩缩容压力大 |
| 本地/边缘模型 | 隐私好，低延迟 | 模型能力和设备资源受限 |
#推理服务指标
推理部署不只看能不能跑起来。核心指标包括首 Token 延迟、总响应时间、吞吐、并发、显存占用、冷启动时间、错误率和队列等待时间。对于流式场景，首 Token 延迟影响体感；对于批量任务，吞吐和队列更重要。
#成本告警设计
生产系统应有成本告警，例如单用户日预算、单业务日预算、单次请求 Token 上限、Agent 最大轮次和异常重试次数。成本异常时要能定位到业务、用户、模型、Prompt 版本和任务类型。否则月底账单异常，很难追责和优化。
#推理服务架构
自部署推理服务通常包含 API Server、Scheduler、KV Cache Manager、Model Worker、Tokenizer、Metrics Exporter 和存储层。API Server 兼容 OpenAI 或内部协议；Scheduler 负责连续批处理和队列；KV Cache Manager 管理长上下文显存；Worker 负责实际推理；Metrics 暴露吞吐、延迟、显存和错误率。
#vLLM 和高吞吐服务点
vLLM 的核心价值在于高吞吐服务，包括 PagedAttention、连续批处理、流式输出、OpenAI-compatible API、张量并行和前缀缓存。面试可以这样讲：长文档问答或固定系统 Prompt 场景适合 prefix caching；高并发短请求关注连续批处理；长上下文场景重点看 KV cache 和显存碎片。
#TensorRT-LLM 和推理优化
TensorRT-LLM 更偏 NVIDIA GPU 上的推理优化和部署，常见能力包括量化、批处理、KV cache 优化、多 GPU/多节点和与 Triton Inference Server 集成。面试不需要背参数，但要知道优化目标：降低首 Token 延迟，提高 tokens/sec，减少显存，稳定并发。
#容量评估公式
容量评估可以粗略拆成：请求量、平均输入 Token、平均输出 Token、模型大小、并发、P95 延迟和显存。生成式模型的瓶颈常常不是 QPS，而是 tokens/sec 和 KV cache。Agent 场景还要乘以平均步骤数；RAG 场景要把检索片段带来的输入 Token 算进去。
#线上指标面板
推理服务至少要看：请求数、排队时长、首 Token 延迟、总延迟、输入/输出 Token、tokens/sec、GPU 利用率、显存占用、KV cache 命中、错误率、限流次数和成本。业务侧再看成功率、用户采纳率和人工接管率。只看 GPU 利用率不够，因为用户体验主要由延迟和稳定性决定。
#候选人自检清单
- 能否在 2 分钟内讲清楚这个模块解决什么业务问题、为什么不是简单调用模型 API。
- 能否说清输入、处理、模型调用、后处理、评测、监控、回滚的完整链路。
- 能否给出至少一个真实项目指标，例如召回率、命中率、延迟、Token 成本、人工复核通过率或线上失败率。
- 能否解释一个失败案例：问题如何发现、如何定位、怎么修复、修复后用什么指标验证。
- 能否区分“学习过概念”和“真正落地过系统”，面试回答要用具体约束、权衡和数据支撑。