模型上线这事儿，做传统软件的同事可能觉得稀松平常——上个新版本，蓝绿部署、滚动更新，半小时搞定。可一换到大模型推理服务，画风突变：模型文件动辄几十上百 GB，显存得整卡整卡地占，一次推理几十毫秒到几秒，线上一个 request 都不许断。我见过太多团队，模型训完直接一把梭替换线上推理服务，结果新版本在评测集上分高，真实流量上翻车，回滚又没留资源，线上直接躺平一晚上。说白了，大模型推理也得讲版本管理和灰度发布，只是这事的复杂度比传统服务高出一个量级。这篇把我踩过的坑和现在主流团队的做法一次说清楚，最后给套能落地的租机方案。

核心结论先放前面：

• 推理服务必须搞多版本并存，别做"替换式"上线——新旧版本并行跑，流量按比例切，出问题立刻切回去，是唯一对用户体感负责的玩法。
• 灰度发布的本质是"多付一份算力"，新旧模型同时驻留显存，规划资源时得把这一份算进去，别拿"上线就替换"的心态去租机器。
• 监控和自动回滚比模型本身更重要，延迟、错误率、首 token 时间这些指标不看，灰度就是赌博。
• 小团队别一上来就租 8 卡 H100 做灰度——单版本单卡 T4（¥900/月）或 RTX3090（¥1750/月）够用就先跑起来，真有流量了再升级到 A100 多卡，钱要花在刀刃上。

一、先搞明白：模型版本管理、灰度发布、金丝雀到底在说啥

1.1 模型版本管理：不是 git 管代码，是"线上允许同时住几个模型"

传统说法里，模型版本管理指的是把训练好的模型按版本号存档，记录超参、数据版本、评测分数，好复现、好回溯。这套在训练侧当然要做，但推理侧的版本管理完全是另一码事——它要解决的是：线上同时有几个模型版本在服务，每个版本各占多少显存，流量怎么分给它们，出问题怎么把一个版本摘掉。

给你个具体画面。你的对话机器人跑的是 Qwen2.5-7B，v1.2 版在线上稳定运行，日请求几百万。现在团队微调出一个 v1.3，评测分高了两三个点，想上。合理的做法不是停掉 v1.2、加载 v1.3，而是：v1.2 和 v1.3 各占一块卡，先把 5% 的流量导给 v1.3，跑一两天看指标，没问题再逐步加到 20%、50%、100%。这个过程里，v1.2 始终在线，随时能一键切回。

这就是推理侧版本管理和训练侧的本质区别：训练侧是"存档"，推理侧是"共存"。多版本共存、AB 测试、一键回滚，这三件事是绑在一起说的。

1.2 灰度发布与金丝雀：流量切分这事，传统方案搬不过来

灰度发布（Canary Release）名字源自煤矿里的金丝雀——先放一只鸟进矿井，鸟死了说明有毒气。放到推理服务上，就是先让一小撮真实流量尝尝新模型，观察它在真实用户场景下的表现，再决定放不放量。

传统 Web 服务的灰度，靠 Nginx/网关按 IP 或 header 切流量就够了，成本极低。但大模型推理不一样：每个模型版本都要独占一块或几块显存，GPU 是物理资源，不能像容器那样一个请求一个请求地"微切"。你至少得让新旧两个版本同时驻留，才谈得上切流量。这也是为什么我开头说"灰度发布的本质是多付一份算力"——这不是网关配置能解决的，是真金白银的显卡预算。

流量切分的粒度也分几种。粗一点按比例：网关随机把 5% 的请求打到 v1.3；细一点按用户或会话：固定把某个用户 ID 区间引流到新版本，好处是同一个用户对话不撕裂——不会上一条是老模型答的、下一条变新模型。做客服、AI 助手这类有连续上下文的场景，我强烈建议按会话切，否则用户能明显感觉到"人格分裂"。

1.3 为什么推理侧特别需要灰度——你不看指标，就等着被指标打脸

大模型评测有个著名难题：离线评测分数高，不代表线上用户觉得好。逻辑推理变强了，可能话痨变多了；指令遵循变强了，可能风格变严肃了；更麻烦的是，评测集里没有的 edge case，真实流量里到处都是。2025 年之后很多团队已经默认：不上灰度直接全量替换的模型上线，等于裸奔。

