新加坡与马来西亚企业如何评估 AI API 经销商？七个可验证判断点

很多人把 AI API 经销商和代充、虚拟卡归成一类，以为重点是能不能用更低的价格拿到额度。实际情况是，经销商拿自己的上游合约提供服务，你拿到的除了调用额度，还有合同、账单、支持分工和一条退出路径。要判断一家经销商能不能进采购流程，看七个可以验证的点：上游关系、加价与收入来源、付款与账务、模型与容量、支持责任、key 与数据归属、退出与迁移。每一项都要有带日期的书面证据，报价才有比较的基础；缺哪一项，就在内部记录里写成未确认，不要用口头承诺补位。

直购官方 API 和找经销商，采购上到底差在哪？

差别最后都落在四件事由谁负责：合同跟谁签、发票谁开、故障找谁、退出时 key 和账怎么处理。技术参数你自己压测就能得到答案，这四项只能靠对方把文件拿出来。

直购：账号、账单和支持都在自己手上

在新加坡或马来西亚注册的公司直接向模型厂商开通账号，通常自己完成主体验证，自己绑定付款方式，自己承接用量上限和账单，出故障时也由自己的工程团队对接厂商的支持渠道。关系短，责任清楚，出问题不用经过第三方转述。代价是每接一家厂商就多一套账号、一份对账单和一个支持入口，模型一多，采购和运维要维护的对接面就跟着变宽。

经销商：中间方接走上游合约、账务与支持

经销商以自己的上游合约提供调用服务，企业在经销商这边管理接入和账务。核对重点是三件事：谁承担合同责任、账单与付款能不能对应、故障由谁受理。MixRoute 由新加坡公司 ELITE CLOUD PTE. LTD. 运营，合同主体是可以直接核对的。

四条要重新谈的线

换成经销商之后，这四条线要让对方单独交底，一份通用报价表回答不了：

• 合同线：谁和上游签、合约期限多长、你的用量在合约里算什么。
• 账务线：发票谁开、币别是什么、账期几天。
• 支持线：故障时谁值班、升级路径有几级。
• 退出线：key 和账单数据归谁、换端点要动多少代码。

答不上来的先写进询价函的待确认栏，再决定哪几项必须在签约前补齐。有些团队是先用第三方通道把产品跑起来，等量涨上来准备签合同，才发现手上没有可核对的主体和账务凭证，这时候回头补的代价比一开始就问清楚高得多。

两条路径的差别也不只在价格。直购时你手里有厂商的账号和工单号；换成经销商，你手里是合同、发票和一份写明的支持分工。采购要准备的材料跟着换，一边是账号和付款信息，另一边是主体证明、开票资料和验收条件。

先把采购范围钉住，再谈条件

后面的七项检查表都以在新加坡或马来西亚注册、能签合同、能走对公付款的企业为前提。如果你是以个人身份找代充或虚拟卡，这份清单帮不上忙，那条路径给不出可核对的主体、账务凭证和支持责任。

另一个容易混的地方是网关和聚合平台。这两类东西各自负责什么，网关与聚合平台的差别这篇讲得更细，看完再去看经销商的报价会顺很多。

评估经销商的七个判断点：每一项怎么核对？

七项可以同时问，不用一项谈完再问下一项。每一项都要一份能落到纸面的东西：上游合约、加价与收入来源、付款与账务范围、模型与端点清单及容量条件、支持分工、key 与数据归属、退出与迁移步骤。对方拿不出来的，就在记录里写未确认，别用口头承诺先过关。

硬条件先看，模型清单可以后补

合同主体、开票信息、容量条件和退出路径属于采购硬条件。这几项对方给不出可核对的东西，后面的价格比较就没有意义，比的只是两个数字各自站在什么分母上。模型与端点清单这类可以后补，同样要带日期，模型上下线是常态，三个月前的截图不能拿来做今年的采购依据。

第⑥项要问得细一点

调用 key 由谁创建、谁能吊销，账单和日志由谁保管、保留多久、怎么导出，这些属于第⑥项。持有 key 本身不代表可以带走历史记录，导出范围要单独确认。这一项关系到权限，也关系到日后查账时你手上有没有东西可以对照。

一页询价表怎么用

把七项做成一页表，同时附上公司所在地、模型与端点、预计用量、付款和凭证要求，请对方逐项填写实际条件、证明或说明的日期，你这一侧再标记是否符合需求。材料齐全但条件不合用的方案，同样可以排除。

首次询价可以同时索取费率表与服务条件。比较时先对齐模型、输入与输出用量、结算币种和附加费，价格才有共同基准。

付款、发票与税务：新马公司能确认到哪一步？

先给结论：通用企业付款路径已经确认，本地发票和税务条件还没有。MixRoute 企业方案主要使用银行电汇，可提供商业发票与弹性账期；新加坡和马来西亚的开票主体、票据类型、币别与税务文件，按所在地与方案向 Sales 确认。前者可以直接写进采购计划，后者要先拿到书面答复，比价时把单价、支付渠道费用与税务条件分开记，整份报价的判断才不会被一个美元数字带着走。

