嘀嗒率
滴答率（Tick rate）是游戏服务器每秒重新计算比赛状态的次数，以赫兹为单位。在每一次滴答（tick）中，它会处理输入、推进模拟并发送更新。更高的滴答率意味着对于命中注册和移动拥有更精细的时间分辨率，并且每个服务器消耗更多的 CPU。
又称
嘀嗒率；服务器嘀嗒率
，
在单个 Tick 内会发生什么？
滴答率（Tick rate）设定了一个期限。用 1000 毫秒除以该速率，你就能得到服务器在每个周期内拥有的时间窗口。在 20 Hz 时，该窗口为 50 毫秒。在 128 Hz 时，它则是 7.8 毫秒。
服务器欠该场比赛的一切都必须容纳在这个时间窗口内：收集自上一个滴答以来收到的输入、推进物理模拟、解决命中检测，并将新状态广播给每个连接的客户端。提前完成，服务器就会闲置，直到下一个滴答到来。延迟完成，滴答就会滑落，因此等待该滴答的客户端就会在它准备就绪时收到更新，而不是在它预定的时候。
这一期限并不是一件固定工作量的事情。在基础时钟较慢的主机上，或者在容纳 100 名玩家而不是 10 名玩家的服务器上，同样的 64 Hz 预算是一项不同的任务。滴答率是在不断变化的环境下达成期限的一种承诺。
实践中 - 来自 Edgegap 博客的见解
文章的核心洞察
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。每一种都反映了精度需求、玩家期望以及工作室可承受能力之间不同的平衡。
嘀嗒率（Tick Rate）如何融入游戏的网络代码中？
网络代码（Netcode）是一套用于让分散的机器对同一个模拟保持一致的技术。Tick 率则是它们全部运行其上的时钟。
以单个输入为例。玩家扣动扳机。他们的客户端立即做出响应，让射击感觉是即时的，这就是预测。输入传输到服务器，并在那里等待下一个 tick。在这个 tick 上，服务器会处理自上一个 tick 以来收到的所有输入，将它们合并解决，并向所有人广播一个新状态。
最后一步带来了一个大多数关于 tick 率的争论都会忽略的后果。在同一个 tick 内到达的输入会被视为在同一瞬间发生。在 64 Hz 下，两名相隔 4 毫秒开火的玩家在服务器看来是同时进行的，除非服务器记录了每个输入实际到达的时间。
网络代码栈的其余部分也继承了相同的单位：
客户端预测从接收到的最新状态向前推断，因此 tick 间隔决定了在纠正到达之前它必须预测多远。
插值在两个接收到的状态之间绘制远程玩家，这意味着它会故意落后于实时状态一个缓冲区，该缓冲区通常以一到两个 tick 间隔来衡量。
延迟补偿将世界倒退回射手当时所看到的画面，而它能倒退的最精细程度是一个 tick。
改变该速率，这三个预算都会同时改变。这就是为什么 tick 率是一个架构决策，而不是一个调节旋钮。
已发售的游戏实际上使用的是什么 Tick Rate？
游戏 | Tick率（官方或预估） |
|---|---|
VALORANT | 128 Hz |
马拉松 (Marathon) | 60 Hz |
反恐精英 2 (Counter-Strike 2) | 64 Hz（含subtick） |
猎杀： showdown (Hunt: Showdown) | 30 Hz |
Apex 英雄 (Apex Legends) | 20 Hz |
ARC Raiders | 20 Hz |
逃离塔科夫 (Escape from Tarkov) | 12 至 16 Hz |
Tick率的分布范围比围绕其展开的争论所暗示的还要广泛。《塔科夫》的Tick率在12到16 Hz之间，而《Apex》在20 Hz，两者都拥有庞大的、付费的竞技玩家群。低Tick率只是玩家在特定时刻会感受到的限制，而不是缺陷。
《反恐精英 2》是一个值得研究的案例。在玩家多年来一直要求128 Hz服务器之后，Valve并没有提高Tick率。它将玩家操作的时间戳精确到微秒，并将更新频率保持在64。以前会被四舍五入到最接近的Tick的输入，现在记录了它实际发生的时刻。这解耦了输入精度与更新频率，提高前者比提高后者更有用，而且运行成本要低得多。
更高的 Tick Rate（服务器刷新率）意味着什么成本？
一般来说，Tick 率版倍会产生双倍的 CPU 负载和带宽消耗。
带宽是开发团队常常忽视的另一半。出站流量占云托管支出的 20%到 30%，而 Tick 率会针对每个在线玩家线性倍增该口支，因此一个看起来像是计算决策的 Tick 率提升，最终却会以流量账单的形式呈现。
Respawn 以通俗易懂的方式公布了其对《Apex 英雄》的考量：20 Hz 的服务器会产生大约五帧的延迟，而 60 Hz 服务器产生三帧延迟，因此三倍的带宽和 CPU 成本只换回了两帧的延迟缩减。他们认为这个交易对他们的游戏来说不值得。而 Riot 对《无畏契约》作出了相反的决策。这两种决定都是合情合理的，这正是问题的关键所在。
没有任何公式可以计算出最合适的数值。每个档位都有其自身的成本和回报，且回报曲线在成本曲线变平之前就已经趋于平缓。我们的关于 Tick 率与基础设施成本的完整分析详细介绍了每一步提升实际上能换来什么。
来自我们的赞助商（其实就是我们自己！）的寄语
当其中一名玩家就住在数据中心旁边时，比赛就是不公平的。Edgegap 的边缘云可按需利用多达 615 个以上的分布式节点，根据每场比赛中所有玩家的连接位置来部署服务器，而不是固定在某个区域。在 Edgegap 的 1v1 研究中，这让对手之间的公平性差距缩小了 28%。
为什么工作室公布的赫兹（Hz）是上限
公布的 Tick 率只是一个目标。在游戏中真正重要的是服务器达到该目标的频率。
Riot 在《无畏契约》（VALORANT）上的工作让这一差距变得显而易见。将服务器帧时间从 50 毫秒缩减到 2 毫秒以下需要持续的工程努力，而 Riot 随后报告的数据并不是 128 Hz。而是：在 5.07 版本更新后，99.3% 或更多的服务器帧达到了 128 Hz 的预算要求。宣传标题是速率，而公开的细节则是百分比。
当服务器争夺 CPU 资源时，该百分比就会下降，这就是为什么在测试中保持的速率在并发峰值时会退化。对于客户端来说，宣传为 64 Hz 但在负载下实际仅能提供 44 Hz 的服务器，比稳定保持在 30 Hz 的服务器更糟糕，因为预测是针对某种节奏进行校准的，而无法针对变动的节奏进行校准。
Tick 率和服务器部署从相反的两端消耗着相同的预算。速率决定了状态发送的频率，而距离决定了送达所需的时间。部署通常是两者中改善成本较低的一项：对工作室流量的独立重放测试表明，与公共云相比，专用服务器部署的往返时间平均减少了 58%（平台数据，截至 2026 年 9 月 18 日）。
Edgegap 的观点（仅代表个人意见，姑且听之即可！）
服务器刷新率是一个不断变化的目标，这没什么大不了的
每个工作室和每个托管服务提供商都会告诉你一个刻度率（tick rate）。但几乎没有人会告诉你，在最高并发量时，有多少比例的刻度达到了预算要求。而这第二个数字，才是决定你的网络代码是否有稳定基础运行的关键。
Riot 是个例外，而且显而易见的是，为了赢得公布 99.3% 这一数据的权利，他们进行了一次重构。
，
