三年大模型开发经验，被一个“重复生成扣费”问题干沉默了… #大模型面试 #AI大模型 #Agent #Ai #大模型

你说你开发过大模型对话系统，但我问你，用户在生成页面连续点了两次发送按钮，你的后端如何保证相同的prompt只调用一次大模型、不重复扣费？ 刚面了一个三年经验的大模型后端，我问他大模型接口防重复调用，看似简单，但要考虑分布式部署、推理超时、消息队列重复消费、网关重试等场景，从前端拦截到落库幂等怎么设计？ 他想了一下说，前端加锁，点一次后按钮置灰转loading，同时后端用Redis分布式锁，Key拼用户ID加会话ID，推理完释放锁。 我顺着他的话继续问，前端按钮置灰很容易绕过，比如直接重放两次HTTP请求，这个防御不算数，那你的Redis锁能兜住吗？大模型单次推理动辄几秒到几十秒，如果第一次请求推理时间很长，超过了锁的过期时间，锁自动释放了，这时第二次请求进来也拿到了锁，两个请求同时调用大模型，重复扣费、重复生成，幂等性怎么保证？ 如果锁没有超时问题，但第一次请求已经将会话状态更新为生成中，第二次请求如何判断这个状态？如果状态机设计有漏洞，第二次请求以为可以执行，就会重复调用大模型，你有没有考虑过不用分布式锁的幂等方案，比如基于数据库的唯一约束，它的优缺点是什么？如果核心对话表已经不允许加唯一索引，历史数据动不了，你怎么办？ 他瞬间慌了，说可以把锁时间设长点，然后说不依赖锁的话。 可以用 SELECT FOR UPDATE 悲观锁。 但问到唯一索引的历史表兼容方案，完全没思路，面试到这里基本就可以结束了。 这正是会用Redis锁和能设计绝对靠谱的大模型幂等服务的关键分水岭。 很多人以为加个 SET NX 锁就解决了大模型重复调用的问题，但一遇到锁超时、状态机异常跳转、遗留表改不了结构这些真实生产问题就崩了。 面试官问这个问题，考察的不是你会不会用 SET NX，而是你在任何异常重试、网络抖动下都保证大模型只调用一次，费用只扣1，结果一致。 真正能通过面试的大模型幂等设计，必须吃透三层核心逻辑。 如果这道题你也不会回答的话，我整理了让大厂面试官沉默的备考题库，涵盖大模型基础面试、RAG、ViT、Transformer、Deep Think、Agent、项目方案面试题等等，只要是我粉丝留下666打包带走。 Nice。 第一层，先明确幂等的范围和失效场景。幂等不是简单同一个请求只处理一次，而是同一业务语义的重复请求，返回相同结果且不产生副作用。 网络超时导致客户端重试，服务端已经调用大模型成功，重试时不能重复调用；MQ重复消费，消费者手动ACK前挂了，推理任务被重新投递；网关重试，业务服务已执行，但响应超时，网关层触发重试；用户手动刷新重发，同一段Prompt重复提交。 第二层。 选一套核心方案落地多种场景。 以唯一请求ID加数据库唯一约束为最可靠极限，辅以状态机。 请求ID生成规则：客户端生成全局唯一request下发ID，或服务端基于用户ID加Prompt哈希生成业务唯一键。 建立一张大模型幂等请求表，字段包含request_id、prompt_hash、status、response_content、token_usage。 业务处理前，先向该表插入记录。插入成功则继续调用大模型；插入失败，直接返回已缓存的生成结果和扣费记录。 用状态机推进任务状态流转：待生成、生成中、生成成功、生成失败。每次状态变更必须基于当前状态执行，例如：update llm_task set status = 生成中 where task_id = xx and status = 待生成。 利用数据库行锁，第一条请求更新成功，第二条请求影响行数为0，直接判定为重复请求，返回已有结果。 第三层生产落地的异常处理细节：锁超时问题上，分布式锁只做并发限流，不承担幂等能力，真正的幂等依靠数据库唯一约束加状态机兜底。 锁超时后，即使第二个请求进入，插入唯一键时也会失败，不会重复调用大模型。 针对无法加唯一索引的历史业务表，新建一张独立的大模型幂等辅助表，和核心业务表对接，通过request_id唯一约束保证幂等。 大模型调用和幂等记录落库操作，要写在同一个本地事务或分布式事务中。 幂等记录的长期存储方面，已完成且超过7天的记录，可迁移到历史表或归档，但要保证归档期间不会有重试请求进来，同时做好监控：唯一键冲突次数、状态机非法跳转告警、幂等表增长趋势、重复调用拦截率。 如果数据库幂等表写入失败，业务可降级为基于Redis的临时幂等记录，加长时间过期，后续配合账单对账兜底。 如果大模型厂商侧返回异常，要做好失败重试的幂等校验，避免重试时重复计费。 这个就叫专业。讲到这里大家就明白了。面试官问大模型接口幂等性，根本不是考你会不会用Redis锁，核心考察三点：能不能识别锁超时、状态机并发重入、历史表无法改结构等真实场景；知不知道不依赖分布式锁，如何实现绝对幂等；有没有唯一约束设计、幂等表拆分、状态机流转等工程落地经验。普通开发只会一把Redis锁，锁超时只会把时间设长一点，大厂开发能徒手设计一套基于唯一约束加状态机的大模型幂等服务，扛得住重复点击、MQ重试、网关超时，既不重复扣费，也不重复消耗算力。