diff --git a/_posts/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities.md b/_posts/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities.md
new file mode 100644
index 000000000..cfcdf125a
--- /dev/null
+++ b/_posts/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities.md
@@ -0,0 +1,152 @@
+---
+layout: blog_detail
+title: "FBTriton 인프라: 업스트림 반영, 계층적 검증, 이상과 현실"
+author: "Meta Triton Team: Daohang Shi, Xu Zhao, Agron Tsai, Wenyuan Chi, Alexey Loginov"
+authors:
+  - Daohang Shi
+  - Xu Zhao
+  - Agron Tsai
+  - Wenyuan Chi
+  - Alexey Loginov
+ext_author: Junghwan Park (박정환)
+category: ["pytorch.org", "translation"]
+date: 2026-07-30 12:00:00
+image: /assets/blog/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities/hero.png
+org_title: "FBTriton Infra: Upstream Ingestion, Hierarchical Validation, Ideals vs Realities"
+org_link: https://pytorch.org/blog/fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities/
+---
+
+![FBTriton 인프라: 업스트림 반영, 계층적 검증, 이상과 현실 / FBTriton Infra: Upstream Ingestion, Hierarchical Validation, Ideals vs Realities](/assets/blog/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities/hero.png){:style="width:100%"}
+
+### TL;DR
+
+Meta의 FBTriton 인프라가 에이전트 기반 반영(agentic ingestion)과 계층화된 L1/L2/L3 검증 프레임워크로 업스트림 Triton과 동기화를 유지하면서, TLX와 autoWS 같은 자체 GPU 컴파일러 혁신을 어떻게 뒷받침하는지 살펴봅니다.
+> Learn how Meta's FBTriton infrastructure powers custom GPU compiler innovations like TLX and autoWS while staying synced with upstream Triton using agentic ingestion and a stratified L1/L2/L3 validation framework.
+
+## fbtriton 소개 / Introduction of fbtriton
+
+Triton은 Meta의 AI 하드웨어 가속 전략에서 근간을 이루는 요소입니다. Triton은 OpenAI가 개발하고 유지보수하지만, 업스트림 저장소만으로는 내부에서 올라오는 기능 요청, 하드웨어에 특화된 최적화, 긴급한 버그 수정을 온전히 담아낼 수 없습니다. 이와 병행해 TLX/torchTLX와 autoWS를 비롯한 자체 GPU 최적화 솔루션을 개발하고 있는데, 이들의 개발 일정과 코드 구조가 업스트림과 늘 맞아떨어지지는 않습니다.
+> Triton is a foundational element of our AI hardware acceleration strategy. While Triton is developed and maintained by OpenAI, the upstream repository alone cannot fully accommodate our internal feature requests, hardware-specific optimizations, and urgent bug fixes. In parallel, we are developing our own GPU optimization solutions, including TLX/torchTLX and autoWS, whose development timelines and code structures do not always align with upstream.
+
+이 간극을 메우기 위해 이러한 혁신들을 fbtriton(`pip install fbtriton`)이라는 다운스트림 포크(downstream fork)에 모았습니다. 덕분에 업스트림과의 차이(delta)를 최대한 작게 유지하면서도 Meta의 워크로드에 최적화된 기능을 빠르게 개발할 수 있습니다. 이 저장소는 내부 코드베이스로 계속 동기화되며, 사내 조정은 최소한만 거친 채 Meta의 여러 서비스에서 GPU 학습과 추론 워크로드를 뒷받침합니다.
+> To bridge this gap, we consolidate our innovations into a downstream fork called fbtriton (`pip install fbtriton`). This allows us to rapidly develop features optimized for our workloads while keeping the delta from upstream as small as possible. The repository is continuously synchronized into our internal codebase with minimal in-house adjustment and powers GPU training and inference workloads across Meta's services.
+
+2025년 3분기에 통합된 이후 fbtriton은 Meta 엔지니어와 NVIDIA, AMD, 학계 협력자를 비롯한 외부 파트너가 컴파일러와 DSL 혁신을 함께 설계하고, 이를 오픈 소스(OSS)와 업계가 평가할 수 있도록 열어 두는 최적화 활주로(runway) 역할을 해 왔습니다.
+> Since its consolidation in Q3 2025, fbtriton has served as an optimization runway for Meta engineers and external partners, including NVIDIA, AMD, and academic collaborators, to co-design compiler and DSL innovations and make them accessible for OSS and industry's evaluation.
+
+이번 글에서는 지속적인 업스트림 반영(upstream ingestion), L1/L2/L3 검증 계층, 그리고 엔지니어링 이상과 프로덕션 현실 사이의 실질적인 간극을 다룹니다.
+> This blog covers continuous upstream ingestion, the L1/L2/L3 validation hierarchy, and the practical gap between engineering ideals and production realities.
+
+## 업스트림 격차 좁히기: 위험도로 나눈 에이전트 기반 번들링 / Closing the Upstream Gap: Risk-partitioned Agentic Bundling
+
+빠르게 움직이는 업스트림과의 격차를 작게 유지하면서 Meta에서 출발한 최적화를 적극적으로 개발하는 일은 fbtriton 입장에서는 쉽지 않습니다.  
+다운스트림 포크를 유지하려면 보통 두 전략 중 하나를 골라야 합니다. 주기적으로 트렁크 전체를 리베이스(full-trunk rebase)하거나, 계속 체리픽(cherry-pick)하는 것입니다. 수정 사항을 안정적으로 유지하고, 대규모 리베이스가 낳는 구조적 불확실성과 마찰에서 일상적인 개발을 떼어 놓기 위해 지속적인 체리픽을 택했습니다.  
+핵심 마찰은 컴파일러 스택의 아키텍처 차이에서 나옵니다. fbtriton은 레이아웃 인터페이스, 양자화, 워프 특화(warp specialization)에 각기 다른 전략과 설계를 사용합니다.  
+CI 엔지니어에게 수동 충돌 해결을 잔뜩 떠안기지 않고 쌓인 백로그를 해소하기 위해, 업스트림 커밋을 큰 저위험 번들과 컨텍스트가 많이 필요한 위험 체인으로 나누는 에이전트 루프(agentic loop)를 만들었습니다.
+> It is not easy for fbtriton to aggressively develop Meta-inspired optimizations while keeping the gap against a fast-moving upstream small.  
+> Maintaining a downstream fork usually forces a choice between two strategies: periodic full-trunk rebases or continuous cherry-picking. We chose continuous cherry-picking to keep our modifications stable and decouple daily development from the structural uncertainty and friction of large rebases.  
+> The core friction comes from architectural divergence in the compiler stack. fbtriton uses distinct strategies and designs for layout interfaces, quantization, and warp specialization.  
+> To clear the accumulated backlog without overwhelming CI engineers with manual conflict resolution, we built an agentic loop that separates upstream commits into large low-risk bundles and context-heavy risky chains.
+
+**1단계: 의존성 추적(Dependency tracking).**  
+들어오는 패치가 진행 중인 복잡한 변경(이른바 기존 위험 체인)과 연결된 파일이나 심볼(symbol)을 건드리는지 시스템이 검사합니다.
+> **Step 1: Dependency tracking.**  
+> The system checks whether an incoming patch touches files or symbols linked to an ongoing complex change, also known as an existing risky chain.
+
+**2단계: 경로 선택(Path selection).**  
+연관성이 발견되면, 의존 관계가 있는 변경들의 순서를 올바르게 유지하기 위해 패치를 그 기존 체인에 자동으로 묶습니다. 그렇지 않으면 해당 커밋은 안전한 것으로 보고 [#1872](https://github.com/facebookexperimental/triton/pull/1872) 커밋처럼 큰 저위험 번들에 병합합니다.
+> **Step 2: Path selection.**  
+> If a correlation is found, the patch is automatically grouped into that existing chain to preserve the correct ordering of dependent changes. Otherwise, the commit is considered safe and merged into a large low-risk bundle, such as commit [#1872](https://github.com/facebookexperimental/triton/pull/1872).
+
+### 운영 지표: 반영 추적 / Operation metrics: Ingestion Tracking
+
+진행 상황을 정확히 측정하기 위해 서로 구분되는 두 가지 운영 지표를 추적합니다.
+> To measure progress accurately, we track two distinct operational metrics.
+
+**주 지표: 업스트림 대비 뒤처진 일수(Days Behind Upstream)**  
+업스트림 반영의 최신 지점(tip)이 업스트림 main 브랜치의 최신 지점보다 며칠 뒤처져 있는지를 추적하는 지표입니다. 드물게는 아주 최근의 업스트림에서 특정 커밋을 긴급히 체리픽하기도 합니다. 이런 개별적인 체리픽은 주 지표에 영향을 주지 않습니다.
+> **Main Metric: Days Behind Upstream**  
+> This metric tracks how many days the tip of our upstream ingestion lags behind the tip of the upstream main branch. In rare circumstances, we may urgently cherry-pick specific commits from very recent upstream. These isolated picks do not affect the main metric.
+
+**견제 지표: 백로그 커밋(Backlog Commits)**  
+반영 지점 뒤에 남은 구멍, 즉 아직 체리픽되지 않고 남아 있는 오래된 업스트림 커밋을 추적하는 지표입니다.
+> **Counter Metric: Backlog Commits**  
+> This metric tracks the holes left behind the ingestion tip: older upstream commits that remain unpicked and outstanding.
+
+두 지표를 분리해 두면 CI 엔지니어는 주 지표를 낮추는 데 집중할 수 있고, 컨텍스트가 많이 필요한 백로그 커밋은 견제 지표를 낮게 유지하도록 비동기적으로 분류(triage)할 수 있습니다. 이렇게 하면 전진하는 진척도와 백로그 정리를 뒤섞지 않고 팀이 효율적으로 운영할 수 있습니다.
+> By decoupling these metrics, CI engineers can focus on driving down the main metric, while context-heavy backlog commits can be triaged asynchronously to keep the counter metric low. This allows the team to operate efficiently without conflating forward progress with backlog cleanup.
+
+### 순서를 벗어난 랜딩 / Out-of-Order Landing
+
+각 커밋이 OSS CI와 내부 CI를 모두 독립적으로 통과하기만 하면, 커밋은 순서와 상관없이 랜딩(landing)할 수 있습니다. 이런 유연성 덕분에 복잡한 의존성 하나에 발목이 잡혀 멈춰 있지 않고, 깔끔한 업스트림 기능을 곧바로 풀어 줄 수 있습니다.  
+다만 이런 방식으로 안전하게 운영하려면 다음 절에서 다루는 견고한 계층적 테스트 프레임워크(stratified hierarchical test framework)가 필요합니다.
+> Commits can be landed out of order as long as each one independently passes both OSS CI and internal CI. This flexibility allows us to unblock clean upstream features immediately instead of stalling behind a single complex dependency.  
+> However, operating this way safely requires a robust, stratified hierarchical test framework discussed in the next section.
+
+## 계층적 테스트 프레임워크 설계 / Designing the Hierarchical Test Framework
+
+LLVM 버전 상향(version bump)을 포함해 위험한 Triton 변경은 프로덕션 스택 전반에 연쇄적인 회귀(regression)를 일으킬 수 있습니다. 이런 문제가 깔끔한 빌드 실패로 나타나는 경우는 드뭅니다. 대신 학습/서빙 효율의 조용한 회귀(silent regression), PT2 컴파일 시간 증가, 또는 모델 성능(정규화 엔트로피, normalized entropy)의 미묘한 드리프트(drift)로 드러날 수 있습니다.  
+모든 커밋에 대해 이 신호 전체를 평가하는 것은 운영 측면에서도, 비용 측면에서도 현실적이지 않습니다. 국소적인 단일 GPU 정확성 테스트는 몇 초면 끝날 수 있지만, 작업(job) 단위 지표를 검증하려면 GPU 클러스터를 몇 시간씩 돌려야 할 수도 있습니다. 실제로는 상대적인 가치와 비용을 기준으로 테스트를 L1/L2/L3 계층으로 정리해 이런 자원 비대칭을 관리합니다.
+> A risky Triton change, including an LLVM version bump, can trigger cascading regressions across the production stack. These issues are rarely clean build failures. Instead, they may appear as silent regressions in training/serving efficiency, increased PT2 compilation time, or subtle drift in model performance (normalized entropy).  
+> Evaluating this entire spectrum of signals for every commit is both operationally and financially impractical. A localized single-GPU correctness test may finish in seconds, while validating job-level metrics may require GPU clusters running for hours. In practice, we manage this resource asymmetry by organizing tests into an L1/L2/L3 hierarchy based on relative value and cost.
+
+**L1: diff 테스트**  
+LIT(LLVM Integrated Tester), Triton 단위 테스트, TLX 튜토리얼 커널 정확성 테스트, 내부 고객의 커널 테스트를 포함한 빠르고 국소적인 테스트입니다. 심각한 기능 파손과 커널 수준의 수치 불일치를 막기 위해 모든 diff에서 실행됩니다.
+> **L1: Diff tests**  
+> Fast, localized tests, including LITs (LLVM Integrated Tester), Triton unit tests, TLX tutorial kernel correctness tests, and internal customers' kernel tests. These are triggered at every diff to prevent major breakage and kernel-level numeric mismatches.
+
+**L2: 트렁크 테스트**  
+필요한 행렬 곱셈 형상(shape)을 훑는 tritonbench 실행이나 분산 학습 작업처럼, 트렁크에서 주기적으로 돌리는 자원 집약적인 통합 테스트입니다. 성능 저하 같은 지표 회귀에 대해 완전히 이분 탐색(bisect)이 가능하므로, 원인이 된 커밋을 자동으로 찾아낼 수 있습니다.
+> **L2: Trunk tests**  
+> Periodic, resource-intensive integration tests run on trunk, such as a tritonbench run sweeping required matrix-multiplication shapes or a distributed training job. These tests are fully bisectable on metric regressions, such as performance degradation, so we can automatically locate the culprit commit.
+
+**L3: 수동 테스트**  
+내부 프로덕션 팀이 그때그때 제공하는, 전적으로 요청 기반(on-demand)의 무거운 프로덕션 워크로드입니다. GPU 시간을 상당히 소모하며, 해당 영역 담당자의 명시적인 지표 승인(sign-off)이 필요합니다.
+> **L3: Manual tests**  
+> Heavy, fully on-demand production workloads provided dynamically by internal production teams. These consume significant GPU hours and require explicit metric sign-off from area owners.
+
+## 논의: 실무에서 마주치는 엔지니어링 문제 / Discussion: Practical Engineering Problems
+
+추상적인 파이프라인 설계도에서 실제 프로덕션 환경으로 옮겨 가면, 인프라 신뢰성과 사람의 행동, 그리고 변화하는 비즈니스 맥락에 걸쳐 운영 현실이 따라옵니다.
+> Moving from an abstract pipeline blueprint to a real production environment introduces operational realities across infrastructure reliability, human behavior, and shifting business context.
+
+### 인프라 단일 장애점의 위험 줄이기 / Derisking from Infrastructure Single Points of Failure
+
+테스트 플랫폼이 결함 없는 진실의 원천(source of truth)이라고 가정할 수는 없습니다. 하부 테스트 인프라 계층의 조용한 버그가 아무런 경고도 없이 L1 테스트 스위트를 빠뜨리기 시작해, 감시되지 않는 거짓 음성(false negative)의 맹점을 만들면서 이를 배웠습니다.  
+이 단일 장애점(single point of failure)을 없애기 위해, [servicelab](https://www.usenix.org/conference/osdi24/presentation/chow) 같은 여러 테스트 하네스(harness)와 내부·OSS 파이프라인에 걸친 다양한 연산 자원을 도입하는 포화 검증(saturated validation) 전략을 채택해 CI 신호의 견고함을 높였습니다.
+> We cannot assume a testing platform is a flawless source of truth. We learned this when a silent bug in an underlying test infrastructure layer began omitting L1 test suites without raising alerts, creating a blind spot of unmonitored false negatives.  
+> To eliminate this single point of failure, we adopted a saturated validation strategy by adopting various testing harnesses (such as [servicelab](https://www.usenix.org/conference/osdi24/presentation/chow)), diverse compute capacities across both internal and OSS pipelines to improve CI signal robustness.
+
+### 일상적인 운영 마찰 관리하기 / Managing Daily Operational Friction
+
+트렁크에 오류를 남겨 두면 그 뒤에 생기는 회귀가 가려지는 것을 피할 수 없습니다. 동시에 diff 작성자는 실패가 자기 코드 변경과 무관해 보이면 트렁크 오류를 그냥 넘기기 쉽습니다. 이렇게 오류의 생애주기가 겹치면 일상적인 분류 작업이 금방 마비될 수 있습니다.  
+트렁크를 정상(green) 상태로 유지하려면 팀의 꾸준한 규율과 들어오는 실패를 그날그날 빠르게 해결하는 노력이 필요합니다.
+> Leaving an error on the trunk inevitably masks subsequent regressions. At the same time, diff authors often ignore trunk errors if a failure appears unrelated to their specific code change. These overlapping error lifecycles can quickly paralyze daily triage.  
+> Maintaining a green trunk requires continuous team discipline and rapid daily resolution of incoming failures.
+
+### 핀 업데이트에서 컨텍스트 격차 헤쳐 나가기 / Navigating the Context Gap During Pin Updates
+
+핵심 컴파일러 팀으로서는 플릿(fleet) 전체의 모든 다운스트림 워크로드와 모델 아키텍처를 온전히 파악하고 있기란 불가능합니다. 이 컨텍스트 격차는 내부에도, 더 넓은 OSS 커뮤니티에도 존재합니다.
+> As a core compiler team, it is impossible to maintain a complete view of every downstream workload and model architecture across the fleet. This context gap exists both internally and in the broader OSS community.
+
+실현 가능한 유일한 완화책은 팀 사이에 동적이고 지속적인 컨텍스트 공유 루프를 두어, 컴파일러 최적화가 변화하는 플릿의 현실과 계속 맞물려 있게 하는 것입니다.
+> The only viable mitigation is a dynamic, continuous context-sharing loop between teams, ensuring that compiler optimizations remain aligned with changing fleet realities.
+
+## 결함 없는 CI: 이상과 현실 / Flawless CI: Ideals vs Realities
+
+엔지니어링의 이상은 완전히 자율적이고 노이즈가 없으며 즉각적인, 그리고 넓은 서브시스템 수준 지표에 완벽하게 대응되는 CI/CD 루프입니다. 프로덕션 현실은 더 복잡합니다. 굵은 단위의 지표만으로는 위험을 온전히 포착하지 못하며, 플릿 규모의 안정성에는 추상적인 서브시스템 수준 추적에 더해 국소적인 운영 규율이 필요합니다.
+> The engineering ideal is a fully autonomous, zero-noise, instantaneous CI/CD loop that maps perfectly to broad subsystem-level metrics. Production reality is more complicated. Coarse metrics do not fully capture risk, and fleet-scale stability requires localized operational discipline in addition to abstract subsystem-level tracking.
+
+완성도 높은 CI 시스템은 하루아침에 만들어지지 않습니다. 코드를 모으는 일뿐 아니라 팀을 모으는 일, 그리고 그렇게 맞춰진 문화를 오랫동안 지켜 내는 일이 필요합니다.
+> A high-craftsmanship CI system cannot be built in a day. It requires not only putting code together, but also putting teams together, and sustaining that cultural alignment over time.
+
+에이전트 기반 솔루션은 이제 일상 워크플로우에 깊이 통합되어 있지만, 무엇이 달라졌고 무엇이 달라지지 않았는지는 냉정하게 볼 필요가 있습니다. AI 에이전트는 지루한 엔지니어링 작업을 없애는 데 효과적입니다. 병합 충돌 해결, 인프라 문제 보고, 테스트 결과 요약, 오류 유형 분류, 그리고 나이틀리 테스트가 깨졌을 때 수정 방안을 담은 추적 이슈 자동 생성에 에이전트를 쓰고 있습니다.
+> Agentic solutions are now deeply integrated into our daily workflow, but it is important to stay clear-eyed about what has changed and what has not. AI agents are effective at eliminating tedious engineering work. We use them to resolve merge conflicts, report infrastructure issues, summarize test results, group error types, and auto-file tracking issues with proposed fixes when nightly tests break.
+
+하지만 컴파일러와 하드웨어의 근본적인 동작 원리(physics)는 바뀌지 않습니다. 실제로는 AI의 환각(hallucination)과 사람의 실수 양쪽 모두를 경계하면서, 에이전트가 내는 속도가 언제나 결정론적인 안전 장치(safety rail)로 보호받도록 해야 합니다.
+> However, the underlying physics of the compiler and hardware remain unchanged. In practice, we must remain cautious about both AI hallucinations and human error, ensuring that agentic velocity is always guarded by deterministic safety rails.
+
+### 감사의 말 / Acknowledgments
+
+OSS 테스트 자원을 제공하며 값진 도움을 준 Abhinav Singh(NVIDIA), Shucai Xiao(AMD), Andrey Talman(PyTorch Dev Infra)에게 감사드립니다.
+> We would like to extend our gratitude to Abhinav Singh (NVIDIA), Shucai Xiao (AMD), and Andrey Talman (PyTorch Dev Infra) for their invaluable support in providing OSS test capacity.
diff --git a/assets/blog/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities/hero.png b/assets/blog/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities/hero.png
new file mode 100644
index 000000000..43b9b27ae
Binary files /dev/null and b/assets/blog/2026-07-30-fbtriton-infra-upstream-ingestion-hierarchical-validation-ideals-vs-realities/hero.png differ