还有一层更现实的：模型推理的"bug"往往是软性的，不是报错，是回答变蠢、变啰嗦、拒绝回答变多。这种问题只能靠线上真实指标发现，比如拒绝率（refusal rate）、回答长度、平均分、用户反馈。所以灰度发布不是"上线流程的仪式感"，它是你唯一能在"伤害用户"之前发现问题的窗口。

1.4 灰度、AB 测试、蓝绿部署——三兄弟别搞混

这三个词经常被混着用，实际是三种不同的机制，我顺手给你掰扯清楚。蓝绿部署，是准备两套完全一样的生产环境，绿环境跑旧版本、蓝环境跑新版本，切换时整组流量直接倒到蓝环境，回滚就是再倒回去——这是"整体切换"，适合无状态服务，代价是两倍硬件。AB 测试，核心目的是"比较两个版本谁更好"，通常配合埋点、用户分组和统计学判断，跑完一轮给结论，未必是为了长期共存。灰度发布，重心在"渐进放量 + 随时回滚"，流量按 5%→30%→100% 阶梯推进，出问题即刻切回，它更像是"带刹车的上线过程"。

落到大模型推理上，这三者的关系是：灰度是主流程，AB 测试是灰度期间的评估手段，蓝绿部署是硬件冗余足够时的简化版。我见过有团队拿蓝绿部署的思路做推理——两台整机各跑一个版本，切换时 DNS 或网关全量切换。这也行，但成本直接翻倍，且冷切换时有秒级连接中断。对小团队我一般建议：先跑通灰度流程，AB 对比指标嵌入灰度观察窗，等有钱了再考虑蓝绿那套豪华配置。

二、灰度发布对推理集群提了什么硬要求

2.1 多版本共存：你的显存规划得按"两个模型"来算

单机单卡跑一个 7B 模型，很多人觉得简单。但要灰度，你要同时跑 7B 的 v1.2 和 v1.3，那就是两块卡、两份显存。这里有个新手最容易犯的错：用"一个模型需要多少显存"来算集群规模，而不是用"线上最多同时驻留几个版本"来算。

怎么估显存？以现在最主流的 Llama 3.1 8B、Qwen2.5-7B 这类 7-8B 模型为例，FP16 权重约 14-16GB，加上 KV Cache、激活值、CUDA context，单副本至少 20-24GB 显存打底。T4 的 16GB 会非常吃紧，RTX3090 的 24GB 刚好卡线，A100 40G 就从容很多。要是上 70B 级别的模型，FP16 单权重就要 140GB，只能上多卡或量化——80G 的 A100 也得两张拼起来跑。

结论很直接：做灰度，算力需求近似翻倍。旧版本一份，新版本一份，回滚时旧版本还得在线待命。这不是浪费，是你为"线上安全"付的保险费。

补一个量化选型的实操判断：同样是灰度两个 7B 版本，你可以两块卡各跑 FP16，也可以一块 A100 40G 上用 INT8 同时挤两个版本。前者显存宽裕、质量无损、并发高；后者省钱但 KV Cache 竞争激烈，并发一高延迟就飘。我自己的倾向是：生产环境灰度别抠量化这口——省下的显存换不来稳定，FP16 的两个副本才是标准答案。量化更适合留给"兜底版本"或者验证性测试，正式流量的灰度，让模型全精度跑，出问题的时候你才知道是模型问题还是量化问题，排查成本低得多。

2.2 流量切分与版本路由：网关层要做的事

灰度发布在架构上分两层。下层是模型服务层，每个版本独立部署，各自加载到 GPU 上；上层是路由网关层，负责把请求按策略分发到不同版本。中间还要有一套配置中心，管理版本号和流量权重的映射关系——改权重不能重启服务，要热更新。

对推理集群的要求就是：至少两个版本的推理服务实例能同时跑，且能被网关独立寻址。容器化部署（Docker + 推理服务框架）是标配，K8s 不是必须的，中小团队用 Docker Compose + 一个负载均衡也能凑合，但前提是机器够。

这里提醒一句：流量权重改得再丝滑，底层显存不够，权重就是纸面数字。你给 v1.3 配 30% 权重，但它的卡还没就绪，网关只能干等。所以版本切换的"引擎"是算力池，不是路由表。这也是为什么我反复强调资源规划先行。

