推理服务架构：推理网格架构

可视化演示

经网关路由、调度器负载均衡到推理节点，演示推理网格如何实现跨模型智能流量调度与故障转移。

1. 路由策略设计

调度中心接线员接起电话，第一句话永远是：“病人什么症状？在哪个区？有没有指定医院？”这三个问题的答案，决定了救护车该往哪开。推理网格里的“接线员”就是路由组件（Router），它问的不是病人，而是请求：你调用哪个模型？来自哪个租户？对延迟有多敏感？这些问题被翻译成一条条路由规则。

技术上，每个推理请求都带着一组元数据，就像救护单上盖的章：model=llm、tenant=bank、priority=high。标签路由匹配就是按这些“章”把请求分发给挂了对应标签的节点组；内容感知路由更进一步，会解析请求载荷，判断它真正需要的是对话模型还是向量模型；优先级路由则为核心交易链路开绿灯，让高 SLA 请求插队到更优质的节点上。

这些规则要打分、排序、合并，才能从几十个候选节点里挑出最合适的一个。打分函数如下：

灰度发布是路由策略最实用的场景之一：新模型上线时，给它配一条 weight=5% 的规则，让一小撮流量先去“试运行”，监控无误后再逐步调高比例，出问题一键切回旧版本。就像调度中心先派一辆救护车去新合作的医院探路，确认能接诊再大规模转送。规则集中管理、动态下发，改一条规则，就能改变整座城市的救援方向。

2. 负载均衡算法

病分好了，车也派对了方向，但调度员还必须回答另一个问题：哪家医院此刻空床最多？医院的空床率每分钟都在变，一个 ICU 病人刚转进来，床位就少一张。推理节点的“空床率”就是在途请求数。负载均衡算法，就是调度中心墙上那块实时更新的空床表。

最简单的轮询算法像排班表——四个节点轮流接，公平且零开销，适合节点配置完全相同的场景。但生产环境的节点往往异构，于是有了最小连接数：永远选当前在途请求最少的节点，对应空床最多的医院；加权随机则给大医院更高概率，让能力强的节点多干活。更高级的自适应均衡会实时统计每个节点的延迟和错误率，动态调整权重——谁慢了就自动“降权”，谁快了就“加担子”。

在一个成熟网格里，路由和负载均衡是流水线关系：路由规则先筛出候选集，负载均衡再在候选集内精挑细选。加权最小连接数是两者的桥梁：

空床率是动态的——救护车还没到医院，ICU 就可能腾出床位。所以调度必须看实时水位，而不是静态排班表。这也解释了为什么“均匀分发”不是好策略：把 10 辆车平均派给 4 家能力悬殊的医院，只会让小医院爆满、大医院闲置。

3. 模型亲和调度

老调度员心里都有一张“王牌科室分布图”：心梗要送三院，因为那里导管室 24 小时待命；卒中要送二院，因为 CT 机就在急诊楼旁边。送对了，一步到位；送错了，转院路上黄金时间就没了。GPU 推理也有同样的“设备就位”问题——大模型加载到显存需要几十秒甚至几分钟，如果请求落到一个“模型还没热”的节点，光等加载就能让用户等到崩溃。

模型亲和调度的核心，就是把请求尽量派给“模型已经驻留显存”的节点。GPU 显存亲和是指目标模型已加载在该节点的显存中，请求到达即可推理；数据本地性是指输入数据（比如用户画像、检索出的文档片段）已经缓存在本区域，避免跨机房拉取；模型缓存复用则是多个租户共享同一个已加载的模型副本，让一次加载服务更多请求。更高阶的做法是搭建推理共享池，把多张 GPU 聚合成一个可弹性切分的池子，按需给不同模型分配显存，减少碎片化部署。

这三类因素需要综合打分：

好的调度员脑子里有一张动态更新的“王牌科室地图”，模型亲和调度就是网格的这张地图。它不追求所有模型出现在所有节点，而是让高频模型待在少数几个“王牌节点”上，再把匹配的请求精准送达——对医院和病人都是最优解。

4. 故障转移机制

再好的医院也会遇到突发停诊，再稳的 GPU 节点也会宕机。调度中心最深的觉悟是：故障不是意外，而是常态。面向失败设计，是网格架构的第一课。城市急救系统的成熟度，恰恰体现在医院停诊时那几分钟的从容切换上。

故障转移机制有四个层次。最底层是健康检查探针，像调度员每 30 秒给医院打一次电话确认“还开着吗”，连续几次打不通就把该节点从候选名单移除。第二层是自动重试，请求超时或连接失败时换一个节点重发，但必须配合指数退避——第一次等 100ms、第二次 200ms，不然会变成重试风暴。第三层是熔断器，当节点错误率超过阈值，直接打开开关快速失败，不再把流量送向注定失败的深渊。最后是跨区域容灾切换：整个集群都挂了，就把流量转移到另一个区域的数据中心。

熔断器的核心判定逻辑非常直观：

就像调度中心绝不会盯着打不通的电话反复重拨——那是浪费生命。熔断器让系统在故障面前“短暂失忆”，给故障节点喘息恢复的时间；等探针确认它重新营业，才把流量慢慢放回来。

5. 性能基准测试

每年，市政府都要给急救调度中心做年度考核：平均出车时间达标了没有？但市民真正关心的，是那个最倒霉的夜晚——救护车 40 分钟才到。平均出车时间好看，掩盖不了 5% 的极端等待。推理网格的性能考核，同样不能只看平均值。

