
游戏服务器 Tick 率详解:游戏精度与基础设施成本

Tick 率是一项成本决策:在竞技游戏中,tick 率会带来显著的 CPU 负载和带宽成本,因此在多人游戏开发中,鉴于其成本,tick 率是最具影响力的基础设施选择之一,同时也会显著影响玩家对游戏“手感”的体验。
VALORANT 对 128 Hz 的承诺:Riot 从零开始重建了核心引擎系统,将服务器帧时间从 50 毫秒降到 2 毫秒以下。这是一项持续多年的工程投入,大多数工作室都难以轻易复制。
CS2 的 Subtick 系统:Valve 没有提高 tick 率,而是为玩家操作引入了微秒级时间戳,在不成倍增加基础设施成本的情况下解决了量化问题。
Marathon 的折中方案:Bungie 的撤离射击游戏表明,合适的 tick 率取决于类型需求和运维能力,而不只是看数值越高越好。
没有通用答案:Apex 运行在 20 Hz,VALORANT 运行在 128 Hz,CS2 在启用 Subtick 的情况下运行于 64 Hz,而 Marathon 运行在 60 Hz。每一种都反映了精度需求、玩家期望以及工作室可承受能力之间不同的平衡。
Outscal 精彩的 YouTube 频道发布了一期对比分析视频,详细探讨了《反恐精英》(Counter-Strike)、《无畏契约》(VALORANT)和《绝地求生》(PUBG)的服务器 Tick Rate(伺服器刷新率)。
这促使我们去探讨:Tick Rate 不仅影响玩家的在线体验,还会影响在不同刷新率区间下运营专用游戏服务器的托管成本。因为这种影响可能是巨大的。
在本文中,我们将重点介绍 Outscal 提及的部分案例以及一些新案例,并分析各类 Tick Rate 如何影响成本。这也向每位游戏开发者提出了一个问题:这种精准度到底价值几何?
什么是 Tick Rate?
从本质上讲,Tick Rate 是服务器的处理节奏。每一个 Tick 都是一个完整的循环:服务器收集自上次更新以来所有玩家的输入,运行物理模拟,检查命中判定,并将更新后的世界状态广播回所有连接的客户端。这整个循环就是一个 Tick。
Tick Rate 以赫兹(Hz)为单位,代表该循环每秒重复的次数。64 Hz 的服务器每 15.6 毫秒运行一次该循环。128 Hz 的服务器则每 7.8 毫秒运行一次。计算公式很简单:1,000 毫秒除以 Tick Rate 即可得出每个循环的处理窗口时间。
对玩家来说,更高的 Tick Rate 意味着服务器所呈现的游戏世界画面更具时效性。命中判定更精准,移动响应更灵敏。玩家因服务器快照落后于实际情况而看似“死在掩体后”的情况也会减少。每一个 Tick 都是一个时间窗口,落入这个间隔中的信息至关重要。
Tick Rate 成本方程
这也正是决策变得艰难的地方。
将 Tick Rate 翻倍,你的 CPU 负载和带宽消耗大致也会翻倍。
每场进行中比赛的每位玩家接收状态更新的频率都会翻倍,这意味着每秒输出的数据量翻倍。这些出站数据属于网络传出流量(egress),而传出流量是需要成本的(除非你使用的服务器价格中已包含传出流量,比如裸金属或 Private Fleet 主机)。
在规模化场景下(例如,全球服务器上同时进行数万场比赛),64 Hz 与 128 Hz 之间的差距绝非四舍五入的微小误差,它在基础设施支出中占据了相当大的比例。由于传出流量占云端整体托管支出的 20-30%,将 Tick Rate 翻倍可能会显著增加(或减少)这一开支。
此外,对 vCPU 占用的影响会进一步加剧这一成本。
更频繁地运行游戏模拟意味着服务器处理器每秒需要处理更多工作:更多的物理计算、更多的命中判定、更多的状态对比。Respawn 在其针对《Apex 英雄》(Apex Legends)的官方开发者深度解析中明确指出了这一点:
“20Hz 的服务器会导致大约五帧的延迟,而 60Hz 的服务器会导致三帧的延迟。因此,为了获得三倍的带宽和 CPU 成本,在最理想的情况下,你只能节省两帧的延迟。”
这种数学权衡正是他们让《Apex 英雄》保持在 20 Hz 的理由。
这就是为什么 Tick Rate 是多人游戏设计中最具决定性的决策之一,也是整个行业至今未达成统一步调的原因。
付出全部代价:128 Hz 的《无畏契约》(VALORANT)
Riot Games 在《无畏契约》开发之初就明确表达了立场:每位玩家在每场对局中都能享受 128 Hz 服务器。没有分级体验,休闲模式与竞技模式一视同仁。
正如《无畏契约》游戏完整性团队的工程师 Brent Randall 在 Riot 官方技术博客中所描述的那样:“‘让服务器提速 20 倍’并不是一个容易解决的问题。”他们的初始服务器帧时间为 50 毫秒。在 128 Hz 下,目标是每帧 2.34 毫秒。这一差距需要重构引擎利用服务器资源的方式,几乎涵盖了每一个系统。
动画是最大的成本驱动因素之一。团队通过每四帧计算一次角色动画并在其间进行插值来降低开销,将动画处理减少了 75%。在不会发生战斗的购买阶段,他们完全禁用了服务器端动画,又节省了 33% 的开销。他们还用基于 RPC 的自定义系统替换了 Unreal Engine 的默认网络层,根据他们自己的测试记录,该系统根据操作类型不同带来了 100 倍到 10,000 倍的性能提升。甚至硬件选择也经过了重新评估,针对缓存架构差异更换服务器带来了另外 30% 的性能收益。
即便如此,2022 年的一次引擎更新还是在竞技赛季期间破坏了性能,迫使团队在冠军赛前几天进行全员紧急响应。他们修复了该问题,系统变得比以往更加出色。在 5.07 版本补丁之后,Riot 报告称 99.3% 或更多的服务器帧达到了严格的 128 Hz 预算标准。
这就是坚持 128 Hz 的真正代价:不仅是更高的算力和流量账单,还需要持续投入工程力量,在面对每一项新功能、每一次引擎更新和每个赛季补丁时坚守这一预算标准。
这是可以做到的,Riot 证明了这一点。但这需要持续的投入,并非所有工作室都有能力复制如此庞大的工程。
重新审视前提:《反恐精英 2》(Counter-Strike 2)的 Subtick 系统
Valve 审视了 128 Hz 的工程投入,并提出了一个不同的问题:如果提高 Tick Rate 解决的根本不是核心问题呢?
固定间隔 Tick 系统的根源问题是量化误差。在 64 Hz 下,两名几乎在同一瞬间开火的玩家会在同一个 Tick 内被处理。谁的动作更接近 Tick 边界,谁就会被先处理。另一名玩家输掉对决,部分原因可能是由于时间判定的偶发性,而不是技术差距。提高 Tick Rate 缩小了这一窗口,但并未彻底消除该问题。
CS2 的 Subtick 系统以不同的方式解决了这一问题。服务器不再固定在 Tick 边界处理所有输入,而是为每个玩家的动作记录精确到微秒级的时间戳。
在一个 Tick 周期中间射出的一枪会在其发生的确切时刻被记录下来。在该周期稍后射出的反击也会拥有自己的时间戳。随后,服务器会按照真实的发生先后顺序处理这些事件,而与基础的 64 Hz 广播频率无关。
Valve 在 CS2 公告页面上直接描述了这一目标:“无论移动、射击还是投掷,Tick Rate 不再影响发挥。Sub-tick 更新是《反恐精英 2》的核心。”服务器仍以 64 Hz 运行以广播状态,但每个 Tick 内发生的事件均以微秒级精度进行解析。时间精准度从此与基础设施成本解耦。
Valve 还将包括 FACEIT 在内的第三方服务锁定在相同的 64 Hz 基础频率,取消了竞技圈多年来依赖的 128-tick 社区服务器。Subtick 的技术逻辑非常扎实,但它引发的争议也是实打实的。这也提醒我们:多人游戏架构的决策无法脱离玩家期望和社区历史而孤立存在。
寻找折中点:《马拉松》(Marathon)的 60 Hz 策略
并非所有工作室都会走向极端。
Bungie 于 2026 年推出的撤离射击游戏《马拉松》运行在 60 Hz 服务器上。在失去一场交火就意味着失去整局所携装备的游戏类型中,服务器的精准度绝非纸上谈兵。一位评测人员将 60 Hz Tick Rate 描述为“《马拉松》中最容易被低估的特性”,并指出严谨的命中判定是该游戏在高风险对决中保持竞技公平性的核心。
相比之下,同类竞品撤离射击游戏《ARC Raiders》则运行在 20 Hz。这种差异在激烈的 PvP 交锋中尤为明显,延迟或不同步会给玩家带来不公平的惩罚。《马拉松》的选择远高于大多数撤离射击游戏的基准线,同时又无需承担 128 Hz 所需的全面工程开销。
这是一个深思熟虑的平衡点。对于一款围绕高代价冲突、击杀时间(TTK)较短而构建的游戏,60 Hz 提供了足够的精准度以保证枪战的公平感,同时将基础设施成本控制在远低于《无畏契约》式方案的水平。合适的 Tick Rate 并不总是可选的最高数值,而是与你的游戏精准度需求相匹配,同时基础设施能够切实承受的数值。
没有标准答案:只有恰当的权衡
《Apex 英雄》运行在 20 Hz,《无畏契约》运行在 128 Hz,CS2 采用带有 Subtick 的 64 Hz,《马拉松》运行在 60 Hz。ARC Raiders 运行在 20 Hz,据报道《猎杀:对决》(Hunt: Showdown)运行在 30 Hz,而《逃离塔科夫》(Escape from Tarkov)则在 12-16 Hz。
每一种选择都反映了对游戏实际需求以及工作室运营支撑能力的不同权衡考量。
所有这些选择背后的逻辑是一致的。更高的 Tick Rate 意味着需要更频繁地向更多玩家发送更多数据。它们在每个模拟周期需要消耗更多的 vCPU 时间,并在规模化运营时带来更高的成本。
对于某些游戏和品类而言,这种精准度值得付出相应的代价。而对于其他游戏,命中判定的微小提升并不能证明让流量账单翻倍是合理的。
同样值得注意的是,Tick Rate 并不是唯一的调节杠杆。将服务器部署在离玩家更近的地方,可以从根本上降低延迟,而 Tick Rate 决策部分正是试图去弥补这一延迟问题。一台部署位置优越的 64 Hz 服务器,其表现很可能会超越一台远离玩家群体的 128 Hz 服务器。像 Edgegap 的游戏服务器编排网络在全球部署了超过 615 个节点,平均可降低 58% 的延迟。事实证明,延迟是导致在线游戏玩家感到挫败的首要原因。
换言之,Tick Rate 与网络节点部署相辅相成。单凭其中任何一项都无法决定全局。
这个决定本身就是一种权衡。请在充分审视游戏类型、玩家群体预期以及团队维护既定标准的能力的基础上,深思熟虑地做出抉择。
如果您想了解 Tick Rate 决策如何影响实际的服务器成本,Edgegap 的定价计算器可让您结合玩家数量和所在区域进行模拟测算。--
本文基于并引用了 Outscal 在 YouTube 上发布的视频《64 vs 128 Tick Servers: CS2 vs Valorant vs PUBG》,以及来自 Riot Games、Respawn Entertainment 和 Valve 的 Counter Strike 2 的第一手技术文档。原内容的所有权利归其各自所有者所有。
书写者
Jakub Motyl,产品经理









