跳到主要内容
Quark

解决方案 · 工作负载

能熬过上游故障的模型调用。

您的代码只调用一个端点;其后是带回退的有序 upstream 链。上游故障变成一次路由决策,而不是一场作战会议。

痛点

哪里最疼。

您的产品在每次请求时调用一个模型。当那个上游犯了错,您的产品跟着遭殃 — 除非切换到备用只是一次路由改动,而不是一次事故。

而当账单到来,花销应当向一把 key 交代,而不是向一团谜交代。

在 Quark 上

在这里如何运转。

把每个模型放在 Gateway 上的一个别名后面,以一条有序 upstream 链支撑。Gateway 按回退顺序尝试该链,并核实模型真的在服务 — 从数据路径验证,而非凭配置条目臆断。

附上按 key 的限额,每次补全都归属到发起它的 key — 上游切换悄无声息,花销始终可读。

所用组件

谁来干活。

每个场景都映射到目录中真实存在的产品——顺着任意一件去到它的页面。

路由、有序上游链、备用、限额与用量归因。

上游凭证以封存引用存在,绝不在配置中留明文。

按 key 的汇总让每次补全都对自己有交代。

恰好 3 个产品完成这项工作——Foundation 始终在底层开启。

联系我们

和我们聊聊运行 Quark。

告诉我们您的工作负载 — 我们会展示您自己的云能做什么。