2.3 回滚要预留资源吗？要，而且不是"预留一点"

很多团队回滚失败，不是模型文件没了，而是没有资源可回。全量替换式上线，v1.3 挂了要回 v1.2，得现场加载模型、初始化推理引擎、预热——慢的话十几分钟，快的话也要几分钟。这在传统服务里不可接受，在推理服务里更是灾难，因为每多一分钟，线上就在用坏模型服务。

所以正确姿势是：灰度期间，旧版本永远保持在线、保持热备。新版本权重加到 100% 之前，旧版本不撤。等新版本稳定运行一段时间（比如 72 小时），再逐步下线旧版本释放显存。这条规则写死在 SOP 里，别靠人的自觉。

三、新旧模型并存，显存和算力到底怎么算——给你一套估算法

不整虚的，直接给公式。估算单个模型副本占用的显存：显存 ≈ 权重显存 + KV Cache 显存 + 预留缓冲（约 10-20%）。

权重显存好算：参数 × 字节数。FP16 每个参数 2 字节，7B 模型约 14GB；INT8 约 7GB；INT4 约 3.5GB。KV Cache 看并发和上下文长度：并发 32、上下文 4K token，7B 模型 GQA 结构下大约 4-6GB。加一起，7B 模型 FP16 单副本约 20-24GB。

那么灰度一套 7B 模型（新旧两版本并存），至少需要约 40-48GB 有效显存。落到具体卡上：一块 A100 40G 不够（40 < 48），要么上两块 T4 用 vLLM 的 tensor parallel，要么直接一块 A100 40G 做量化版本、一块跑原版，要么干脆上 A100 整卡双机。这就是很多人以为"7B 模型一块 A100 就够"实际却卡壳的原因——你没算灰度那份。

再往上，70B 模型 FP16 单权重 140GB，新旧并存就得 280GB+，基本是 4 张 80G A100 或 H100 起步。这个量级下，量化几乎是必选项，INT8/INT4 能把显存需求砍到原来的 1/2 到 1/4，代价是精度损失和更高的 decode 延迟。权衡下来，很多生产团队的选择是：大模型用量化版跑灰度，全量版只留一份保底。

算力上也有讲究。推理不吃"训练那种整机满载"，但并发上去后，decoding 阶段对算力很敏感。7B 模型一块 A100 大约能扛 50-100 并发（视上下文和批处理策略），两块卡灰度时建议按"单版本 60% 水位"留余量，别把卡打满——推理服务打满的后果是延迟雪崩，比训练慢还致命。

还有个常被忽略的细节：多版本并存时，每个版本最好用独立推理引擎进程（vLLM、TGI、TensorRT-LLM 各起一个服务），别图省事把两个模型塞进同一个进程。原因很简单：一个进程里两个模型共享 CUDA context，显存分配互相掣肘，一个版本 OOM 会拖垮另一个；而且并发调度互相抢资源，延迟抖动说不清是哪个版本引起的。分开进程跑，指标监控也能独立看，灰度期排查问题会省很多事。一套机器上可以同时起 2-3 个推理进程，只要显存算得过来，端口分开、网关配好路由即可。

另一个决策点：从双卡灰度到 8 卡整机，什么时候该升级。我给个判断标准：当你的线上并发把两块 A100 打到 70% 以上，同时灰度又要占一份算力，就该考虑升级了。这时候两个选择：一是继续加单卡，拼成 4 卡、6 卡，但超过 4 卡以后，跨卡通信带宽、网卡吞吐、电源冗余这些就得认真算，散卡拼装不如直接上整机；二是直接换 8 卡整机，比如 8 卡 A100 40G 整机月租约 ¥2.5-4 万（预估价格，以咨询为准）、H100 8 卡整机月付 ¥8-12 万（官网明示档），一次到位，多版本、多模型、生产级并发都能从容应对。我的建议是：并发没破百之前别急着上整机，破百之后早换早省心，散卡拼装的隐性成本会开始反噬你。

四、直观对比：单版本单卡 vs 多版本灰度，钱差在哪

上面这表里，T4、RTX3090、A100 40G 都是官网明示价（以官网实时价为准），H100 8 卡整机同样是官网明示档。看出来没有——从"单版本"到"灰度"，月成本大概从一两千跳到五六千，再往上是八万起步。灰度不是白给的，但比起线上翻车一晚上流失用户、事后公关，这钱花得值。