已经确认的通用付款路径

银行电汇、商业发票和弹性账期这三项属于通用条件，适用于企业方案。落到操作上就是三件事：收款账户信息能不能提前拿到，发票抬头和合同主体对不对得上，账期在合同里有没有写明。这三项能核对，对公付款就能排进财务日历，不会卡在月底结算。

市场专属的问题交给 Sales 定

向 Sales 一次确认开票主体、票据类型、币别与账期，再把答复放进采购比较表。如果你公司走的是对公付款，这几项最好在询价的同一轮问完，分成几轮问，内部审批的时间会被拉长。

账期与币别会改变比价结果

同一个美元报价，账期三十天和现结，对现金流的影响不一样；票据类型不同，财务能不能入账也不一样。比价表里除了模型单价，留三列给结算币别、账期和票据类型。这三列空着的报价先按未确认处理，等 Sales 回复后再补进去，再和直购方案放在一起比。

询价函里给结算条件留一行：币别、账期、票据类型、开票主体。四个格子里只要有一个空着，这份报价就只能当参考价，进不了合同评审。

容量、模型和支持：要厂商拿出什么证据？

三样东西：模型清单与端点支持，并发或保留容量的书面条件及日期，故障时的支持分工。宣传页上的高并发和自动切换，如果没有公开的方法论，只能算厂商自述，进不了验证过的性能那一栏。

模型清单与端点支持

清单要能对上三层：模型名、端点类型，以及这个模型在你要用的端点上是否可用。一个端点上能跑通，不代表另一个端点上也有同一个模型，所以要一个端点一个端点地核。清单还要带日期。端点支持最好让对方用一条可复现的请求示范，别只在表格里打勾。

容量与并发要落到书面条件

容量最容易被口头承诺糊过去。MixRoute 提供预购 provisioned throughput 的保留容量选项，它属于企业版套餐的权益：定价页写明每月消费满 20,000 美元，或单次充值满 30,000 美元，就有 Reserve Capacity 的使用资格；容量规模与条款再找业务确认，也不该和降价承诺混在一起谈。看清保留容量的访问条件，再判断要不要把它写进合同条款。

如果你的应用有固定的高峰时段，或者延迟直接决定用户体验，容量条件尤其要写成条款。对方给的并发数是在哪个时段、哪些模型上的口径，写进合同才算数，写在宣传页上只能当参考。

支持责任分工

把故障场景直接写出来问：上游厂商那侧出问题，谁负责对外沟通，走什么渠道，多久升级一次，有没有值班联系人。这条答不上来，前面谈的容量和模型就少一层保障。可靠性宣传则按厂商自述标注出处。举例来说，CloseAI 在 2023 年的一则公告里称，OpenAI 服务发生大规模故障期间系统自动切换到 Azure OpenAI 的美国数据中心，并称可承载千万级 TPM 的高并发调用；这些是厂商自述，没有公开方法论时，不能当作已验证的延迟、429 率或切换时长数据。

还有一个具体问题要问：你的故障工单进的是哪一方的系统。经销商能自己答复，和只能转述上游答复，响应路径和责任边界不一样。让对方写明受理渠道、值班时间和升级联系人，再判断这条支持路径够不够支撑你的业务。

报价里的“一刀”和折扣，为什么不能直接比？

因为分母不同。先把同一个模型名、同一条通道分组、同一种计费单位和币别对齐，再比数字。折扣打在不同对象上时，两个百分数放在一起说明不了什么。

三种常见的标价基准

简体中文的中转列表里，0.6R 一刀、1R 一刀这类写法说的是用人民币给 1 美元官方额度标价，有的还按 AZ 分组和官转分组各报一个价。另一类平台直接写官方价打 65.8% 到 77.9% 折扣，第三类写 Top Models 40% OFF。这三种句子的分母各不相同：一个是中转单位，一个是官方模型价格，一个是充值折算。看到便宜的那句话，先问它便宜在哪个分母上。

这类标价写法在公开的中转平台上会随时调整。真正要比的，是你那条请求路径上的单价乘以用量。

对齐之后再看具体报价

MixRoute 提供 250+ 模型的单一端点，页面以美元显示价格，储值与模型推理不加价，收入来自上游经销利润。Smart Routing 全面免费，不收路由服务费，只需支付实际选用模型的用量费用。比价时把模型费用和充值费用分别列出，详见定价页与Smart Routing 收费说明。

比价的三步动作

1. 把两边的模型名写成同一个名字。
2. 问清计价单位是官方模型价格、充值金额，还是中转单位。
3. 把币别统一到页面显示的美元口径，再决定要不要谈量。

用把自家用量换成同一口径的估算工具算一遍；智能路由这一项的费用口径是免费、不收路由服务费，比价表里只需要列模型用量。

量起来之后再看一次报价

季度用量翻倍的时候，原来那份按量报价的性价比会变，这时候可以回头谈承诺量、账期和容量条件。谈判的筹码不在你比过几家，而在你手上有没有一份写得清楚的用量清单。清单越具体，对方越难用一句规模很大来回答。

