
游戏服务器 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 频道 发布了一篇关于服务器 tick rate 在 Counter-Strike、VALORANT 和 PUBG 之间的对比分析。
这促使我们讨论 tickrate 不仅会影响玩家的在线体验,还会影响 托管 运行专用游戏服务器的成本,以及不同 tick rate 区间下的规模差异。因为其影响可能相当显著。
在本文中,我们会展示 Outscal 提到的一些相同案例,也会补充一些新案例,并说明每种 tickrate 如何影响成本。这也让每位游戏开发者都不得不思考:这种精确度到底值多少钱?
什么是 Tick Rate?
从本质上说,tick rate 就是服务器的处理节奏。每个 tick 都是一个完整周期:服务器收集自上次更新以来所有玩家的输入,运行物理模拟,检查命中检测,并把更新后的世界状态广播给所有已连接客户端。整个循环就是一个 tick。
tick rate 以赫兹(hertz)计量,表示这段周期每秒重复多少次。64 Hz 的服务器每 15.6 毫秒运行一次。128 Hz 的服务器每 7.8 毫秒运行一次。数学很简单:1,000 毫秒除以 tick rate,就得到了每个周期的处理窗口。
对玩家来说,更高的 tick rate 意味着服务器对游戏世界的认知更接近实时。命中判定更精准,移动更灵敏。那种玩家明明躲在掩体后却还是死亡,因为服务器快照落后于现实的情况,会更少发生。每个 tick 都是一个窗口,而落入那个缝隙里的东西很重要。
Tick Rate 的成本公式
难点就在这里。
把 tick rate 翻倍,你的 CPU 负载和带宽消耗也大致会翻倍。
每一场进行中的比赛里,每位玩家接收到状态更新的频率都会翻倍,这意味着每秒的出站数据也会翻倍。这些出站数据就是网络 egress,而 egress 是要花钱的(除非你使用已将 egress 费用包含在价格中的服务器,比如 裸金属v 或 Private Fleet 主机)。
在大规模场景下(例如全球服务器上同时进行的数万场比赛),64 Hz 和 128 Hz 之间的差距绝不是四舍五入误差,而是基础设施支出的重要部分。由于 egress 占云端整体托管支出的 20-30%,把 tick rate 翻倍会增加(或降低)这部分金额。
随后,vCPU 使用量上的影响还会进一步放大这笔成本。
更频繁地运行游戏模拟,意味着服务器处理器每秒要做更多工作:更多物理计算、更多命中检查、更多状态比对。Respawn 在其关于 Apex Legends 的官方技术深度解析中直言不讳:
“20Hz 服务器大约会产生五帧延迟,而 60Hz 服务器则会产生三帧延迟。所以,以三倍的带宽和 CPU 成本,你在最佳情况下可以节省两帧的延迟。”
这就是他们让 APEX: Legends 维持在 20 Hz 的理由。
这就是为什么 tick rate 是多人游戏设计中最具影响力的决策之一,也正因为如此,整个行业至今仍未收敛到一个统一答案。
付出全价:VALORANT 的 128 Hz
Riot Games 从 VALORANT 开发之初就明确了立场:每位玩家、每场比赛都使用 128 Hz 服务器。没有分级访问,也没有休闲池和竞技池之分。
正如 VALORANT Gameplay Integrity 团队工程师 Brent Randall 在 Riot 官方技术博客中所说:“‘把服务器变快 20 倍’并不是一个很容易解决的问题。”他们最初的服务器帧时间是 50 毫秒。在 128 Hz 下,目标是每帧 2.34 毫秒。为了跨越这道鸿沟,几乎所有系统都必须重构引擎使用服务器资源的方式。
动画是最大的成本驱动之一。团队通过每四帧计算一次角色动画并在其间插值,把动画处理开销削减了 75%。在无法发生战斗的购买阶段,他们则完全关闭了服务器端动画,又节省了 33%。他们还用基于 RPC 的自定义系统替换了 Unreal Engine 的默认网络层;根据他们自己记录的测试,这一改动依据动作类型不同带来了 100 倍到 10,000 倍的性能提升。连硬件选型也被重新审视,针对缓存架构差异更换服务器,又带来了另外 30% 的提升。
即便如此,2022 年的一次引擎更新仍在竞技赛季期间破坏了他们的性能,导致在 Champions 开赛前几天整个团队都必须紧急响应。他们修复了问题,系统比之前更好了。在 5.07 补丁之后,Riot 报告称 99.3% 及以上的服务器帧都满足了他们严格的 128 Hz 预算l。
这才是真正的 128 Hz 承诺成本。不只是更高的算力和 egress 账单,还有一项持续性的工程责任:要用每一个新功能、每一次引擎更新、每一轮赛季补丁去捍卫这份预算。
这并非无法实现。Riot 已经证明了这一点。但它需要持续投入,并不是所有工作室都具备复制如此庞大工程的条件。
重新思考前提: 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 已经不再重要。子 tick 更新是 Counter-Strike 2 的核心。”服务器仍以 64 Hz 运行并广播状态,但每个 tick 内发生的事件都会以微秒级精度进行结算。时间精度与基础设施成本解耦。
Valve 还把 FACEIT 在内的第三方服务锁定在相同的 64 Hz 基础速率上,终结了竞技圈多年依赖的 128 tick 社区服务器。Subtick 的技术论证很扎实,但它引发的摩擦也是真实存在的。这提醒我们:多人游戏中的架构决策并不是孤立存在的,它们总会与玩家预期和社区历史发生关联。
寻找中间地带: Marathon 的 60 Hz
并不是每家工作室都会走向两个极端中的任何一端。
Bungie 的 Marathon,这款于 2026 年发布的撤离射击游戏,运行在 60 Hz 服务器 上。在这种类型的游戏中,一场交火的失败意味着这次跑图的整套装备都可能丢失,服务器精度就不再只是学术问题。一位评论者把 60 Hz tick rate 描述为“Marathon 最被低估的功能之一”,并指出在高风险对决中,紧密的命中判定是游戏竞技完整性的核心。
相比之下,竞争对手 ARC Raiders 以 20 Hz 运行。这种差异在激烈的 PvP 对局中最为明显,因为在那种场景下,延迟或不同步原本会不公平地惩罚玩家。Marathon 的选择明显高于大多数撤离射击游戏的基础水平,但又没有承担 128 Hz 所要求的全部工程开销。
这是一个刻意选择的中间点。对于一个围绕高后果交战和低 TTK 设计的类型来说,60 Hz 提供了足够的精度,让枪战感觉公平,同时把基础设施成本控制在不会达到 VALORANT 式承诺的范围内。合适的 tick rate 并不总是可用的最高值,而是能同时满足你游戏精度需求和基础设施可持续性的那个值。
没有标准答案:只有合适的权衡
APEX: Legends 运行在 20 Hz,VALORANT 运行在 128 Hz,CS2 运行在 64 Hz 并使用 Subtick,Marathon 运行在 60 Hz。Arc Raiders 运行在 20 Hz,据报道 Hunt Showdown 运行在 30 Hz,Escape from Tarkov 运行在 12-16Hz。
每一种选择都反映了对游戏需求以及工作室在运营层面能够支持什么的不同计算。
其底层逻辑对所有这些游戏都一致。更高的 tick rate 会更频繁地向更多玩家发送更多数据。每个模拟周期都需要更多 vCPU 时间。规模越大,成本越高。
对于某些游戏和类型来说,这种精度值得这笔开销。对于另一些游戏来说,命中判定的边际提升并不足以证明把 egress 账单翻倍是合理的。
同样值得注意的是,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 的一手技术文档。原始内容中的所有权利归其各自所有者所有。