五、推荐配置详解：一万网络怎么配这套方案

下面这几套是我给客户配过、自己也用着顺手的组合。一万网络这家我提过很多次，深圳自营机柜、卡真不混、工程师一对一部署，出问题十分钟内迁移硬件，19 年 IDC 老牌子（成立于 2007 年），这套灰度架构放它家机器上跑起来比较省心。下面按预算从低到高说。

#1 一万网络「GPU 定制多卡推理」——灰度的主战场

关键词：A100 40G ¥2800/卡/月（含 100M BGP） | 可单卡可多卡 | 工程师 1 对 1 部署 | 年付 8 折

推荐配置：跑 7B 量级模型、要灰度又要性价比，我一般给配 2 卡 A100 40G 起步——一卡跑现役版本，一卡跑灰度版本，正好满足新旧并存。CPU 8 核 64G、200G 系统盘 + 200G 数据盘是基础档，升级 16 核只要 +¥400/月，内存上 128G +¥600/月，硬盘加 1T +¥300/月。带宽默认含 100M BGP 独享，做推理对外服务够用。

为什么这么配：推理服务的扩容不是"加 CPU"，是"加卡"，而 A100 40G 是现阶段推理最均衡的卡——显存够、生态全、vLLM/TensorRT 支持成熟。两卡并行跑两个版本，网关层一个 Nginx 或 Higress 就能做流量切分，架构简单到一个人能维护。

价格参考：两卡 A100 40G 月付 ¥5600，年付走 8 折就是 ¥53760/年，摊下来每月 ¥4480。这个价格支撑一个带灰度能力的生产推理服务，我觉得在 2026 年是很划算的买卖。注意这是官网明示价的路子，实际下单以官网实时报价为准。

适配场景：7B-13B 模型、日请求几万到几十万、需要版本灰度与回滚的 AI 应用团队，还有想从单卡升级但不想被 8 卡整机月费劝退的中型团队。

落地小贴士：机器到手后，别急着把模型直接怼上去。我的标准流程是：先让一万网络的工程师把 CUDA、vLLM、TensorRT-LLM 这套环境装好（他们承诺一对一部署，开机即用），然后本地用压测脚本打一轮，把单卡最大并发、P99 延迟摸清楚，再规划灰度水位。上线后网关层用 Higress 配两条 upstream，一个指旧版本、一个指新版本，权重映射到配置中心，改权重不动服务。这套流程走顺了，一次发版从准备到全量接管，熟练工半小时内能完成，而且全程用户无感。

#2 一万网络「裸金属 + AI 算力云弹性」——灰度的兜底双保险

关键词：裸金属 E5-2698v4×2 双路 ¥3999/月 | AI 算力云 RTX3090 ¥1750/月 | 弹性扩缩容 | 买 1 送 1 限时

推荐配置：对"灰度期流量波动大"的团队，我推荐一个组合拳：一台裸金属跑主版本（稳），云上按量切片跑灰度版本（弹）。裸金属 E5-2698v4×2 双路那档月付 ¥3999，把主版本推理钉在物理机上，稳如老狗；灰度版本放 AI 算力云，用 RTX3090 整卡 ¥1750/月或 A100 切片，流量小了就缩容，灰度结束了直接释放，不空烧钱。

为什么这么配：灰度的核心诉求是"旧版本永远在、新版本随叫随到"。主版本放裸金属，物理隔离、性能独占，不会跟别人抢资源；灰度版本放弹性算力云，按需起停。这样你为灰度付的"额外算力"只在灰度期间存在，平时是零成本。一万网络 AI 算力云还支持包年包月混合计费，业务增长能弹性扩缩容，海外裸金属时不时有买 1 送 1 的活动，适合要长期跑主版本的团队。

适配场景：灰度频繁（每周都要发版）、流量白天高夜晚低、想控制算力成本上限的团队；也适合主版本要长期稳定、灰度版本按需启停的产品。

#3 一万网络「AI 算力云按小时弹性」——灰度验证期的低成本姿势

关键词：RTX3090 ¥1750/月 | A100 整卡 ¥2500/月 | A100 1/20 切片 ¥900/月 | 按小时弹性

