@SuJinYan123: NV72：每 4 个 GPU 一个 tray，每 tray 配 2 个 NVIDIA Grace（ARM Neoverse V2，72 核，共 144 核，3.39 GHz），单 CPU ~480 GB LPDDR5X，即 4 个 GPU…

X AI KOLs Timeline 新闻
nv72 nvidia-grace gpu-tray inference-architecture mixture-of-experts parallel-strategy kv-cache coding-traces

摘要

文章详细分析了NV72架构中每4个GPU配2个Grace CPU的tray设计，探讨了在coding负载下通过EP64、TP8等并行策略优化推理性能，以及KV cache管理和路由算法的复杂性。

NV72：每 4 个 GPU 一个 tray，每 tray 配 2 个 NVIDIA Grace（ARM Neoverse V2，72 核，共 144 核，3.39 GHz），单 CPU ~480 GB LPDDR5X，即 4 个 GPU 配 ~956 GB CPU 内存（~239 GB/GPU）。网卡每 tray 4 个 CX8，PCIe 6.0（128 GB/s）。 所以大家常说的一个问题，p/d 流量和 ep all to all 流量冲突，完全可以通过 P/D 走 RDMA, ep 走 nvlink 解决。 nv72，但是比如 glm5.2 专家数量是 256，除不尽，硬上 72 可以通过类似冗余专家去做 eplb，会给系统增加一些复杂度，另一方面，prefill 和 decode 是否放一起，如果放一起，超长 prefill 怎么 handle，nv72 是否可以和另外一个 nv72 通信？（感觉复杂）。如果放一起，类似 green ctx 可以解决一些冲突的问题，但在 prefill 较长的时候性能会有损。 还有一个思路是做 attn ffn 分离，也复杂，暂时不考虑。 EP64 在形态上刚好，剩下来的 8 个卡，刚好做类似 TP8 的东西处理长 prefill，剩下的 短 prefill 和 decode 一起跑。我们需要一个具体量化的数字，假设我们服务 coding 流量。 https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces… 我们来 vllm 开源的一个 codex 在 sweben-pro 上跑的真实的 coding traces， 假设 kv cache缓存无限大， 需要 prefill 的请求里，50% 的请求只需要 prefill < 357 token，72% 的请求只需要 prefill < 2048 个 token，平均 ctx 长度在 63K，coding agent 是重 kv cache hit 的负载（需要很棒的 kv cache 系统支持）。 即使我们将 按 2K 的阈值，将 72% 的请求和 decode 一起跑，剩下 28% 的请求都是长 prefill，仅由 TP8（或者其他方式支持可能不太够），我们只能保佑他们不是一瞬间到来的（这需要真实流量的 traces)。 对于 GLM5.2，我们再看 kv cache 容量，dp64 ep64后，单个 B300 有接近 230GB 的 GPU kv cache 显存，按照之前的估计，每个 GPU 实际上也只有近似的 CPU kv cache 大小，这意味着如果 CPU 是 write through 策略的话，它几乎不能带来性能的提升。B300 显存是在太大了。 假设平均 ctx=256k，fp8 kv cache，显存里能放 17 个请求，如果要做稀疏撑 BS 的话，CPU 又显得有一些小了。 所以我们必须思考 CPU Memory 做 kv cache 的意义，不过可以后置。 所以流量最后可能是这样的，对于冷启动的 prefill，它会被路由到 prefill wokrer（由 8 卡提供支持），和剩下的 64 卡做 P/D 分离，短 prefill 会被路由到 64 卡，这里需要选一个 DP worker（这个 DP worker 开不开 TP 也是一个问题，我们需要一个甜点区），这里的路由算法会比较复杂，需要考虑两方面，一方面是 decode 的 balance，另一方面是 prefill 的热点（谁有 kv cache). 另一方面如果64 个 gpu kv cache 是 p2p 的，或者说整个 64 可以逻辑看作一整个 kv cache pool，那么调度就不用考虑 cache aware，更多偏向 decode balance 侧。 所以我们需要一个 gpu p2p kv cache based on nvlink，这也许会让事情变得复杂。短期 goal 可以借助 cpu p2p（pegaflow已经支持），包括 prefill worker -> normal worker(64 卡），也是走的 pegaflow p2p。 剩下的就是两侧的引擎形态 prefill worker: tp8? tp8 + ep8? 需要回答的是，什么并行策略能提供长 ctx 下极致的吞吐。 normal worker: ep64，但 attn 部分是否是纯 dp，开 tp 的话，要切 head（64 一切就不太友好了），当然也有别的方式可以解。moe all to all 怎么写，nv 好像有写，还没测过。一些调度，dp 协作，mtp 这些处理，还是蛮负载的。 这样构建完，72 卡应该能提供非常 amazing 的性能。 未完持续。
查看原文
查看缓存全文

缓存时间: 2026/07/12 16:59

NV72：每 4 个 GPU 一个 tray，每 tray 配 2 个 NVIDIA Grace（ARM Neoverse V2，72 核，共 144 核，3.39 GHz），单 CPU ~480 GB LPDDR5X，即 4 个 GPU 配 ~956 GB CPU 内存（~239 GB/GPU）。网卡每 tray 4 个 CX8，PCIe 6.0（128 GB/s）。

所以大家常说的一个问题，p/d 流量和 ep all to all 流量冲突，完全可以通过 P/D 走 RDMA, ep 走 nvlink 解决。

nv72，但是比如 glm5.2 专家数量是 256，除不尽，硬上 72 可以通过类似冗余专家去做 eplb，会给系统增加一些复杂度，另一方面，prefill 和 decode 是否放一起，如果放一起，超长 prefill 怎么 handle，nv72 是否可以和另外一个 nv72 通信？（感觉复杂）。如果放一起，类似 green ctx 可以解决一些冲突的问题，但在 prefill 较长的时候性能会有损。

还有一个思路是做 attn ffn 分离，也复杂，暂时不考虑。

EP64 在形态上刚好，剩下来的 8 个卡，刚好做类似 TP8 的东西处理长 prefill，剩下的 短 prefill 和 decode 一起跑。我们需要一个具体量化的数字，假设我们服务 coding 流量。

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces…

我们来 vllm 开源的一个 codex 在 sweben-pro 上跑的真实的 coding traces，

假设 kv cache缓存无限大， 需要 prefill 的请求里，50% 的请求只需要 prefill < 357 token，72% 的请求只需要 prefill < 2048 个 token，平均 ctx 长度在 63K，coding agent 是重 kv cache hit 的负载（需要很棒的 kv cache 系统支持）。

即使我们将 按 2K 的阈值，将 72% 的请求和 decode 一起跑，剩下 28% 的请求都是长 prefill，仅由 TP8（或者其他方式支持可能不太够），我们只能保佑他们不是一瞬间到来的（这需要真实流量的 traces)。

