2小时完成大模型推理网关：一次AI Coding实战记录
2小时完成大模型推理网关：一次AI Coding实战记录
在蚂蚁集团2026春季校园招聘的AI Coding笔试中，我用2小时完成了一个面向大模型推理场景的HTTP网关。这篇文章记录了我的设计思路、技术实现和AI协作体会。
一、写在前面
这次笔试的题目很有意思：实现一个面向大模型推理场景的HTTP网关，核心挑战是在提升KV Cache命中率和防止单机过载之间做动态平衡。
简单说就是：
- 相同前缀的请求路由到同一后端 → 可以复用KV Cache，延迟更低
- 但如果所有相同前缀请求都堆到同一台机器 → 热点形成，排队加剧
如何在两者之间权衡？这就是这次项目的核心命题。
时间限制：2小时
工具：网页内置IDE + AI辅助编程
技术栈：Java 17 + Spring Boot 3.2 + Maven
二、核心设计
整体架构
客户端请求 → 网关入口 → 路由决策层 → 负载均衡层 → 后端实例池 ↓ 指标采集层（命中率、延迟、负载分布） 模块拆解
| 模块 | 实现方案 | 设计考量 |
|---|---|---|
| 路由策略 | 前缀匹配 + 降级分流 | 优先让相同前缀请求打到同一实例；过载时自动降级 |
| 负载均衡 | 动态权重算法 | 综合命中率、当前负载、健康状态计算权重 |
| 健康检查 | 主动探测 + 熔断降权 | 后端不可用时自动摘除，恢复后重新加入 |
| 指标统计 | 滑动窗口 + P95计算 | 实时统计成功率、延迟分布、命中率 |
三、核心亮点
1. 动态权重算法
如果只追求命中率，会把相同前缀请求都打到同一实例，导致过载。我的方案是设计了一个联合打分函数：
实例权重 = (命中率权重 × 历史命中率) + (负载权重 × (1 - 当前负载率)) - 命中率权重和负载权重可配置，支持不同场景调优
- 实例过载时（并发数 > 阈值），命中率权重动态降低
- 支持策略切换，可与纯轮询策略对比
阈值设定：默认并发阈值100，压测发现超过后延迟明显上升，以此作为过载信号。
2. 工程化实践
虽然是2小时的限时开发，但我特别注意了工程化要求：
- 配置与代码分离：后端列表、阈值、策略参数全部放在
application.yml，支持热加载 - 异常处理与降级：后端超时（3秒）自动降级到其他实例，全部失败时返回503
- 可观测性：实时输出请求总数、成功率、P95延迟、命中率、负载分布
- 代码可读性：核心类有职责注释，关键算法有设计说明，使用依赖注入便于测试
3. 压测验证
设计了4类测试场景，验证系统鲁棒性：
| 场景 | 测试方法 | 验证结果 |
|---|---|---|
| 正常流量 | 随机前缀并发请求 | 命中率约40%，负载相对均衡 |
| 热点前缀 | 80%请求使用同一前缀 | 动态权重将热点分散到2-3个实例，避免单机过载 |
| 过载场景 | 单实例并发数超阈值 | 自动降级分流，该实例权重降至最低 |
| 故障注入 | 手动停掉一个后端 | 自动摘除，流量平滑切换；恢复后重新加入 |
四、技术栈
| 组件 | 版本 | 说明 |
|---|---|---|
| Java | 17 | 稳定版本 |
| Spring Boot | 3.2.0 | 框架 |
| Maven | 3.8+ | 构建工具 |
| HTTP客户端 | RestClient (Spring 6.1+) | 内置，无额外依赖 |
五、AI协作体会
这是我在时间压力下第一次用AI完成完整项目，有几点真实体会：
成功做法
- 任务拆解先行：我先写出模块列表（路由、负载均衡、健康检查…），再让AI逐个生成，避免一次性让AI生成全部导致失控。
- 版本管理意识：第一版完成后，我让AI调整项目目录结构，结果引发了连锁错误。因为没有保存中间版本，只能让AI重新生成。这让我意识到：AI协作也需要版本管理，每完成一个模块就本地备份一次，增量修改优于全量重构。
- 上下文管理：当对话达到100K tokens时，我开始注意精简提示词。当AI开始“忘记”早期约定时，我会重新锚定：“还记得我们的项目结构吗？”
踩过的坑
- 全量重构风险大：让AI一次性大改代码很容易出问题，最好用git或手动备份checkpoint
- 依赖版本冲突：我先让AI生成
pom.xml确认无误，再生成代码 - AI会过度设计：有时会给简单功能添加复杂配置，需要及时纠正
核心感悟
AI确实极大提升了开发效率，2小时内就能从零搭建一个完整系统。但真正决定代码质量的，仍然是人的工程化判断——什么时候该解耦、边界条件如何处理、异常怎么兜底，这些AI不会主动帮你做，需要人来把关和调控。AI是高效的执行者，而人是负责决策和兜底的那个。
六、可优化方向
如果时间更充裕，我会考虑：
- 流式响应转发：目前是同步转发，可以用WebClient的Flux实现真正的流式转发
- 更精细的KV Cache感知：目前用字符串前缀近似，可以引入Trie树做更精确的匹配
- 分布式扩展：当前指标统计是内存的，可以用Redis做分布式聚合，支持多网关实例
七、总结
这次AI Coding笔试让我收获颇丰：
- 技术上：实现了一个有挑战的系统，加深了对网关设计、负载均衡、可观测性的理解
- 协作上：建立了“人机协作”的方法论——清晰拆解、增量迭代、版本管理、及时复盘
- 认知上：AI是强大的执行工具，但工程化思维（解耦、边界处理、可维护性）仍然是人的核心竞争力
最后想说的是：AI不会取代工程师，但会用AI的工程师一定会取代不会用的。关键是找到人和AI的最佳协作模式——各司其职，效率最高。
附录：项目结构
inference-gateway/ ├── pom.xml ├── src/main/java/com/ant/gateway/ │ ├── InferenceGatewayApplication.java │ ├── config/ # 配置类 │ ├── controller/ # HTTP入口 │ ├── model/ # 数据模型 │ ├── router/ # 路由策略（前缀匹配、降级） │ ├── loadbalancer/ # 负载均衡（动态权重、轮询） │ ├── health/ # 健康检查 │ ├── metrics/ # 指标统计 │ └── client/ # HTTP客户端 └── src/main/resources/ ├── application.yml # 配置文件 └── logback-spring.xml 