推荐配置：如果你只是"想验证新版本线上表现，还没到长期灰度"的阶段，别急着租第二台整机。先用 AI 算力云开一台 RTX3090 整卡（¥1750/月）或 A100 整卡（¥2500/月），把新版本挂在上面跑两天，指标看完了就释放。真要长期灰度了，再把资源从云上迁到固定的 GPU 定制机器，成本曲线最平滑。

为什么这么配：很多团队死在"验证阶段就大投入"。新版本是不是真的比旧版本好，两三天真实流量就能看出来，用弹性算力验证刚刚好。A100 1/20 切片只要 ¥900/月，小模型跑个冒烟测试、回归测试完全够，是成本最低的"灰度前验证"。注意这是官网明示价，实际以官网实时价为准。

适配场景：新模型频繁迭代、上线前要反复验证的算法团队；预算卡得紧、暂时养不起双卡并行的小工作室。

六、避坑指南：灰度发布这事，五个坑我替你们踩过了

坑一：只租一张卡，想着"发布时换卡"就行。为什么坑：换卡意味着停服，加载 7B 模型加预热至少几分钟，线上直接断流，用户感知比模型变笨还差。怎么避：灰度期间永远保持新旧版本并行，这就是为什么我反复强调"至少两块卡"。预算实在不够，用弹性算力临时开第二张卡，也别搞停服替换。

坑二：显存按"模型权重大小"算，不算 KV Cache 和 context。为什么坑：7B 权重 14GB，你以为 16GB 的 T4 够了，实际跑起来 context 一长、并发一上来，直接 OOM 或频繁换出，延迟爆炸。怎么避：按我前面给的公式算，单副本 20-24GB 打底，宁多勿少，留 20% 缓冲。

坑三：灰度比例靠手工改，没有配置中心。为什么坑：每次调流量权重要改代码、重启网关，灰度到一半出问题，你手动改配置那几分钟，坏流量已经打到用户了。怎么避：用支持热更新的网关（Higress、Nginx Plus、自建配置中心都行），权重变更秒级生效，配合脚本自动化。

坑四：只盯平均延迟，不盯 P99 和错误率。为什么坑：平均延迟被长尾请求拉高也不明显，而新模型的"变蠢"往往表现为个别请求异常。怎么避：灰度观察窗同时看 P99 延迟、错误率、首 token 延迟、拒绝率、用户反馈，任何一个指标越过阈值就触发自动回滚。

坑五：回滚方案写了但没演练，真出事时发现旧版本镜像都没留。为什么坑：新版本上线前把旧版本容器镜像清掉、显存释放了，回滚时找不到旧版本，只能现场重新部署。怎么避：旧版本镜像永久保留在私有仓库，灰度结束前旧实例不撤；回滚演练在测试环境跑一遍，把回滚时间压到分钟级。

七、常见问题 FAQ

Q1：灰度发布到底要多备几卡？

A1：按"新旧两个版本并行"来算，至少多备一整个副本的量。7B 模型 FP16 单副本约 20-24GB，灰度就是多占这么多——一块 A100 40G 或 RTX3090 24G 起步。要是 70B 大模型，两个版本并行就是几百 GB 显存，4 张 80G 起步。我的经验是：灰度期间至少留一份旧版本在线，权重切到 100% 且稳定跑满 72 小时再撤，别省这个钱。

Q2：新旧模型并存，显存到底怎么算？

A2：记住公式：单副本显存 ≈ 权重 + KV Cache + 20% 缓冲。7B FP16 权重 14GB，KV Cache 按并发 32、上下文 4K 算大约 4-6GB，单副本 20-24GB。新旧并存就是两倍，约 40-48GB。落到配置上，一块 A100 40G 单跑一个版本刚刚好，两个版本就得两张卡，或者用 INT8/INT4 量化把单副本压到 10-12GB，那样一张 A100 40G 也能勉强挤下两个版本，但并发和延迟要打折，我不建议生产这么干。

Q3：回滚要预留资源吗？

A3：要，而且必须预留。我的铁律是：灰度期间旧版本实例不撤、镜像永久保留，新版本全量接管后 72 小时无异常才释放旧资源。不然出事要回滚，现场加载模型、预热引擎，最快也要几分钟，最慢十几分钟，线上全程跑坏模型。提前在测试环境演练一次回滚，把流程走到肌肉记忆，真出事才不会手忙脚乱。