基准测试要盯四类指标：延迟分位数（P50/P95/P99），分别代表典型体验、较差体验和最差体验；吞吐量（QPS），即系统每秒能处理多少推理请求；长尾时延，用 P99 减去 P50 的差值衡量尾部分布有多“胖”；成本效率，即每张 GPU 卡每秒能撑起多少请求，这是老板最关心的 ROI。测试方法也有讲究：固定请求率压测找稳定性，阶梯加压找吞吐拐点，混合模型负载模拟真实流量。

其中 P99 的定义精确又优雅：

打车时你平均等 5 分钟，但深夜可能等了半小时——这个“半小时”才是用户真实记住的体验。推理网格的优化同理：平均延迟是给汇报用的，P99 才是给用户承诺的。

6. 调优实践方法

急救调度中心要应对早晚高峰：白天的写字楼片区配 20 辆救护车，深夜只需 5 辆；周末的体育场办演唱会，还得临时从邻区借调。推理流量同样是波动的——白天上班族的问答请求暴涨，深夜跌到谷底。固定的资源池要么高峰期不够用，要么低谷期浪费钱。

调优实践的第一板斧是弹性扩缩容：按 QPS 或 GPU 利用率自动增减节点，但要设置冷却时间防止流量毛刺引起抖动。第二板斧是预热缓冲池：把常用模型常驻显存，冷门模型提前预加载，用户请求永远不撞上“冷启动”的几十秒。第三板斧是动态批处理：把短时间内的并发请求攒成一个 batch 一次性过 GPU，摊薄显存搬运开销，用可控的排队延迟换更高的吞吐。最后还有缓存分层：结果缓存、KV Cache、前缀缓存各司其职，让相似请求直接命中走捷径。

动态批处理的收益可以用一个简洁的公式刻画：

让救护车引擎不熄火地等在街角、让顺路的病人拼一辆车、让常见病直接用标准方案秒回——调优的本质，是用可控的等待换取吞吐，像调度员拿捏“压多少单才不误事”的分寸。每一次调参，都是在延迟、吞吐和成本三者之间重新找平衡点。

7. 多云兼容迁移

城市之间会签医疗互助协议：邻市急救车满了，可以把病人转过来。但真到执行那天才发现，人家的急救电话频率不一样、医院编码规则不同、电子病历系统互不兼容。推理网格的多云部署，面临着完全相同的“跨系统对接”难题。

厂商差异是第一个坑：各云厂商的 LoadBalancer、Ingress、GPU 实例规格、Kubernetes 版本语义都不完全一致，连“健康检查”的配置写法都各有脾气。第二个坑是模型资产的兼容性：推理引擎版本、模型权重格式、镜像打包方式都可能不通用。破局要靠标准化 API——用统一的网关抽象层屏蔽底层差异，让上层调度逻辑只认一套接口。迁移前必须做系统评估：把所有功能用例按重要性加权打分，跑一轮完整回归。最后用灰度迁移分步放量：

调度协议统一了，急救车才能跨城开进邻市医院，而不被门口保安拦下。多云迁移不是“搬家”，是让两套系统说同一种语言——先把协议定了、用例跑通了、灰度放量了，才谈得上真正的多云自由。

AI 应用场景

Python 演示

import randomimport statistics  class InferenceNode:    def __init__(self, name, model, capacity):        self.name = name        self.model = model        self.capacity = capacity        self.inflight = 0        self.failed = False        self.served = 0     def can_serve(self, model):        return (self.model == model and not self.failed                and self.inflight < self.capacity)  class InferenceMesh:    def __init__(self, nodes):        self.nodes = nodes        self.dropped = 0     def route(self, model):        alive = [n for n in self.nodes if n.can_serve(model)]        if not alive:            self.dropped += 1            return None        best = min(alive, key=lambda n: n.inflight / n.capacity)        best.inflight += 1        best.served += 1        return best     def simulate(self, requests, fail_prob=0.02):        latencies = []        for i, model in enumerate(requests):            if i % 50 == 0 and i > 0:                victim = random.choice(self.nodes)                victim.failed = True            node = self.route(model)            if node is None:                continue            load_factor = node.inflight / node.capacity            latency = 0.08 + 0.04 * load_factor + random.uniform(0, 0.01)            latencies.append(latency)            node.inflight -= 1        p99 = sorted(latencies)[int(len(latencies) * 0.99) - 1]        return {            "throughput_qps": len(latencies) / 30.0,            "p50": statistics.median(latencies),            "p99": p99,            "dropped": self.dropped,        }  if __name__ == "__main__":    mesh = InferenceMesh([        InferenceNode("host-a", "llm", 8),        InferenceNode("host-b", "llm", 6),        InferenceNode("host-c", "vision", 6),        InferenceNode("host-d", "llm", 10),    ])    requests = ["llm"] * 600 + ["vision"] * 150    random.shuffle(requests)    result = mesh.simulate(requests)    print(result)

1. alive = [n for n in self.nodes if n.can_serve(model)]先用路由条件过滤候选节点：模型匹配、未故障、未满载。
2. best = min(alive, key=lambda n: n.inflight / n.capacity)最小连接数算法的核心：选在途负载率最低的节点。
3. if i % 50 == 0 and i > 0:每 50 个请求随机让一个节点故障，模拟生产环境的“故障是常态”。
4. latency = 0.08 + 0.04 * load_factor延迟随节点负载线性上升，体现排队效应。
5. p99 = sorted(latencies)[int(len(latencies) * 0.99) - 1]排序后取第 99 百分位，与正文 P99 定义一致。

常见误区

面试题