对于 GLM5.2，我们再看 kv cache 容量，dp64 ep64后，单个 B300 有接近 230GB 的 GPU kv cache 显存，按照之前的估计，每个 GPU 实际上也只有近似的 CPU kv cache 大小，这意味着如果 CPU 是 write through 策略的话，它几乎不能带来性能的提升。B300 显存是在太大了。

假设平均 ctx=256k，fp8 kv cache，显存里能放 17 个请求，如果要做稀疏撑 BS 的话，CPU 又显得有一些小了。

所以我们必须思考 CPU Memory 做 kv cache 的意义，不过可以后置。

所以流量最后可能是这样的，对于冷启动的 prefill，它会被路由到 prefill wokrer（由 8 卡提供支持），和剩下的 64 卡做 P/D 分离，短 prefill 会被路由到 64 卡，这里需要选一个 DP worker（这个 DP worker 开不开 TP 也是一个问题，我们需要一个甜点区），这里的路由算法会比较复杂，需要考虑两方面，一方面是 decode 的 balance，另一方面是 prefill 的热点（谁有 kv cache).

另一方面如果64 个 gpu kv cache 是 p2p 的，或者说整个 64 可以逻辑看作一整个 kv cache pool，那么调度就不用考虑 cache aware，更多偏向 decode balance 侧。

