HPCA 2027 #884 · Ham, Bae, Lee, Jeon, Kim (POSTECH) · arXiv:2608.03555v1
KARAT 리뷰 분석: 약점 원문 대조와 대응 계획
원문
papers/karat_2608.03555.pdf (14쪽) · §IV-A p.8 = 논문이 그렇게 쓴 절·쪽 · Rev D = 리뷰어가 쓴 내용 · 해석 = 원문·리뷰에서 요약자가 끌어낸 판단 · 논문에 없음 = 원문 수치로 계산한 추정·제안0한눈에 보기
리뷰어 5명이 모두 Weak reject(2)를 주었다. 가장 많이 겹친 지적은 simulation 을 믿을 수 없다는 것이며, 5명 모두 적어도 한 갈래로 이를 짚었다 해석.
원문과 대조하면 약점 15개 중 10개는 원문 문장이 지적을 그대로 뒷받침하고, 3개는 일부만 맞으며, 2개는 오독이다 해석.
0.1
0.1.1문제
headline 수치(throughput/TDP 2.09–6.13×)는 MIG proxy 로 만든 KARAT latency, area scaling 으로 추정한 power, 250K token 에서 끝나는 simulation 이라는 세 가정 위에 있다 §IV-A p.8–9 §IV-F p.11.
0.1.2현상
5명 모두 device 모델 검증을 요구했고, 4명은 TDP 로만 비교한 점을, 4명은 HW novelty 를 지적했다. Expert 인 E 만 Soundness·Novelty 에 3점을 주었다 Rev A–E.
0.1.3원인
논문이 스스로 “Any programmable core type … would serve equally well” 이라고 써서 HW 기여를 낮추었고, 검증 방법은 §IV-A 의 한 문단뿐이다 §III-D p.6 해석.
0.1.4결과
simulation 을 충분히 길게 다시 돌리는 것이 첫 단계다. 그 결과를 바탕으로 power·proxy 오차·CMR 을 정량으로 방어하고, claim 은 “retrieval indexer 에 맞춘 compute sizing” 으로 좁힌다 해석.
0.2
0.2.1
5 / 5
simulation·device 모델 불신을 지적한 리뷰어
0.2.2
4 / 5
TDP-only 비교·cost 를 지적한 리뷰어
0.2.3
10 / 15
원문으로 확인되는 정당한 지적 (부분 3 · 오독 2)
0.2.4
≈ 2.25 s
D 가 원문 수치로 계산한 simulation 길이
1리뷰 점수와 리뷰어 성향
A~D 는 모두 Soundness 2, Novelty 2 이고, 가장 전문성이 높은 E 만 3, 3 을 주었다 Rev A–E.
E 는 아이디어에 호의적이므로 champion 이 될 가능성이 있고, D 는 원문 수치로 직접 계산해 온 만큼 답하면 점수가 오를 여지가 크다 해석.
1.1
| 리뷰어 | Merit | Soundness | Novelty | 전문성 | 성향 (해석) |
|---|---|---|---|---|---|
| 1.1.1A | 2 | 2 | 2 | 2 Knowledgeable | novelty 에 회의적이다. related work 와 claim 조정으로 설득할 수 있다 |
| 1.1.2B | 2 | 2 | 2 | 2 Knowledgeable | 원문 문장을 정확히 읽는다. 반박보다 수용하는 편이 유리하다 |
| 1.1.3C | 2 | 2 | 2 | 2 Knowledgeable | 가장 엄격하며 방법론 전반을 불신한다. 오독이 한 건 있다 |
| 1.1.4D | 2 | 2 | 2 | 3 Somewhat familiar | 원문 수치로 계산해 온다. “calibrated model 이면 충분” 이라고 했다 |
| 1.1.5E | 2 | 3 | 3 | 1 Expert | insight 를 좋게 본다. champion 후보다 |
2핵심 약점: 원문 대조
판정은 세 가지로 나눈다. 정당은 원문 문장이 지적을 그대로 뒷받침한다는 뜻이고, 부분은 일부는 원문에 답이 있다는 뜻이며, 오독은 원문과 다르다는 뜻이다.
분석 칸의 계산은 원문 수치로 요약자가 한 것이며 측정한 값이 아니다 논문에 없음.
2.1치명: 결과 전체를 흔드는 것
2.1.1
| 약점 | 지적 | 원문 근거 | 판정 | 분석 |
|---|---|---|---|---|
| 2.1.1.1W1 simulation 길이 | D | “Each run spanned 250K generated tokens or 300 s … excluded the first 20% as warmup.” §IV-A p.9 | 정당 | 111K tok/s 이면 2.25 s 로 TBT 100 ms 기준 약 22 step 이다. turn 당 decode 가 47–263 token 이라 대부분 session 이 turn 을 하나도 끝내지 못한다 논문에 없음. P99 와 CMR ablation 이 모두 이 구간에서 나왔다. |
| 2.1.1.2W2 H200 MIG proxy | A B C D E | “For KARAT we used an H200 MIG 1g.35gb instance, which provides the same memory bandwidth, and scaled the SM count.” §IV-A p.8–9 | 정당 | peak bandwidth 만 맞추었다. LPDDR5X 의 bank 구조와 timing 에서 top-k·gather·hash access 가 어떻게 되는지는 모델에 없고, 오차 범위도 제시하지 않았다. |
| 2.1.1.3W3 HW 기여 부재 | A B C E | “Any programmable core type that satisfies the same OI requirement would serve equally well.” §III-D p.6 | 정당 | 논문이 스스로 HW 기여를 부정한 문장이다. “KARAT’s 1.87× advantage comes from the compute placed next to that capacity” §IV-B p.9 도 이득의 원천이 provisioning 이라는 A·B 의 해석과 맞는다 해석. |
| 2.1.1.4W4 TDP-only 비교 | A C D E | “normalized by TDP as system power cannot be equalized” §IV-A p.8, Table V 는 host CPU 를 생략한다 p.6 | 정당 | KARAT node 는 LPDDR5X 16 TB, device 32개, switch 로 이루어진다. cost 와 system power 는 한 번도 제시하지 않았다. |
2.2높음: 방어 논리에 구멍이 있는 것
2.2.1
| 약점 | 지적 | 원문 근거 | 판정 | 분석 |
|---|---|---|---|---|
| 2.2.1.1W5 static power | B C D | “scaled the measured H200 idle power by the die area ratio … yielding an upper bound. The maximum power we measured was 147.7 W” §IV-F p.11 | 정당 | LPDDR5X 512 GB 의 background·refresh power 항목이 없다. 175 − 147.7 = 27.3 W 의 여유분으로 이것을 덮을 수 있는지 계산하면 방어할 수 있다 논문에 없음. |
| 2.2.1.2W6 CMR drift 서술 | B | “ℓ(m,d) drifts by at most the difference in request count on d … so no further trigger is needed.” §III-F p.7 | 정당 | drift 는 step 마다 누적되므로 서술이 틀렸다. 다만 동시 session 이 4–5K 이고 turn 당 decode 가 47–263 token 이면 step 마다 약 15–100개 request 가 끝나 rebalance 가 거의 매 step 일어난다 논문에 없음. 측정해서 보이면 된다. |
| 2.2.1.3W7 CMR 의 GPU batch imbalance | B | Algorithm 1 은 device 별로 ℓ(m,d) 를 먼저, |m| 을 tie-break 로 비교한다 §III-F p.7 | 부분 | B 의 1 대 10 예시는 device 하나 기준이다. GPU 는 128–192개 device 를 합친 |m| 을 보므로 평균화될 가능성이 크다 해석. step 별 Σ|m| 차이를 측정해야 확정된다. |
| 2.2.1.4W8 network 총량 | D E | “these transfers take 43–232 µs per request and decoding step, below 0.25% of the 100 ms TBT SLO.” §III-B p.5 | 정당 | request 하나 기준이다. 총량은 step 당 약 10–46 GB 로, 100 ms 안에 옮기려면 0.1–0.46 TB/s 가 필요하다. 이는 최적 구성의 GPU node 2–4개 × 400 GB/s 의 6–58% 이며 all-to-all 과 link 를 나눠 쓴다 논문에 없음. link bandwidth 를 1/4 로 줄이면 8–32% 떨어진다는 결과도 있다 Fig. 13 p.10. |
| 2.2.1.5W9 OFMS cross-rank 순서 | D | “switching micro-batches only when the current operation blocks … Nor does the schedule add any cross-rank synchronization beyond the all-to-all” §III-E p.7 | 정당 | rank0 이 µB0 dispatch 에, rank1 이 µB1 dispatch 에 들어가면 collective 의 짝이 맞지 않는다. micro-batch 마다 communicator 나 buffer 를 따로 두는지 명시해야 한다 해석. |
| 2.2.1.6W10 관련 연구 | A E | MegaScale-Infer [101], LongSight [75], M2NDP [28] 는 인용했다 §V p.11–12 | 부분 | attention–MoE disaggregation 은 MegaScale-Infer 로 이미 인용했으므로 E 에게 그 문장을 가리키면 된다. NanoFlow·H2-LLM·Lamina 는 인용이 없고, LongSight 와의 정량 비교도 없다. |
2.3보통: 범위·서술 문제
2.3.1
| 약점 | 지적 | 원문 근거 | 판정 | 분석 |
|---|---|---|---|---|
| 2.3.1.1W11 baseline 공정성 | C | “For each system, we then selected the EP and TP degrees per model and workload profile using the search method” §IV-A p.8 | 오독 | search 는 모든 system 에 적용했다. HiSparse 는 GPU 에 host DRAM 2 TB 를 붙이고 hit rate 95% 를 가정했으므로 오히려 유리한 조건이다. 남는 gap 은 GPU + CXL memory baseline 하나다. |
| 2.3.1.2W12 “MIG 가 정확히 18 SM” | A | “… and scaled the SM count” §IV-A p.9 | 오독? | 원문은 SM 수를 scaling 했다고 쓰므로 1g.35gb 의 SM 수가 18 이 아닐 수 있다. 실제 SM 수를 확인하면 A 의 오해를 정정할 수 있다 (확인 필요). |
| 2.3.1.3W13 multi-turn prefill | D | “only the KV cache of the newly prefilled tokens is transferred” §III-B p.5, “94–97% … hit the prefix cache” §II-A p.3 | 부분 | O1 의 문장은 prefill pool 도 prefix cache 를 가진다는 뜻으로 읽힌다 해석. 그렇다면 KV 사본이 중복되는데, 원문은 이를 명시하지 않았고 그 capacity 는 TDP 에서 빠져 있다. |
| 2.3.1.4W14 quality 미보고 | C | §IV-A 에 Quest·STARC·MagicPIG 의 page size·top-k·hash 설정이 없다 §IV-A p.8 | 정당 | 설정값조차 원문에 없다. 설정표와 accuracy 가 모두 필요하다. |
| 2.3.1.5W15 serving 모델 범위 | C E | “closed-loop at a fixed concurrency N” §IV-A p.8, SLO 는 100 ms P99 TBT 하나다 | 정당 | open-loop 구성과 SLO sweep 이 없고, prefill pool 은 고정했다 §II-A p.3. |
3simulation 불신의 세 층
simulation 불신은 한 덩어리가 아니라 입력 LUT, power 모델, run 자체의 세 층으로 나뉜다 해석.
세 층은 대응 비용이 다르다. run 과 power 는 재실행·계산으로 빨리 해소되지만, 입력 LUT 는 calibration 이 필요하므로 sensitivity 로 오차 범위를 묶는 것이 현실적이다 해석.
3.1
| 층 | 무엇을 못 믿는가 | 지적 | 원문 근거 | 대응 비용 |
|---|---|---|---|---|
| 3.1.1① 입력 LUT | KARAT kernel latency 를 H200 MIG 에서 재고 SM 수로 scaling 한 값 | A B C D E | §IV-A p.8–9 | 높음 calibration 필요 |
| 3.1.2② power 모델 | 분모인 TDP 가 die area scaling 으로 추정한 값 | B C D | §IV-F p.11 | 낮음 계산 |
| 3.1.3③ run 자체 | 약 2 s 구간, closed-loop, simulator 를 실제와 비교한 적 없음 | C D | §IV-A p.8–9 | 낮음 재실행 |
3.2
3.2.1문제
C 는 “end-to-end validation against any existing heterogeneous system” 이 없다고 지적했다 Rev C. KARAT 쪽은 실물이 없어 검증할 수 없다.
3.2.2현상
원문에는 simulator 결과를 실제 serving 과 비교한 수치가 없다. GPU-only baseline 도 측정한 kernel 로 simulation 한 값이다 §IV-A p.8.
3.2.3원인
GPU-only baseline 은 실제 H200 에서 돌릴 수 있는데도 simulator 와 비교하지 않았다 해석.
3.2.4조치
H200 에서 GPU-only baseline(예: SGLang + DeepSeek-V3.2)을 실제로 돌려 simulator 와의 throughput·TBT 오차를 보인다. 그러면 ③ 층이 해소되고, 남는 불확실성이 ① 층의 “KARAT LUT 가 맞느냐” 하나로 좁혀진다 논문에 없음.
3.3
| 순서 | 할 일 | 해소하는 층 |
|---|---|---|
| 3.3.11 | run 길이를 늘리고 seed 여러 개로 재실행한다 | ③ |
| 3.3.22 | GPU-only baseline 을 실제 H200 serving 과 비교한다 | ③ simulator 신뢰 |
| 3.3.33 | KARAT LUT 오차 sensitivity 곡선을 만든다 (“×2 느려져도 Y× 유지”) | ① 오차 범위 |
| 3.3.44 | LPDDR5X background·refresh power 를 계산한다 | ② |
4대응 계획
rebuttal 은 분량이 제한되고 5명 모두에게 답해야 하며, 새 HW 를 만들 시간은 없다. 다만 D 는 “A calibrated model would be sufficient; a physical implementation is not required” 라고 명시했다 Rev D.
요구의 대부분은 기존 simulator 로 가능한 재실행·sensitivity·계측이므로 P0 → P1 → P2 순서로 진행한다. P0-1 의 재실행 결과가 나온 뒤에 나머지 수치를 뽑는다 해석.
4.1P0: rebuttal 핵심, 순서대로
4.1.1
| 할 일 | 해소 | 산출물 | 비용 |
|---|---|---|---|
| 4.1.1.1simulation 재실행. 250K token 상한을 없애고, 모든 session 이 turn 을 여러 번 끝낼 만큼 길게, seed 3개 이상으로 돌린다. 실제 simulated 시간, 완료 turn 수, P99 집계 방식을 보고한다 | W1 · D | seed 별 throughput·P99 표, 구간 길이에 따른 수렴 곡선 | 낮음 |
| 4.1.1.2CMR 계측. step 별 rebalance 횟수, device 별 ℓ 차이, GPU 쪽 Σ|m| 차이를 기록하고 §III-F 의 문장을 정정한다 | W6 W7 · B | rebalance 간격·imbalance 분포 | 낮음 |
| 4.1.1.3power 재산정. LPDDR5X JEDEC IDD 값으로 512 GB 의 background·refresh 를 계산하고, PHY/controller idle 과 CXL 을 더해 27.3 W 여유분과 비교한다. 넘으면 TDP 를 올려 다시 계산한다 | W5 · B C D | component 별 W breakdown 표 | 낮음 |
| 4.1.1.4proxy 오차 sensitivity. KARAT 단계별(scan, top-k, gather, attend) latency 를 ×1.25·×1.5·×2 로, bandwidth 를 60–80% 로 바꿔 본다. 1g.35gb 의 실제 SM 수도 확인한다 | W2 W12 · A C D E | “×X 느려져도 Y× 유지” 곡선 | 낮음 |
| 4.1.1.5network 총량. step 당 GPU↔KARAT 총 byte 와 link utilization 을 보고하고, all-to-all 과 link 를 공유하는 구성도 돌린다 | W8 · D E | link utilization 표 | 낮음 |
| 4.1.1.6서술 보강. OFMS 의 micro-batch 별 communicator, multi-turn prefix cache 의 위치, positioning 표(NanoFlow · H2-LLM · Lamina · MegaScale-Infer · LongSight · M2NDP)를 쓴다 | W9 W10 W13 · A D E | rebuttal 문단·차별점 표 | 낮음 |
4.2P1: rebuttal 에 수치로 넣을 추가 실험
4.2.1
| 할 일 | 해소 | 산출물 | 비용 |
|---|---|---|---|
| 4.2.1.1GPU-only baseline 을 실제 H200 serving 과 비교해 simulator 오차를 보인다 (3절) | W1 W2 · C D | simulator vs 실측 표 | 중간 |
| 4.2.1.2system-level 지표: host·switch 를 포함한 system W, 절대 tokens/s, energy/token, 대략적인 $ (LPDDR5X $/GB, die) | W4 · A C D E | per-TDP / per-system-W / per-$ 표 | 중간 |
| 4.2.1.3tighter SLO: P99 TBT 50 ms 등으로 sweep 한다 | W15 · E | SLO sweep 그림 | 낮음 |
| 4.2.1.4provisioning 과 programmability 분리: SPNM 에 KARAT 와 같은 compute(250 TFLOPS FP8)를 준 variant 를 만든다. MagicPIG 에서 차이가 나면 R4 가 입증된다 | W3 · A B D | ablation 그림 | 중간 |
| 4.2.1.5LongSight 와 공통 workload(dot-product top-k)로 비교한다 | W10 · E | 비교 막대 | 중간 |
| 4.2.1.6training-free 설정표와 quality (Quest · STARC · MagicPIG, 평가 설정에서) | W14 · C | 설정·accuracy 표 | 중간 |
| 4.2.1.7GPU + CXL memory baseline (HiSparse 의 host DRAM 을 CXL 로 교체) | W11 · C | baseline 추가 | 중간 |
4.3P2: revision / 재투고용
4.3.1
| 할 일 | 해소 | 산출물 | 비용 |
|---|---|---|---|
4.3.1.1GPNM core 를 M2NDP [28] 계열로 구체화하고, cycle-level + LPDDR5X DRAM 모델로 단계별 kernel 을 돌려 MIG proxy 와의 오차를 비교한다. 저자 그룹의 자산이라 가장 현실적인 경로로 보인다 해석 (M2NDP_Detour/ 활용 가능 여부 확인 필요) | W2 W3 · A B C D E | per-stage 검증표, microarchitecture 절 | 높음 |
| 4.3.1.2package/board 구성안: 64 channel, LPDDR5X package 수, die-edge PHY. LPDDR5X 대용량 선례(예: Grace)와 비교한다 (수치 확인 필요) | C | floorplan 그림 | 중간 |
| 4.3.1.3open-loop arrival, prefill pool 과의 coupling | W15 · C | arrival rate sweep | 중간 |
4.4원문에서 고칠 문장
4.4.1
| 위치 | 현재 문장 | 문제 |
|---|---|---|
| 4.4.1.1§III-D p.6 | “Any programmable core type … would serve equally well.” | HW 기여를 스스로 부정한다. “요구 OI 를 만족하도록 sizing 한 것이 기여” 로 바꿔 쓴다 |
| 4.4.1.2§III-F p.7 | “drifts by at most the difference in request count … no further trigger is needed.” | 누적을 무시한 틀린 서술이다. 측정한 rebalance 간격으로 대체한다 |
| 4.4.1.3§III-B p.5 | “43–232 µs per request … below 0.25% of the 100 ms TBT SLO.” | request 하나 기준이라 총량을 묶지 못한다. 총 byte 와 link utilization 으로 바꾼다 |
| 4.4.1.4§IV-F p.11 | “… yielding an upper bound.” | LPDDR background 가 빠져 있어 upper bound 가 아니다 |
| 4.4.1.5§IV-A p.9 | “250K generated tokens or 300 s” | 구간이 약 2 s 뿐이다. 재실행한 뒤 조건을 바꾼다 |
5리뷰어별 해석
각 리뷰어가 인정한 점, 핵심 우려, 원문과 대조한 결과, 설득 포인트를 차례로 정리한다.
원문 대조와 설득 포인트는 요약자의 판단이다 해석.
5.1Review A: novelty 회의형
5.1.1
5.1.1.1인정
workload characterization 이 가장 강한 부분이라고 보았다. 세 mechanism 의 OI 차이와 ablation 도 유용하다고 했다 Rev A.
5.1.1.2우려
125 BF16 TFLOPS 가 H200 의 18 SM 분량이고 latency 는 MIG 에서 측정했으므로, KARAT 를 “LPDDR5X 를 단 작은 Hopper” 로 본다 Rev A.
5.1.1.3원문 대조
989 × 18/132 × 1.83/1.98 ≈ 125 이므로 A 의 계산은 맞다 논문에 없음. 그러나 “MIG 가 정확히 18 SM” 이라는 부분은 원문의 “scaled the SM count” 와 어긋난다 (W12).
5.1.1.4설득
NanoFlow 는 homogeneous GPU 안에서의 overlap 이고 OFMS 는 이종 device 사이에서 expert all-to-all 을 숨긴다는 점으로 구분한다. H2-LLM 과는 대상 연산과 capacity 규모로 구분한다 해석.
5.1.2
| 질문 | 대응 |
|---|---|
| 5.1.2.1OFMS 는 NanoFlow 식 fine-grained overlap 과 무엇이 다른가 | 4.1 P0 서술 보강 |
| 5.1.2.2H2-LLM 식 compute–bandwidth co-design 을 넘어서는 아키텍처 기여는 무엇인가 | 4.1 P0 서술 보강, 4.2 P1 provisioning 분리 |
원문 요지 번역
- 5.1.3
- 5.1.3.1KARAT device 는 충분히 정의되지 않았고, compute throughput·latency·area·power 를 기존 H200 의 일부에서 끌어왔다.
- 5.1.3.2논문 스스로 “요구 OI 를 만족하는 programmable core 면 무엇이든 된다” 고 밝혔다.
- 5.1.3.3core 구성, dataflow, NoC, memory scheduling, irregular selection·gather 지원에 대한 설명이 거의 없다.
- 5.1.3.4최대 32 device · 16 TB node 에 대해 area·packaging cost·TCO 분석 없이 TDP 로만 비교했다.
- 5.1.3.5주된 기여는 새 PNM 아키텍처가 아니라 workload characterization 과 resource provisioning 이라고 본다.
5.2Review B: 원문 검증형
5.2.1
5.2.1.1인정
문제 설정과 indexer characterization, 실행 모델, scheduling·link·core 평가를 좋게 보았다 Rev B.
5.2.1.2우려
이득의 원천이 아키텍처인지 provisioning 인지 가려지지 않는다. CMR drift, static power, GPU 쪽 imbalance 도 문제로 들었다 Rev B.
5.2.1.3원문 대조
지적 네 개가 모두 원문 문장(§III-F, §IV-F, Algorithm 1)과 정확히 대응하므로 정당하다 해석.
5.2.1.4설득
틀린 서술은 인정하고 측정값으로 대체한다. device 여러 개를 합치면 imbalance 가 평균화된다는 점을 수치로 보인다 해석.
5.3Review C: 방법론 불신형
5.3.1
5.3.1.1인정
dense PIM 과 retrieval sparse attention 의 차이, 실제 trace, 여러 모델과 P99 SLO 를 좋게 보았다 Rev C.
5.3.1.2우려
device 검증, 물리 integration, simulation-only, closed-loop, 비교 공정성, quality 여섯 가지를 들었다 Rev C.
5.3.1.3원문 대조
“search 가 KARAT 에만 유리하다” 는 오독이다. search 는 모든 system 에 적용했다 §IV-A p.8. training-free 설정값이 원문에 없다는 지적은 정당하다.
5.3.1.4설득
질문 다섯 개에 수치로 하나씩 답한다. 오독은 원문 문장을 인용해 짧게 정정한다 해석.
5.3.2
| 질문 | 대응 |
|---|---|
| 5.3.2.1index scan·top-k·gather·MLA/GQA attention 에서 MIG linear scaling 이 얼마나 정확한가 | 4.1 P0 proxy sensitivity, 4.3 P2 cycle-level |
| 5.3.2.2175 W 에 LPDDR·PHY·static·CXL·board 손실이 포함되는가 | 4.1 P0 power 재산정 |
| 5.3.2.364 channel · 512 GB 의 package/board 설계는 무엇인가 | 4.3 P2 package |
| 5.3.2.4절대 throughput·cost·평균 power 로 비교하면 어떤가 | 4.2 P1 system-level |
| 5.3.2.5training-free 기법의 quality 는 얼마인가 | 4.2 P1 quality |
5.4Review D: 수치 검증형
5.4.1
5.4.1.1인정
KV capacity → batch 크기 → MoE 효율의 연결을 명확하다고 보았고, KARAT 가 지는 경우도 보고한 점을 좋게 보았다 Rev D.
5.4.1.2우려
250K token 이면 약 2.25 s 로 끝난다고 계산했다. P99 집계 방식, stationarity, OFMS 순서, multi-turn, network 총량도 물었다 Rev D.
5.4.1.3원문 대조
계산은 원문 수치(Fig. 14, §IV-A)로 재현된다. OFMS 와 multi-turn 도 원문에 설명이 없으므로 모두 정당하다 해석.
5.4.1.4설득
calibrated model 이면 충분하다고 했으므로 P0 의 재실행과 proxy sensitivity 가 곧 답이다. 설득 가능성이 가장 높다 해석.
5.4.2
| 질문 | 대응 |
|---|---|
| 5.4.2.1더 긴 run 과 여러 seed 에서도 throughput·P99 가 안정적인가 | 4.1 P0 재실행 |
| 5.4.2.2성능과 175 W 는 어떻게 검증했는가 (MIG→LPDDR mapping, memory subsystem power) | 4.1 P0 power·proxy |
| 5.4.2.3scheduling 과 multi-turn interface 는 어떻게 구현했는가 | 4.1 P0 서술 보강 |
5.5Review E: Expert, champion 후보
5.5.1
5.5.1.1인정
retrieval sparse attention 이 traffic 은 줄이지만 capacity 는 줄이지 못하고, index scan 이 기존 PIM 보다 많은 compute 를 요구한다는 insight 를 좋게 보았다 Rev E.
5.5.1.2우려
기여를 “indexer 용 compute sizing + serving 통합” 으로 본다. LongSight 정량 비교, LPDDR 검증, system cost, tighter SLO 를 요구했다 Rev E.
5.5.1.3원문 대조
attention–FFN disaggregation 은 MegaScale-Infer [101] 로 이미 인용했지만 대비 설명이 약하다. Lamina 는 인용이 없다 §V p.11.
5.5.1.4설득
E 가 규정한 기여를 그대로 claim 으로 채택한다. LongSight 비교가 가장 효과적일 것으로 보인다 해석.
5.5.2
| 질문 | 대응 |
|---|---|
| 5.5.2.1programmable CXL near-memory·attention–FFN disaggregation 대비 기여, LongSight 비교 | 4.1 P0 서술 보강, 4.2 P1 LongSight |
| 5.5.2.2LPDDR 모델 검증, bandwidth 저하·contention 시 이득 변화 | 4.1 P0 proxy·network |
| 5.5.2.3system power·tighter SLO·32 device node 의 cost | 4.2 P1 system-level·SLO |