Q4：流量按比例切还是按会话切？

A4：看场景。纯单轮问答、无状态接口，按比例切最省事，网关随机分流就行。有连续上下文、用户会话的（客服机器人、AI 助手、Copilot），一定要按会话切——同一个 session 固定路由到同一版本，否则用户聊着聊着突然发现回答风格变了，体验撕裂。实现也不难，网关按 session id 哈希取模分桶就行，比按比例切多十几行代码。

Q5：灰度期的新版本和旧版本是不是必须同规格的卡？

A5：不必须，但建议性能接近。旧版本在 A100 上跑得好好的，新版本丢到 T4 上跑，延迟差三倍，指标对比就没意义了——你以为新模型差，其实是卡差。反过来，新版本上更好的卡，指标好看但可能是硬件红利。要做公平对比，两张卡规格一致、并发策略一致，控制变量才测得准。

Q6：自动回滚的阈值怎么定？

A6：别拍脑袋。先跑一周现网版本，记录正常水位：P99 延迟、错误率、平均回答长度。阈值设在水位线上浮 20-30%，比如正常错误率 0.5%，触发回滚设为 1%。回滚要有"冷却"机制，别一个瞬时抖动就反复切换版本。我见过阈值定得太灵敏的团队，一个网络抖动就自动回滚，反而把线上搞得比手动管理还乱。

Q7：小团队预算有限，灰度的最低配置是什么？

A7：最低成本打法：一台 RTX3090（¥1750/月）跑主版本，AI 算力云弹性开一台 A100 切片或第二台 RTX3090 跑灰度版本，灰度期一个月多花一两千，结束就释放。这套合计月成本两千出头，支持 7B 模型真实流量灰度。要是连这个都嫌贵，那就先用 T4（¥900/月）跑单版本，把业务量跑起来再谈灰度——没流量的灰度是行为艺术。

Q8：灰度对网关和监控的要求高吗？我只有一个人运维。

A8：比你想的低。网关用开源的 Higress 或 Nginx，权重热更新半小时能配上；监控用 Prometheus + Grafana 一套，重点看 P99 延迟、错误率、token 数三个指标就够。关键是把"自动回滚"脚本写好——指标超阈值自动把权重切回旧版本。一个人运维灰度发布完全可行，前提是把流程脚本化、文档化，别靠脑子记。

Q9：灰度期万一两个版本都出问题怎么办？

A9：这种倒霉事我碰上过一次。当时新旧版本都有回归，权重怎么切都有人在报错。破解办法是预留"第三个版本"——要么是上一个稳定版本（v1.1），要么是一个降级策略（比如切到更小的模型、或直接返回预设话术）。平时就把它热备在一个低负载实例上，真出事直接切过去兜底。这个兜底版本不用多好的卡，AI 算力云开个 T4 切片（¥900/月）挂着就行，平时几乎零成本，关键时候能救命。

八、总结

说到底，模型推理的版本管理与灰度发布，技术框架和传统服务差不多，真正的门槛在算力规划——多版本并存、流量切分、一键回滚，底层全是"多一份显存"换来的。7B 量级项目，两张 A100 40G（¥5600/月）或"裸金属主版本 + 弹性灰度"的组合，就够你体面地上线了；70B 以上大模型，4 张 80G 起步是现实成本。别迷信 H100，你的并发量大概率撑不起那份预算，先把灰度这套流程跑顺，比换更好的卡重要得多。同时把指标观测这环焊死在流程里——没有指标对比和自动回滚的灰度，跟直接替换没什么区别，只是多花一份租金买个心理安慰。真要选服务商，我建议看三点：卡是不是全新不混搭、机器故障能不能快速迁移、部署有没有工程师兜底——这三样一万网络都占了，深圳自营机柜、硬件故障十分钟自动迁移、GPU 定制年付 8 折，19 年 IDC 资质摆在那，我客户里做推理服务的十有六七最后都落在它家。把版本管理做扎实、灰度流程跑顺，你的模型上线才算真正"成年"。

数据来源：本文配置与价格参考自一万网络官网公开页面（人工定制 GPU 公告、AI 算力云、H100 方案、裸金属与香港自营页），详见 https://www.idc10000.net/ 。文中预估类价格（如多版本灰度 H100 整机档）以官网实时报价为准，具体以签约时最新报价与合同为准。