所以我们需要一个 gpu p2p kv cache based on nvlink，这也许会让事情变得复杂。短期 goal 可以借助 cpu p2p（pegaflow已经支持），包括 prefill worker -> normal worker(64 卡），也是走的 pegaflow p2p。

剩下的就是两侧的引擎形态 prefill worker: tp8? tp8 + ep8? 需要回答的是，什么并行策略能提供长 ctx 下极致的吞吐。 normal worker: ep64，但 attn 部分是否是纯 dp，开 tp 的话，要切 head（64 一切就不太友好了），当然也有别的方式可以解。moe all to all 怎么写，nv 好像有写，还没测过。一些调度，dp 协作，mtp 这些处理，还是蛮负载的。

这样构建完，72 卡应该能提供非常 amazing 的性能。

未完持续。

Inferact/codex_swebenchpro_traces · Datasets at Hugging Face

Source: https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces This is a dataset generated by real swebenchpro agentic workload trace + codex agent.

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#1-eval-result-summary1. Eval Result Summary

MetricValueTotal trials731Successful trials610Failed trials120No data (skipped)1Passed329Pass rate (of successful)53.9%

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#per-repo-breakdownPer-Repo Breakdown

RepoTotalSuccessFailedPassedPass%ansible/ansible969336065%internetarchive/openli918835259%flipt-io/flipt858232632%qutebrowser/qutebrowse797815672%gravitational/teleport7640361230%protonmail/webclients6506500%future-architect/vuls625653155%navidrome/navidrome575522545%element-hq/element-web565422444%nodebb/nodebb444403170%tutao/tutanota202001260%

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#2-per-trial-statistics2. Per-Trial Statistics

Based on successful trials only.

MetricMeanP50P90P99LLM calls per trial33305790Total input tokens2,266,0551,637,0004,750,6919,030,908Total cached tokens2,133,6871,525,3764,580,2248,781,952Total computed tokens132,368116,991230,677512,315Total output tokens17,23915,66629,96840,542Starting context (1st call)12,36712,27812,81313,744Ending context (last call)84,48280,488130,165180,943Max context length84,51380,488130,165180,943Context growth per turn2,2428805,96415,930

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#3-per-llm-call-statistics3. Per-LLM-Call Statistics

20,230 total LLM calls across 610 successful trials.

MetricMeanP50P90P99Input tokens68,32963,917114,888166,322Cached tokens64,33860,928112,512162,048Computed (uncached) tokens3,9917588,73653,323Output tokens5202461,1334,845 Context length per trial:

MetricMeanP50P90P99Starting context (1st call)12,36712,27812,81313,744Ending context (last call)84,48280,488130,165180,943Max context84,51380,488130,165180,943

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#4-caching-analysis4. Caching Analysis

Overall cache hit rate: 94.2%(1,301.5M of 1,382.3M input tokens served from cache)

Only**80.7M tokens (5.8%)**of all input required actual KV compute; the rest were cache hits.

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#41-intra-trial-cache-turn-by-turn4.1 Intra-Trial Cache (Turn-by-Turn)

TurnAvg Cache RateMedianN Trials187.4%93.6%610265.5%66.2%610376.2%77.8%610485.3%87.2%610589.5%91.5%610692.7%95.2%610794.2%96.3%609892.4%97.3%607971.3%95.1%6041084.6%96.2%5981189.2%97.2%5881293.7%98.1%5761394.2%98.5%5661494.5%98.8%5571595.2%99.0%5401694.9%99.3%5241795.6%99.3%5031896.3%99.4%4891995.8%99.4%4772095.7%99.4%4612596.1%99.5%3883096.4%99.5%3103596.3%99.5%2414098.1%99.6%1834596.5%99.7%1335097.8%99.6%935594.6%99.7%746094.9%99.7%526598.4%99.8%337098.4%99.7%317598.2%99.7%228099.3%99.8%158598.1%99.7%10

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#42-cross-trial-cache-1st-call-analysis4.2 Cross-Trial Cache (1st-Call Analysis)

The 1st LLM call of each trial can only have cache hits from other concurrent trials sharing the same system prompt prefix.

MetricValueTotal trials610Trials WITH 1st-call cache hit572 (93.8%)Trials WITHOUT 1st-call cache hit38 (6.2%) Among trials with 1st-call cache hit:

MetricValueMean cache rate93.2%Median cache rate93.8%

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#prefix-group-analysisPrefix Group Analysis

Cached Tokens# TrialsNotes11,520568Main shared prefix038Cache miss on 1st call12,0322Variant12,6721Variant12,1601Variant

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#5-turn-timing–inter-call-delays5. Turn Timing & Inter-Call Delays

Time between consecutive LLM calls within a trial. Includes model response time + tool execution + agent processing.

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#per-trial-duration-first-to-last-llm-callPer-Trial Duration (first to last LLM call)

MetricMeanP50P90P99Trial duration (seconds)336.8273.7637.81160.5Avg inter-call delay per trial (s)10.29.714.522.8

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#inter-call-delay-distributionInter-Call Delay Distribution

MetricMeanP50P90P99Inter-call delay (seconds)10.55.223.081.4

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#delay-by-turn-numberDelay by Turn Number

TurnAvg Delay (s)Median (s)N Trials24.84.661035.74.661046.64.561058.74.9610610.04.9610711.44.9609811.34.5607913.05.36041010.95.05981113.05.35881211.55.05761311.75.45661411.85.25571511.15.05401612.25.05241712.35.75031811.35.44891910.75.54772011.16.14612511.06.23883010.35.13103511.16.02414014.16.41834512.46.6133509.95.5935511.05.6746013.09.552659.04.733708.36.5317511.55.0228012.77.2158510.57.310

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#6-workload-characteristics6. Workload Characteristics

  • 131:1 input:output ratio— massively prefill-dominated
  • Context grows ~2,242 tokens/turnon average
  • Cache:New-input ratio = 16.1:1— for every 1 token of new compute, 16.1 tokens are served from cache
  • 20,230 total LLM callsacross 610 trials, avg 33 sequential calls per trial
  • Avg output per call: 520tokens (median 246)

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#compute-distribution-heavy-tailCompute Distribution (Heavy-Tail)

Uncached prefill compute is concentrated in a small fraction of calls:

Top % of Calls# Calls% of Uncached Compute1%20220.5%5%1,01149.6%10%2,02364.2%20%4,04680.0%

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#context-growth-by-phaseContext Growth by Phase

PhaseTurnsAvg Growth/TurnExploration (turns 2-5)2-5~6,166Active coding (turns 6-12)6-12~2,535Iteration (turns 13+)13-100~1,410

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#9-failed-trials-analysis9. Failed Trials Analysis

120 total failuresout of 731 trials.

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#by-root-causeBy Root Cause

Root Cause# TrialsRepos AffectedPackage not found108protonmail/webclients (65), gravitational/teleport (35), future-architect/vuls (5), element-hq/element-web (1), flipt-io/flipt (1), navidrome/navidrome (1)Setup timeout7ansible/ansible (2), internetarchive/openli (2), element-hq/element-web (1), flipt-io/flipt (1), gravitational/teleport (1)NonZeroAgentExitCodeError: Command failed (exit 1): set -euo pipefail; if ldd --version 2>&1grep -qi mus3DownloadVerifierDirError: Failed to download verifier directory from environment2ansible/ansible (1), qutebrowser/qutebrowse (1)

https://huggingface.co/datasets/Inferact/codex_swebenchpro_traces#by-repoBy Repo

RepoErrorsTotal TrialsFailure Rateprotonmail/webclients6565100%gravitational/teleport367647%future-architect/vuls5628%ansible/ansible3963%flipt-io/flipt3854%internetarchive/openli3913%element-hq/element-web2564%navidrome/navidrome2574%qutebrowser/qutebrowse1791%

Downloads last month1,197

相似文章

@LinQingV: 之前做LLM推理芯片架构探索的时候，我把四大AI推理ASIC公司的架构都翻过一遍。Groq、SambaNova、Tenstorrent、Cerebras。前三家的思路虽然各有侧重，但底层逻辑都在同一个框架里：片上大SRAM + dataf…

X AI KOLs Timeline

The article analyzes the AI inference ASIC architectures of Groq, SambaNova, Tenstorrent, and Cerebras, highlighting Cerebras's unique wafer-scale engine design. It discusses the benefits of deterministic latency and high bandwidth for LLM inference, while noting challenges like yield, cost, and KV cache bottlenecks.