哪些做法不该写进采购方案？

虚假身份、虚假账单资料、绕过平台验证的做法，都不该进企业采购方案。第三方付款或某种卡是否受理，按平台实际规则确认。无论用哪种方式，都要有明确的合同主体、付款记录和支持责任，否则出了问题连找谁都不知道。

这类路径缺的是可核对的条件

如果对方无法说明合同主体、付款记录与故障受理方式，先把这三项补齐，再往下谈价格。服务范围按对方书面写下的内容算，缺的部分留空等下一轮，不要替对方补完。

把范围写进询价函

询价函里写清楚你的注册地、结算币别、需要的模型与端点和预计用量，让对方按这四项回答，而不是回一份通用价格表。这样收到的答复本身就带对照基准，不用你在几份格式不同的报价之间猜。

退出和迁移：签约前先看好后路

签约前先写好退出清单：key 归谁、账单和日志怎么导出、换端点要改什么。迁到兼容 OpenAI SDK 的网关通常只改 base URL，但参数映射要逐项测试。

迁移要改什么

MixRoute 的迁移口径是把 base URL 指向 https://api.mixroute.ai/v1，OpenAI SDK 兼容，模型名不变。接口层兼容不等于每个参数逐字段等价。切换前把你在用的参数列出来，用真实请求逐个验证，尤其是超时、输出长度上限和模型特有参数这类会改变行为的设置，别假定两边同名参数的行为一致。

退出成本清单

退出成本由三块构成：上游 key 的归属，也就是账号和 key 是经销商的还是你的；账单与日志能不能导出，导出之后能不能对上内部账；端点切换要改多少代码和配置。这三块在签约前问清楚，成本就是可预算的；问不清楚，它就会变成合同里别人说了算的条款。

内部这一侧也要一起算：谁改配置、谁换密钥、谁做验收。把这三个角色写进切换计划，演练当天才不会出现改完了没人测的情况。

切换前的最后一次演练

决定切换之前，用一小部分真实流量走一遍新端点，把请求参数、返回结构和错误码记下来，和旧路径逐条对照。这一步花的时间不多，能把大多数切换当天的意外提前暴露出来。演练通过之后再安排正式的账号和账单迁移。

FAQ

新加坡与马来西亚企业找 AI API 经销商，第一件事确认什么？

先确认合同主体，也就是这份合同跟谁签、它和上游是什么关系。转钱和接 API 之前，先拿到主体名称和一份可核对的答复口径，后面谈容量、支持与退出条件才有落点。如果连合同主体都问不出来，这家可以先放一放，价格谈得再细也落不到纸上。

不同代理商的报价为什么不能直接比较？

因为各自的计费基准不一样。有的按官方价打折，有的按充值金额折算，还有的按通道分组单独定价，加上模型名和币种各不相同，把两个百分数放在一起，只能说明它们的分母不同。先固定同一个模型、同一条通道、同一种计价单位和币别，再比数字，得出的结果才对你的用量有意义。

MixRoute 能给新加坡或马来西亚公司开本地发票吗？

要看所在地和方案，现在还不能直接答会或不会。可以确定的是企业方案主要走银行电汇，可提供商业发票与弹性账期；新加坡和马来西亚本地的开票主体与税务文件仍需向 Sales 确认。询价时把票据类型、币种、账期和开票主体一次列清楚，财务那边才能提前排期，不会等到付款那天才发现资料不齐。

MixRoute 的报价用什么币种？

页面价格以美元显示。要拿不同币种的报价来比，先统一到同一个日期、同一个来源的汇率，再把银行或支付渠道实际收的费用单独列出来。这两个数字分开记，你才知道差额是汇率造成的，还是渠道费造成的。汇率每天都在动，比价表上要写清楚用的是哪一天的。

保留容量适合什么样的团队？

有稳定的大体量用量、愿意提前预购 provisioned throughput 的团队比较适合。它属于企业版套餐的权益，定价页写明每月消费满 20,000 美元或单次充值满 30,000 美元就有使用资格，也不该和降价承诺混在一起谈。采购时把容量条件、访问门槛和期限写成书面条款，再和按量计费那条路径分开评估，两条路径各有各的适用场景。

从直购或其他中转站迁移到 MixRoute 要改多少东西？

按官方口径，把 base URL 指向 https://api.mixroute.ai/v1，OpenAI SDK 兼容，模型名不变。工作量主要不在改地址，而在参数。接口兼容不等于每个字段逐项等价，超时、输出长度上限、模型特有参数这些会改变行为的设置，都要用真实请求跑一遍。先拿一小部分流量演练，再正式切换。

宣传页上的高并发和故障切换数字能当采购依据吗？

不能直接当。这类数字属于厂商自述，要带上日期、范围和公开的方法论，才能进比较表。没有方法论的时候，把它和合同里写明的容量条件分开记，一边是宣传口径，一边是条款，签合同时起作用的是后者。你也可以直接问对方这份并发数字对应哪些模型、哪个时段，答不上来就先按未确认处理。