Aelion Twelve（A12）
슈퍼 매니지드 PTZ 기술 백서

요약요약

A12는 이기종 GPU 컴퓨팅 자원을 위한 스케줄링 및 서비스 플랫폼입니다. 클라우드 GPU 클러스터, 전문 IDC를 유휴 워크스테이션/에지 GPU와 결합합니다. 액세스, 검증, 측정 및 스케줄링을 통합하고, 작업 특성에 따라 고속으로 상호 연결된 중앙 집중식 클러스터에서 높은 통신 강도로 대규모 모델 훈련을 유지하고, 낮은 통신 강도 추론, 검색 향상(RAG), 효율적인 매개변수 미세 조정(LoRA/QLoRA) 및 일괄 처리 작업을 보다 비용 효과적인 분산 리소스에 할당하고, 모델 서비스(MaaS), 에이전트 애플리케이션(AaaS) 및 완전한 개발자 도구 체인을 제공합니다. 통합된 작업 인터페이스.

이 백서는 현재 검증되었거나 명확한 엔지니어링 경로가 있는 설계에 대해서만 설명하고 세 가지 작성 원칙을 준수합니다. 모든 성능 지표는 실제 측정 결론이 아닌 설계 목표입니다. 모든 안전 메커니즘은 경계와 실패 조건도 설명합니다. 사업주제 및 이력에 관한 모든 정보는 공개목록 형태로 제시되며, 공개 전 신뢰성의 근거로 사용되지 않습니다.

키워드: 이기종 컴퓨팅 파워 스케줄링; 신뢰할 수 있는 리소스 확인; 하이브리드 컴퓨팅 전원 공급 장치; 모델 서비스; 에이전트 신청

첫 번째제1장 산업배경과 문제점 정의

1.1 AI 컴퓨팅 전원 공급 장치의 구조적 현황

생성적 AI의 워크로드는 빠르게 다양화되고 있습니다. 기본 모델 사전 훈련 및 전체 매개변수 미세 조정에는 고주파 그라데이션 동기화가 필요하며 자연스럽게 NVLink/InfiniBand 수준 클러스터 상호 연결에 의존합니다. 추론, 임베딩, 순위 재지정, RAG 데이터 처리 및 LoRA/QLoRA 미세 조정과 같은 작업은 통신 강도가 1~10배 낮으며 단일 시스템 또는 소규모 클러스터의 폐쇄 루프에서 완료될 수 있습니다. 두 가지 유형의 로드는 인프라에 대한 요구 사항이 크게 다르지만 오랫동안 "동일한 공급 방법"으로 서비스를 제공해 왔습니다.

동시에 컴퓨팅 전원 공급 장치 측면은 3계층 구조를 제시합니다. 초대형 클라우드 플랫폼은 표준화되었지만 상대적으로 고가의 관리형 컴퓨팅 전원을 제공합니다. 전문 AI IDC 및 기업 소유 클러스터는 고속 상호 연결이 가능하지만 활용률이 변동됩니다. 전 세계에는 여전히 수천만 개의 소비자급 및 워크스테이션급 GPU가 있으며, 이는 신뢰할 수 있는 액세스 및 예약 메커니즘이 부족하여 유휴 상태입니다(규모는 정확한 통계가 아닌 공공 산업 표준을 기반으로 한 추정 참조입니다. 이 장의 업계 데이터는 구조적 판단을 설명하는 데 사용됩니다). 문제는 '컴퓨팅 파워가 부족하다'는 게 아니라, 다양한 물리적 조건에서의 컴퓨팅 파워가 적절한 작업 부하로 정리되지 않는다는 점이다.

1.2 혼합 공급의 조직 효율성 문제

위의 세 가지 공급 계층을 통합하려면 다음 네 가지 엔지니어링 문제를 해결해야 합니다.

• 이기종 적응: NVIDIA, AMD 및 기타 가속기 카드의 드라이버, 런타임 및 운영자 라이브러리의 차이로 인해 비용 없이 상위 계층 작업을 마이그레이션하기가 어렵습니다. "완전히 무의미한 통일성"을 주장하는 솔루션은 실제 적응 작업을 피합니다.
• 신뢰할 수 있는 리소스: 개방형 액세스 환경에서는 리소스 위장, 비디오 메모리 초과 예약 및 반복 선언 가능성이 있습니다. 노드 자체 보고 정보에만 의존하는 것만으로는 예약에 필요한 신뢰를 구축하는 데 충분하지 않습니다.
• SLA와 탄력성 사이의 모순: 유휴 엣지 GPU의 온라인 속도는 불안정하며, 기업 수준의 온라인 서비스를 직접 전달하면 가용성 붕괴로 이어질 수 있습니다. 중앙 집중식 리소스를 완전히 사용하면 유휴 컴퓨팅 성능의 사용이 포기됩니다.
• 경제적 지속 가능성: 토큰 배출 보조금 공급에만 의존하는 모델은 실제 수요가 부족할 때 "배출권 판매 압력-인센티브 실패"의 사이클에 빠지게 됩니다.

1.3 A12에 대한 솔루션(개요)

위의 문제에 대한 A12의 해법은 네 가지로 요약할 수 있으며, 그 타당성 경계는 해당 장에서 하나씩 설명한다.

• 통신 강도에 따라 구분되는 스케줄링 아키텍처: 통신량이 많은 작업은 중앙 클러스터에 고정되고, 통신량이 적은 작업은 분산 리소스로 이동됩니다(3장, 5장).
• 계층화된 리소스 신뢰성 검증 시스템: "진술 검증 + 실제 측정 문제 + 런타임 원격 측정 + 작업 수준 검증 + 기록 평판"의 조합으로 신뢰를 구축하고 단일 "절대 위조 방지" 메커니즘에 의존하지 않습니다(4장).
• 이중 트랙 공급 모델: 탄력적 최선형 모드는 중단 가능한 작업을 전달하고 전용 보증 모드는 SLA 서비스를 전달하며 두 가지가 물리적으로 격리되어 있습니다(4장 및 5장).
• 실제 서비스 수익을 기반으로 한 경제 모델: 플랫폼 수익이 우선이고, 토큰은 인센티브 및 정산 증서 역할을 하며, 환매 및 파기는 수익과 연결되어 있으며 상한이 엄격합니다(8장).

두번째제2장 프로젝트 포지셔닝 및 거버넌스 투명성

2.1 플랫폼 포지셔닝 선언문

A12는 "중앙 집중식 운영 + 분산 실행"이라는 아키텍처 포지셔닝을 채택합니다. 플랫폼은 운영 주체의 리소스 액세스 확인, 작업 일정 관리, 청구 및 결제, 분쟁 처리 및 보안 위험 제어를 중앙에서 담당합니다. 컴퓨팅 자원 자체는 전 세계(개인, 기관, IDC 및 엣지 노드)에 분산되어 있고, 자원이 있는 위치에서 분산 방식으로 작업 실행이 완료되며, 각 노드의 실시간 상태를 기반으로 일정 결정이 내려집니다. 플랫폼이 통합 인터페이스와 신뢰할 수 있는 검증을 통해 분산된 이기종 컴퓨팅 성능을 사용하는 데 드는 조직 비용을 줄여주기 때문에 사용자는 A12를 선택합니다.

플랫폼은 다음을 약속합니다. 모든 일정 및 청구 규칙은 공개적으로 사용 가능하며 확인할 수 있습니다. 테넌트가 작업 계량 기록을 내보내고 감사할 수 있습니다. 향후 온체인 인증 및 결제가 도입되면 투명성을 강화하기 위한 선택적 프로토콜 계층으로만 사용되며(§8.6 참조) 플랫폼의 운영 책임 기관은 변경되지 않습니다.

2.2 프로젝트 주체 및 팀 공개(필수 공개 목록)

참고: 책임 직위는 운영 주체 내의 기능적 부서이며, 해당 기능을 수행하도록 운영 주체가 지정한 직원, 외부 컨설턴트 또는 기관이 맡습니다. 해당 인력이 작업장에 도착하기 전에 운영 주체의 책임자가 인력을 충원합니다. 구체적인 책임 주체는 발표 페이지에 나열되어 있습니다(컨설턴트 및 아웃소싱 구성은 §2.5 인적 자원 보장, D-20 참조). 약속 날짜는 운영 주체의 담당자 승인 후 발효됩니다. 리듬 구경: 약속된 날짜는 평가 노드이며, 기한이 지난 경우 다음과 같은 기한이 지난 처리 규칙이 실행됩니다. 부록 C의 주간 업데이트는 진행 상황을 기록하지만 새로운 평가 시점을 구성하지 않는 프로세스 공개입니다. 둘 다 약속된 날짜를 기준으로 합니다. ② ③ (공식 이메일 및 사무실 주소, 법적 연락 채널)은 비용이 전혀 들지 않는 항목입니다. 제3자의 협력에 의존하지 않으며, 승인이나 외부 검증이 필요하지 않습니다. 따라서 이행 날짜는 전환 공지 페이지의 첫 번째 버전과 같은 날인 본 버전 출시 후 영업일 기준 5일 이내(2026-09-21)로 설정됩니다. ①⑦ 팀원은 플랫폼 백엔드에 협력해야 하며 약속 날짜는 2026-10-15입니다. ④⑤⑥⑧ 외부기관의 협조나 규제절차가 필요하며, 약속일자는 위와 같습니다. 엄밀한 관찰 포인트: 첫 번째는 2026-09-21입니다. ( ② ③ 비용이 전혀 들지 않는 항목과 발표 페이지의 첫 번째 페이지, 실행 능력을 테스트합니다.) 두 번째는 2026-10-31(D-04 투자자 증거 및 D-08 주요 도메인 이름, 주제 검증 가능성의 실질적인 변경 지점)입니다. 세 번째는 2026-11-30(D-05 특허 번호 및 D-06 코드 저장소, 기술 자산 진위)입니다. 연체 처리: 약속 날짜까지 문제가 종결되지 않은 경우 운영 주체는 연체 이유, 현재 진행 상황 및 수정된 약속 날짜를 해당 날짜로부터 영업일 기준 5일 이내에 공시 페이지에 설명하고 동시에 이 표와 부록 C를 업데이트해야 합니다. 동일한 사항이 2회 연속으로 연체된 경우에는 별도의 정정서를 공고해야 합니다. 수정일은 원래 날짜로부터 30일 이내이어야 합니다(외부 기관의 협조가 필요한 사항을 제외하고, 기관 피드백 주기도 명시되어야 함).

2.3 명명 이력 및 기술 영역 레이아웃

명명 내역: Aelion Twelve는 프로젝트 및 해당 운영 주체의 이름입니다. Axiur Twelve는 2021년에 이 프로젝트에 투자하는 동시에 특별 개발팀을 구성할 전략적 투자자입니다. Aelion Twelve를 통해 투자자와 투자 프로젝트 간의 관계를 형성합니다. 두 이름의 'Twelve'는 투자가 완료되었을 때 사용한 프로젝트 코드에서 따온 것으로, 이는 투자 이력에서 남겨진 자연스러운 네이밍 흔적이다. 투자계약서, 자본출자증명서 등 서면문서도 대상정보 공개 범위에 포함된다(§2.2 참조).

기술 영역 레이아웃: 핵심 컴퓨팅 파워 스케줄링 기술의 특허 레이아웃은 R&D 팀의 구성과 일치합니다. 분산 시스템 담당자(Tunde Akinwale)와 GPU 인프라 담당자(Amara Okoye)는 나이지리아에 있으며 관련 연구 개발 작업은 나이지리아에서 완료됩니다. 따라서 발명이 완료된 곳에 먼저 특허출원을 제출한 뒤, 중국(출원 승인 완료), 미국(2026년 말 예상) 등 목표 시장 중요도 순으로 추진한다. 이는 다국적 R&D 팀의 전통적인 로컬 레이아웃 전략입니다. 구체적인 진행 상황은 특허 번호/출원 번호 발표에 따라 달라질 수 있습니다(§2.2 참조).

명명 및 기호 가용성: 토큰 기호 A12와 프로젝트 이름 Aelion Twelve의 상표 및 주류 트렌드 플랫폼에 대한 고유성 검색이 출시 전에 완료되었습니다. 검색 범위 및 결과[보충 및 공개 전 공개 · D-09]는 기존 프로젝트/상표와 충돌이 없음을 보장합니다.

2.4 규정 준수 약속

플랫폼은 다음 사항을 준수합니다: 사용자 식별(KYC) 및 제재 목록 심사; 컴퓨팅 성능 테넌트 사용 검토 및 콘텐츠 준수 규칙(§4.7 참조) 데이터 보호 및 국경 간 전송 규정 준수 평가 디지털 자산과 관련된 관할권에서는 토큰 관련 활동은 필요한 허가를 얻은 후에만 수행됩니다. 운영 법인 등록이 완료되었습니다(캐나다). MSB 및 SEC 관련 라이센스 신청이 진행 중입니다. 라이센스를 취득하기 전에는 위 라이센스와 관련된 사업을 수행할 수 없습니다.

라이선스 진행 관찰 지점: "라이센스를 받기 전에 개발 없음"을 외부에서 관찰할 수 있도록 운영 주체는 MSB 등록의 적용 단계, SEC 관련 라이선스 및 기타 사항, 승인/수신 번호 공개 방법, 예상 완료 기간 및 현재 상태를 항목별로 구분하여 공개 발표 페이지에 라이선스 상태 테이블을 유지합니다. 첫 번째 라이선스 상태 표의 공개 날짜는 전환 공개 발표 페이지(§2.2 참조)의 시작 날짜 이후이어야 하며 이후 매월 업데이트됩니다. 업데이트된 책임 직위는 운영주체의 법무 및 준법담당자입니다. (외부 로펌과 관련된 사항은 표에 책임법률사무소도 표기되어 있습니다.) 라이선스와 관련된 모든 사업 개시 발표에는 라이선스 상태에 해당하는 쿼리 링크가 함께 제공되어야 합니다. 링크 실패 시 대체 인증 방법으로 "규제기관명 + 접수/접수번호 + 규제기관 공식 문의포털"을 이용하시면 영업일 기준 5일 이내에 링크를 복구 또는 교체해 드립니다.

2.5 자금 및 자원 투명성 약정

공개 테스트 인센티브, 제3자 회계 검증, 계약 보안 감사, 컴퓨팅 파워 조달 및 노드 공유, 팀 보상 등은 모두 운영 주체의 자체 자금에 의존합니다. "자기자금" 명세서를 검증할 수 있도록 다음과 같은 조치를 취합니다.

위 표는 "약정 지출 및 자원 보장"의 유일한 범위입니다(동일 섹션에 두 개의 숫자 세트를 피하기 위해 이 버전에서는 원래 병렬 목록 범위가 삭제되었습니다). 각 약정 지출은 명확한 자금 출처, 상한 범위 및 추적 번호(D-10 ~ D-20)에 해당합니다. 독자들은 부록 C에서 항목별로 번호에 따라 확인할 수 있다. 이 표는 "계정 - 상한 - 출처"의 검증 가능한 프레임워크를 설정하고 평가 가능한 프레임워크를 설정했습니다. 해당 값은 추적 테이블(부록 C)을 통해 발표된 후 평가 가능해집니다. 운영 주체의 자체 자금 규모 범위(D-17)와 향후 12개월 동안의 자금 격차(D-19)가 발표되기 전에 이 기사는 지불 능력을 외부에서 평가할 수 있다고 주장하지 않습니다. 폐쇄 루프 우선순위: D-19(향후 12개월 동안 자금 격차 및 보충 방법)가 이 표에서 가장 높은 우선순위 항목으로 나열됩니다. 자금의 절대 규모가 상업적 기밀로 인해 공개하기에 적합하지 않은 경우, D-17은 범위 구경 또는 "고객에게 별도로 제공되어 검증 가능한 기록으로 보관"된 확인서의 형태로 충족될 수 있습니다.

제삼3장 시스템 아키텍처 개요

3.1 디자인 원칙

시스템 설계는 네 가지 원칙을 따르며, 각 원칙은 수용 가능한 엔지니어링 영향에 해당합니다.

• 물리적 토폴로지 친화성: 작업의 스케줄링 대상은 "분산 정도"가 아닌 통신 컴퓨팅 특성에 따라 결정됩니다. 훈련 작업은 고대역폭 클러스터에 유지되는 반면 추론 작업은 에지로 싱크됩니다.
• 이기종 하드웨어 추상화: 통합된 것은 기본 실행 환경이 아니라 작업 제출 인터페이스와 측정 수준입니다. 제조업체 간의 차이점은 숨겨지기보다는 명확한 적응 매트릭스를 통해 공개됩니다.
• 계층화된 검증 가능: 신뢰는 여러 계층의 메커니즘(진술, 실제 측정, 원격 측정, 임무 확인, 평판)의 중첩에서 비롯되며 우회되는 단일 계층은 시스템 위험을 구성하지 않습니다.
• 수직적 가치 사슬: CaaS(컴퓨팅 파워) → MaaS(모델 서비스) → AaaS(에이전트 애플리케이션)는 계층별로 가치를 추가합니다. 플랫폼 수익은 가치 사슬의 상위로 올라갈수록 단가와 고정성이 증가합니다.

3.2 4계층 아키텍처

레이어는 표준 인터페이스와 분리됩니다. 컨트롤 플레인(스케줄링, 미터링, 정산)은 데이터 플레인(모델 실행, 데이터 전송)과 분리됩니다. 작업이 위치한 클러스터 내에서 데이터 플레인 전송이 우선시되며 컨트롤 플레인은 대규모 텐서 데이터 전달을 담당하지 않습니다.

그림 3-1 A12 4계층 시스템 아키텍처: 수직 가치 사슬은 계층별로 가치를 추가하고 제어 평면과 데이터 평면이 분리됩니다.

3.3 생태학적 역할

3.4 디자인 참조 시스템(Ethereum 및 Filecoin에서 엔지니어링 영감을 얻음)

A12의 메커니즘 설계는 두 개의 대규모 검증된 분산 시스템 백서의 엔지니어링 패러다임을 크게 활용하지만 합의 메커니즘을 복사하지는 않습니다. Ethereum의 검증 대상은 원장 상태이고 Filecoin의 검증 대상은 저장 정확성이며 A12의 검증 대상은 컴퓨팅 프로세스 및 성능입니다. 검증 대상의 차이가 메커니즘 형태의 차이를 결정합니다.

매핑 관계는 다음과 같습니다.

네번째4장 레이어 1: 리소스 액세스 및 신뢰성 검증

4.1 설계 원칙 및 경계(중요 사항)

개방형 환경에서 리소스 검증을 위한 "절대적인 위조 방지"는 없습니다. A12의 설계 목표는 부정 행위로 인한 이익보다 부정 행위에 따른 총 비용(탐지 확률 × 손실)을 크게 높이고, 비정상적인 노드를 지속적으로 식별하고 다운그레이드할 수 있도록 하는 것입니다. 이를 위해 이 플랫폼은 "3가지 금지 사항"을 명확하게 명시합니다.

• '실리콘 물리적 지문'이 장치 ID로 사용되지 않으며 지문을 기반으로 영구적으로 차단되지 않습니다(물리적 특성은 온도, 전압, 노화에 따라 표류하며 안정적으로 재현할 수 없으며 영구적인 처벌을 지원할 수 없음).
• 물리적 세계에서 아날로그 수량을 인증하기 위해 영지식 증명을 사용하지 마십시오(증명 시스템은 "특정 계산이 정확함"을 증명할 수 있지만 "특정 물리적 이벤트가 발생했음"을 증명할 수는 없습니다).
• 확인을 위해 테넌트 모델 가중치 또는 데이터에 대한 액세스가 필요하지 않습니다(테넌트 개인정보 보호를 위해).

4.2 5단계 신뢰성 검증 시스템

그림 4-1 A12 5계층 신뢰 검증 시스템: 계층화 및 중첩, 단일 계층을 우회하는 것은 시스템적 위험을 구성하지 않습니다.

5개 계층 검증 시스템의 L2 및 L3 계층은 아래 설명과 같이 정량화 가능한 통계적 판단 방법을 채택합니다.

L2 능력 측정을 위한 결정 모델. 플랫폼 검증 클러스터는 무작위 벤치마크 챌린지를 생성합니다. 무작위 행렬 A ∈ ℝ^(m×k), B ∈ ℝ^(k×n)(요소는 균일 분포를 따르고 시드는 VRF 비콘에서 파생됨), 노드는 지정된 정확도(FP16/BF16)로 대상 GPU에서 GEMM 계산 C = A × B를 수행하고 결과 요약(SHA-256(C))과 실제 시간 T를 반환합니다. 통계 세트는 다음을 결정하는 데 사용됩니다.

• 정확성: 참조 구현을 통해 샘플링 요약을 검토하기 위해 클러스터를 확인하고 상대적인 Frobenius 표준 오류 ``C − C_ref``_F / ``C_ref``_F ≤ ε를 요구합니다(ε은 정확도 수준에 따라 설정되며 FP16은 일반적으로 10⁻² 정도이며 부동 소수점 비연관성 및 다양한 연산자 구현으로 인한 법적 편차를 포괄합니다).
• 성능 합리성: T_hat = 2·m·k·n / eta_peak는 측정된 처리량 기준선 eta_peak(m, k, n은 챌린지 GEMM의 매트릭스 크기)를 기반으로 파생된 예상 시간 소모이며, (1−δ)·T_hat는 합리적인 하한입니다. 측정된 시간 소모가 이 하한(T<(1−δ)·T_hat)보다 작으면 "컴퓨팅 성능의 허위 보고" 또는 "사전 계산 캐시" 공격으로 판단됩니다. 상당히 느린 작업은 인증 확인 통과에 영향을 주지 않으며 SLA 및 평판 메커니즘에 의해 처리됩니다(§4.5 및 §5.3 참조).
• 베이스라인 교정 및 오염 방지: θ_peak는 공식 참조 하드웨어 장비에 대한 플랫폼 검증 클러스터에 의해 정기적으로 측정 및 교정되며 베이스라인 테이블은 공개되고 버전이 지정됩니다. 연결되지 않은 노드의 기록 측정값을 직접 집계하는 것은 저품질 샘플이 기준선을 낮추어 탐지 실패를 일으키거나 고품질 샘플이 기준선을 높여 실수로 실제 노드를 손상시키는 것을 방지하기 위해 기준선 소스로 사용되지 않습니다.
• 고성능 노드 오판 방지: 실제 측정이 기준보다 나은 것이 법적 상황입니다(성능 업그레이드, §4.6 참조). 허위 경보 프로세스는 실제 측정값이 물리적 하한값보다 낮은 경우에만 트리거됩니다. 판정을 받은 운용자는 원격 재시험 및 수동 검토를 신청할 수 있습니다(실측 측정 기록 및 운용 환경 설명 제출). 검토 기간 동안 해당 소득은 보류 상태로 동결됩니다. 오확인은 완전히 해제되어 부정적인 평판 기록에 포함되지 않습니다.

다양한 매트릭스 크기(1K² ~ 16K³)와 정밀 조합이 무작위로 선택되므로 노드가 단일 규모로만 목표 최적화를 수행하는 것이 불가능합니다.

L3 런타임 원격 측정에 대한 이상 탐지. EWMA(지수 가중 이동 평균)는 사용률, 메모리 사용량, 온도 및 전력 소비와 같은 타이밍 지표의 기준을 유지하는 데 사용됩니다.

s_t = α·x_t + (1 − α)·s_{t−1}

여기서 α는 평활 계수(일반적으로 0.05–0.2)입니다. 순간 값이 기준선에서 3σ 이상 벗어나고(σ는 과거 잔차의 EWMA 분산으로 추정됨) K 샘플링 기간 동안 계속되면 원격 측정 비정상 이벤트로 표시됩니다. 비정상적인 이벤트가 누적되어 운영자의 평판(§4.5 참조)에 포함되고 해당 작업의 암호화 밀도 샘플링 검사가 실행됩니다. 이 방법의 경계도 명확합니다. 원격 측정에서 발견한 것은 "통계적 불일치"이며 변조 수단에 대한 철저한 증거를 구성하지 않습니다. 이것이 단일 결정 지점 대신 5개의 중첩 레이어가 필요한 이유입니다.

프로토콜의 공식화에 도전합니다. L2 챌린지의 생성 및 공개는 Commit-Reveal 패러다임을 따릅니다(이 패러다임은 Ethereum의 난수 비컨 및 Filecoin의 창 증명과 동일한 출처를 가짐). 검증 클러스터는 먼저 각 라운드에서 챌린지 약속을 발표한 다음 시드를 공개합니다. 노드는 이후에 클러스터의 "선택적 질문 없음"을 독립적으로 감사하고 확인할 수 있습니다.

그 중 (y, π)는 VRF 출력 및 증명이고, sk_V/vk_V는 검증 클러스터 서명 키 쌍이며, 모든 제3자는 vk_V를 사용하여 오프라인에서 시드 적법성을 검증할 수 있습니다. 약정 값에는 seed_q 및 공개 매개변수(ε, δ)만 포함되어야 합니다. A_q 및 B_q는 seed_q에서 파생됩니다. 약속이 포함되면 약속 단계에서 매트릭스 콘텐츠가 잠기고 "먼저 커밋하고 나중에 공개"하는 반선택적 질문 생성 디자인은 효과가 없습니다. 챌린지 검증의 참조 결정 프로세스는 다음과 같습니다(최종 구현이 아닌 도식적 의사 코드).

4.3 검증인 네트워크(명확한 권리, 책임 및 비용)

• 검증 클러스터: 플랫폼에서 구축하고 운영하는 핵심 검증 클러스터는 모든 샘플링 재실행 및 벤치마크 과제의 생성, 발행 및 결정을 담당합니다. 그 비용은 플랫폼 서비스 요금에 포함되어 있으며 임차인에게 투명하게 공개됩니다.
• 자발적 검증 노드: 평판이 높은 노드는 검증 네트워크 가입을 신청할 수 있으며 보증금(금액은 수행할 검증 작업량에 연결됨)을 약속해야 하며 완료된 효과적인 검증을 기준으로 지급됩니다. 검증 오류가 있거나 검증된 노드와 공모하는 경우, 보증금은 몰수되며 검증 자격은 영구적으로 취소됩니다.
• 무작위 비콘: 검증 가능한 무작위 함수(VRF)를 사용하여 검증 클러스터에 의해 챌린지 시드가 생성되고 시드 약속이 공개됩니다. 노드는 챌린지의 내용을 예측할 수 없으며, 검증 클러스터는 해당 질문이 선택적으로 선택되지 않았음을 나중에 증명할 수 있습니다.

4.4 이중 레일 노드 액세스

탄력적 노드는 SLA 서비스를 제공하지 않습니다. 전용 리소스 풀의 중복 배포를 통해 엔터프라이즈 수준의 가용성이 보장됩니다. 이는 "키보드와 마우스가 활성화되자마자 오프라인으로 전환"과 "온라인 서비스" 사이의 모순을 구조적으로 제거합니다.

4.5 마녀 방지 및 초과 예약 방지 메커니즘

• 운영자 계정 시스템: 모든 평판, 합의 및 처벌은 운영자(자연인 또는 법인)에 의해 집계됩니다. 동일한 사업자 명의의 여러 기기의 성능을 합산하여 계산합니다. 단일 장치 불이행은 운영자의 전반적인 평판과 정산 주기에 영향을 미치므로 "각각 악한 일을 하는 다수의 새로운 ID를 등록"하여 손실을 분리하는 것이 불가능합니다.
• 글로벌 리소스 임대와 교차 ID 메모리는 상호 배타적입니다. 각 GPU는 "장치 일련 번호 + 운영자 계정"을 키로 사용하여 플랫폼 원장에 등록됩니다. 리소스가 작업에 의해 잠겨 있는 동안에는 동일한 키로 두 번째 판매 가능한 리소스를 생성할 수 없습니다. 더 중요한 것은 장치 일련 번호가 원장 수준에서 전역적으로 고유하다는 것입니다. 동일한 일련 번호는 동시에 하나의 운영자 계정에만 바인딩될 수 있으며 선언하는 데 어떤 계정을 사용하든 관계없이 최대 하나의 유효한 임대가 있습니다. 일련번호의 계정 바인딩 변경 사항은 양 당사자가 모두 검토해야 하며 30일의 철회 가능 기간이 설정됩니다. 이는 발견할 후속 감지에 의존하는 대신 "하나의 물리적 카드가 세 개의 ID로 교환되고 각각은 모든 메모리를 한 번 선언"하여 원장 수준에서 상호 배타적이게 만듭니다. 동일한 물리적 장치를 반복적으로 선언하면(가상화 분할 후 다중 ID 선언 포함) 계정 수준 검토가 트리거됩니다. L1 문 확인은 하드웨어 조합(GPU 모델, 총 비디오 메모리, PCIe/NUMA 토폴로지, VBIOS 버전 및 일련 번호)을 수집하고 계정 간 중복 확인에도 사용됩니다. 중복 확인 및 검토 신호에만 사용되며 장치 ID 인증 또는 영구 블랙리스트 작성을 위한 기초로는 사용되지 않습니다(§4.1 "3가지 금지 사항"과 일치). 이러한 상호 배제를 외부에서 관찰할 수 있도록 하기 위해 교차 ID 중복 제거 통계(신고된 장치 수/중복 제거 후 장치 수/차이)가 각 단계에서 승인 보고서의 "노드 규모" 필드에 포함되어 공개됩니다(§9.2.1 참조).
• 토폴로지 클러스터링 의심 감지: 선언된 리소스의 PCIe 토폴로지, NUMA 구조, 드라이버 및 펌웨어 조합에 대한 클러스터 분석을 수행하고 "동일한 물리적 시스템으로 의심되는 여러 ID"를 시간 제한적으로 관찰하고 수동 검토를 시작합니다. 토폴로지 기능은 클러스터 감지 및 예약 참조에만 사용되며 장치 ID 인증에는 사용되지 않습니다. 오판 방지 및 항소 채널: 규정을 준수하는 다중 기계 운영자(인터넷 카페, 학교 컴퓨터실, 소규모 스튜디오, 대행사 IDC)는 당연히 동일한 하드웨어 및 펌웨어 조합을 가지며 장비 목록, 구매 바우처 및 기타 자료를 제출하여 운영자 신원 검토를 신청할 수 있습니다(처리 기한은 영업일 기준 7일이며 결과가 발표됩니다). 평판 모델은 "판단 부정 행위"(벌칙 및 몰수)와 "클러스터 의심"(스트림 관찰만 가능, 페널티 없음 및 영구적인 가중치 감소 없음, 검토가 통과되면 가중치가 복원됨)을 구별합니다.
• 새로운 노드 소득 성장 곡선: 처음 30일 동안 새로 등록된 운영자에 대해 소득 한도와 점진적인 해제가 구현되므로 새 계정의 일괄 등록으로 인한 일회성 부정 행위 예상 소득은 0에 가깝습니다. 무결성 기록이 누적됨에 따라 상한선이 점차 증가합니다.
• 수익 지연 릴리스 풀: 노드 수익은 세 가지 상태로 흐릅니다: 획득 → 보류 중 → 출시됨. 대기 관찰 기간(작업 가치에 따라 1~72시간으로 구분) 동안 무작위 검사 및 분쟁이 처리됩니다. 계약 위반이 적발되면 해당 보류 소득은 몰수되고 피해를 입은 임차인에게 보상하는 데 사용됩니다. 고부가가치 SLA 사업에 대해서는 별도의 보증금이 설정되어 있습니다. §4.4를 참조하세요.

평판의 정량적 모델(설계 목표). 운영자 평판 값 R ∈ [0, 100]은 "지수 망각 + 작업 피드백"에 따라 업데이트됩니다.

R_{t+1} = λ·R_t + (1 − λ)·r_task

그 중 r_task ∈ [0, 100]은 단일 작업 평가(종합 검증 통과 상태, 성능 편차, SLA 달성)이고, λ ∈(0, 1)은 망각 요소입니다. λ가 1에 가까울수록 기록 가중치가 클수록 간헐적인 지터가 완화되지만 복구 속도가 느려집니다. λ가 0에 가까울수록 새 점수의 영향이 커지고 최근 변경 사항에 더 민감하며 복구 속도가 빨라집니다. 디자인은 "안정성"과 "응답성" 사이의 균형을 유지합니다. 장기적으로 양호한 기록은 가끔씩 발생하는 불안감을 완화하는 반면 지속적인 성능 저하로 인해 R은 단조롭게 최근 성능 수준으로 수렴됩니다. 불이행에 대한 추가 페널티 승수: 각각의 확인된 불이행 이벤트로 인해 R에 감쇠 계수 κ(값 0.8, 위험 제어 규칙에 의해 조정될 수 있음)가 직접 곱해지고 운영자 수준 검토 프로세스에 기록됩니다. 평판 R(예: R < 60은 SLA 리소스 풀에 들어갈 수 없음)의 일정 가중치 및 허용 매핑 관계를 설계 목표로 삼고 0단계 내부 테스트에서 보정 후 발표할 예정입니다.

페널티 기능은 Filecoin의 담보/슬래싱 모델을 사용하지만 페널티 한도는 "마이너스 자산" 계정을 피하기 위해 운영자의 보관 예금을 엄격히 초과하지 않습니다.

그 중 V_disputed는 분쟁 작업의 가치, m_violation은 책임 결정 배수(초기값 1.0, 반복 위반 시 누진), D_escrow(o)는 운영자의 보관 예치금입니다. 위약금 금액은 예치금의 하드 상한선이며 초과 금액은 플랫폼 오용 보상 기금에서 부담하며 운영자는 무제한 책임을 지지 않습니다.

(수익 보관 및 몰수에 대한 계약 수준 의견 §8.6 프로토콜 계층 - 이 기능은 4단계 제공 가능하며 현재 제공되는 것으로 잘못 해석되는 것을 방지하기 위해 프로토콜 계층 장에서 통일된 방식으로 제공됩니다.)

4.6 동적 성능 등급(CU)

노드 종합 능력 점수는 다음과 같이 정의됩니다.

그 중 P는 계산 벤치마크 점수, B는 메모리 대역폭 점수, M은 메모리 용량 점수, N은 네트워크 품질 점수, R은 기록 신뢰성 점수입니다. w_P, w_B, w_M, w_N, w_R 가중치는 작업 유형에 따라 조정됩니다(훈련 작업은 P/N 가중치를 증가시키고 온라인 API는 N/R 가중치를 증가시킵니다). w_P+w_B+w_M+w_N+w_R=1을 충족합니다. 각 하위 항목은 제조업체의 공칭 값이 아닌 L2 실제 측정 및 L3 원격 측정에서 나옵니다.

이기종 하드웨어 간의 비교 가능성을 보장하기 위해 각 하위 항목은 먼저 최소-최대를 [0, 1]로 정규화합니다.

그 중 X_min / X_max는 이상치 스트레칭을 억제하기 위해 동일한 세대의 하드웨어 기어의 측정된 분포 분위수(P5/P95)에서 가져옵니다. 정규화된 점수는 위 공식에 의해 가중 및 합산되어 CU(i) ∈ [0, 100]을 얻은 후 보정된 컷오프 지점에 따라 Tier-S/A/B/C로 나뉩니다. 컷오프 지점 선택은 "계층 내 최소 CU 분산 및 계층 간 작업 통과율의 최대 차이"라는 원칙을 따르며 실제 작업 통과율(하드웨어)로 0단계 내부 테스트에서 보정 후 공개됩니다. 사양표는 교정 전 임시 구분의 기준으로 사용됩니다.

노드는 측정된 CU에 따라 Tier-S/A/B/C 4단계 계층으로 나뉩니다. 수행할 수 있는 계층과 작업 범위는 §5.4의 일정 제약 표에 나와 있습니다. 모든 계층의 작업 테이블은 하드웨어 사양과 검증 가능한 일관성을 유지합니다.

4.7 노드 소유자(공급자) 보호 및 콘텐츠 준수

노드 소유자에 대한 플랫폼의 의무는 테넌트의 의무와 동일합니다.

• 최소 권한 실행: 테넌트 작업은 컨테이너 격리 환경(cgroups v2 + Seccomp + 읽기 전용 루트 파일 시스템)에서 실행되고 노드 데몬은 권한이 없는 사용자로 실행됩니다. 격리는 공격 표면을 크게 줄일 수 있지만 위험을 완전히 제거할 수는 없습니다. 플랫폼은 이에 대해 보험에 가입되어 있으며 남용 보상 기금을 마련합니다.
• 사용 검토: 임차인 등록은 KYC를 완료해야 합니다. 작업 이미지는 화이트리스트 창고를 통해 배포되며 노드는 외부 이미지를 가져오는 것이 금지됩니다. 암호화폐 채굴, 포트 스캐닝, 가비지 트래픽과 같은 용도는 금수 조치 목록에 포함되며 원격 측정을 통해 감지됩니다.
• 어뷰징 보상: 플랫폼 리스크 관리 부주의로 인해 노드 소유자가 손실을 입은 경우 약정에 따라 어뷰징 보상 기금에서 보상이 이루어집니다.
• 무료 종료: 노드는 언제든지 종료할 수 있으며, 종료는 해제됨 상태에 들어간 혜택의 철회에 영향을 미치지 않습니다.
• 기밀 컴퓨팅에 대한 전망(연구 프로젝트): "노드 메모리의 테넌트 코드 및 가중치의 개인정보 보호"에 초점을 맞춰 TEE(신뢰할 수 있는 실행 환경), 즉 하드웨어 수준에서 비디오 메모리와 컴퓨팅 프로세스를 암호화할 수 있는 CC(기밀 컴퓨팅) 모드를 지원하는 데이터 센터 GPU를 기반으로 기밀 컴퓨팅 경로를 추적하여 노드 소유자 자체가 테넌트 데이터를 읽을 수 없도록 합니다. 이 기능은 특정 하드웨어 세대 및 제조업체 지원에 의존하며 연구 범위에 포함됩니다(§9.3 참조). 생태계에서 적격 장비의 규모가 형성될 때까지는 약속 항목이 아닙니다. 그 전에는 컨테이너 격리 + 사용 검토 + 보상 기금이 여전히 주요 보호 조합이 될 것입니다.

제오5장 계층 2: 스케줄링 및 리소스 풀링

5.1 HAL(하드웨어 적응 계층) - 정직한 이기종 전략

A12는 근본적인 차이점을 제거한다고 주장하기보다는 하드웨어 추상화 계층을 통해 작업 제출 인터페이스를 통합합니다. 명확하게 언급됨:

• 통합 인터페이스: 테넌트는 특정 GPU 모델을 선택하지 않고 통합 작업 설명(모델, 데이터, 컴퓨팅 전력 요구 사항, 대기 시간 및 예산 제약)을 제출합니다.
• 백엔드 이질성: 기본 실행은 각 제조업체의 드라이버, 컴파일 도구 체인 및 연산자 구현에 따라 다릅니다. 로드맵에서는 NVIDIA CUDA 스택을 프로덕션에 사용할 수 있을 것이라고 약속합니다. AMD ROCm 스택은 실험적인 지원과 함께 제공됩니다. 국산 칩 적응은 연구 항목으로 등재될 예정이며, 실제 프로젝트 진행 상황에 따라 별도로 공지될 예정이다.
• 플랫폼은 제3자 상표와 유사한 제품 이름을 사용하지 않습니다.

5.2 이중 경로 스케줄링

스케줄러는 작업의 통신-계산 비율 α_comm을 기반으로 경로를 선택합니다.

• α_comm ≥ 1(통신 제한): 중앙 집중식 컴퓨팅 센터(클라우드 플랫폼 GPU 클러스터, 전문 AI IDC, HPC)로 파견 - A12는 표준 어댑터를 통해 이러한 리소스에 액세스하고 통합 오케스트레이션을 제공하여 임차인의 자체 가격 비교 및 ​​접합을 대체합니다.
• α_comm < 1(컴퓨팅 제한): A12 분산 리소스 풀(검증된 IDC, 워크스테이션 및 에지 노드)에 예약하여 로컬 폐쇄 루프 작업(추론, 임베딩, LoRA/QLoRA, 일괄 처리)을 실행하여 WAN의 고주파수 동기화를 방지합니다.

α_comm의 두 가지 시간 구성요소는 고전적인 Hockney 통신 모델과 Roofline 처리량 추정을 사용하여 모델링되었습니다.

• 통신 시간: T_comm ≒ T_startup + m / BW + o(m), 여기서 m은 단일 단계 동기화를 위해 전송될 데이터의 양입니다(예: 전체 매개변수 훈련에서 이는 동기화할 매개변수의 바이트 수 × 동기화 횟수와 거의 같습니다). BW는 링크의 유효 대역폭(실제 측정, 비공칭), T_startup은 고정 시작 지연(일반적으로 WAN의 경우 10~100ms, 일반 NVLink/IB < 10μs), o(m) 프로토콜 스택에 대한 추가 항목;
• 계산 시간: T_compute = FLOPs / eta_eff, 여기서 FLOPs는 단일 단계 부동 소수점 연산의 양(전체 매개변수 훈련은 대략 6 × 매개변수 양 × 토큰 수)이고 eta_eff는 측정된 유효 컴퓨팅 전력 처리량입니다(루프라인 모델 하의 ​​산술 강도 제약 조건에 따라 일반적으로 최대 컴퓨팅 전력의 30%-60%).

7B 매개변수 모델의 전체 매개변수 미세 조정을 예로 들어 보겠습니다. 데이터 병렬 처리에서 각 단계에는 약 28GB의 동기화가 필요하며(FP16 가중치 + 최적화 프로그램 상태는 구현에 따라 다름) 25Gbps WAN 링크(유효 대역폭 ≒ 3GB/s)에서 단일 단계 통신에는 ≒ 9.3초가 걸립니다. InfiniBand 400Gbps(유효 45GB/s) 클러스터에서는 동일한 동기화 양이 1 미만입니다. 초 - 통신 시간은 크기에 따라 다르지만 이 규모의 단일 단계 계산은 단 몇 초에 불과합니다. 이는 "높은 통신 작업이 중앙 집중식 클러스터에 유지되어야 함"에 대한 정량적 기반입니다. 여기서 강조할 점은 25Gbps는 전용선/데이터센터 상호접속 수준에 속한다는 점이다. 홈 업링크 1Gbps(실효 110MB/s)를 기준으로 다시 계산하면 동일한 28GB 동기화 볼륨은 단계당 약 265초가 소요되며 이는 위의 예보다 거의 30배 더 높습니다. 이 결론은 실제 에지 대역폭 분포의 예보다 훨씬 더 극단적입니다. 스케줄러의 α_comm 매개변수 라이브러리는 목표 공급단 대역폭 분포(업스트림 P50/P90, 국경 간 지연)에 따라 구축되고 추정 오류에 대한 내결함성을 유지합니다. 임계값 양쪽의 경계 작업은 실제 측정 검토를 통해 결정됩니다. 스케줄러는 작업이 제출될 때 α_comm을 추정하여 라이브러리에 저장하고 이를 실제 작업 실행에서 관찰된 값과 비교하여 대역폭 및 처리량 매개변수 라이브러리를 지속적으로 수정합니다. 다섯 가지 일반적인 작업 유형에 대한 오프로드 추정은 그림 5-1에 나와 있습니다.

그림 5-1 이중 경로 스케줄링 및 오프로드의 기초: α_comm 임계값의 두 측면은 각각 중앙 집중식 클러스터와 분산 리소스 풀입니다.

5.3 일정 결정 및 SLA 모델

일정 점수 매기기는 다중 목표 가중치를 적용합니다.

가중치는 작업 유형에 따라 동적으로 조정됩니다. 스케줄링 솔루션은 엔지니어링에서 제약 필터링 + 그리디 스코어링의 두 단계로 단순화됩니다. 먼저 하드 제약 조건(에셜론 승인, SLA 승인, 메모리/토폴로지 일치, 평판 임계값)에 따라 후보 세트를 필터링한 다음 점수에 따라 나머지 후보를 정렬하여 최적의 후보를 선택합니다. 전체적인 복잡도는 O(N log N)이며, 1,000개 수준의 노드 규모에서 단일 의사결정은 밀리초 안에 완료될 수 있습니다. 다목적 가중치의 장기 최적화는 연구 항목으로 나열되며 첫 번째 버전에는 적용되지 않습니다.

SLA 가용성을 위한 중복 수학. 단일 노드의 월간 가용성이 A₀이고 활성 노드와 백업 노드가 독립적인 전원 공급 장치와 네트워크 콘센트를 통해 독립적으로 배포된다고 가정하면 전체 서비스 가용성은 다음과 같습니다.

A = 1 − (1 − A₀)²

A₀ = 99.5%를 예로 들면, 이중 머신 이중화 이후에는 A = 1 − 0.005² = 99.9975%, 즉 월별 누적 비가용 시간이 약 3.6시간에서 약 1.1분으로 압축됩니다. 플랫폼은 이를 기반으로 용량 계획을 수행합니다. 목표 가용성 A*는 필요한 단일 노드 가용성 A₀* = 1 − √(1 − A*)에서 추론됩니다. A₀ ≥ A₀* ≥ 판매된 SLA 주문 수 + 안전 마진을 충족하는 전용 리소스 풀의 활성 및 백업 쌍 수가 새로운 주문이 허용되는 경우에만 마진이 부족하면 초과 판매 대신 새로운 SLA 주문이 거부됩니다. 이는 용량 수준에서 §4.4 이중 레일 격리를 구현한 것입니다. 다음 사항을 강조해야 합니다. 위의 99.5% 및 99.9975%는 실제 측정 결론이 아니라 설계 목표이기도 한 설계 기준 구경의 계산 예시입니다. 예제는 중복 합성의 크기 관계를 설명하는 데 사용되며 99.9975%는 외부 약속 값이 아닙니다(외부 약속의 하한에 대해서는 아래 SLA 목표 값 프레임워크 참조).

제어 영역 가용성(A_platform). 위 공식은 리소스 노드 측의 중복성만 다룹니다. 일정 관리, 측정, 정산 및 검증 클러스터와 같은 제어 평면 구성 요소는 플랫폼에 의해 자체 구축 및 운영되며 가용성은 별도로 모델링됩니다. 제어 평면은 여러 가용성 영역에 배포되고 WSS 게이트웨이는 다중 활성입니다. 검증 클러스터를 사용할 수 없는 경우 챌린지 발행이 자동으로 무작위 검사 모드로 다운그레이드되고 대기 수익의 출시가 연기되고 노드 기본값이 고려되지 않습니다. 외부적으로 커밋된 서비스 수준 가용성 = A_platform × A_node. 그 설계 목표값은 아래의 "SLA 목표값 프레임워크"에 나와 있습니다. 공식 약속 값은 공식 출시 버전과 함께 발표되며 추적 번호 D-23으로 등록됩니다. 제어 플레인 오류 시 청구 규칙: 오류 기간 동안 청구가 일시 중단되고 SLA에 도달한 주문은 보상 조건에 따라 실행됩니다. 테넌트는 플랫폼 오류에 대해 비용을 지불하지 않습니다.

SLA 목표 가치 프레임워크(2단계 아웃바운드 판매의 전제 조건) 외부적으로 약속된 서비스 수준 가용성 목표 값은 공식 릴리스 버전에서 발표됩니다. 이 기사에서는 먼저 설계 목표를 제시합니다. 배타적 보장 모드 서비스 수준 가용성 A_service ≥ 99.5%, 여기서 제어 평면 A_platform ≥ 99.9%, 노드 측 합성 가용성 ≥ 99.6%(A = A_platform × A_node에 따라 합성됨). 세 가지 기준은 다음과 같이 명확합니다. 첫째, 99.5%는 예상 운영 가치가 아닌 외부 약속의 하한입니다. - 용량 계획은 위 공식의 A* 역해 A₀* 논리에 따라 실행됩니다. 이는 설계 기준 A₀ = 99.5%(월간 구경) 하에서 이론적 합성 값인 이전 예인 99.9975%와 충돌하지 않습니다. 하한값과 이론적 합성값의 차이는 외부 약속의 안전 여유입니다. 둘째, A₀의 설계 기준은 월간 99.5%(독점 보장 모드 활성 및 백업 노드)입니다. A = 1 − (1 − A₀)²의 역해에 따르면 외부에서 커밋된 노드 측 합성 가용성 ≥ 99.6%는 A₀* ≥ 93.68%에 해당합니다. 93.68%는 단일 노드의 설계 기준이 아닌 외부 약속의 하한에 해당하는 역수 값입니다. 실제 용량 계획은 99.5% 기준 실행을 기반으로 합니다. 셋째, 통계 창: A_service, A_platform 및 A_node는 모두 자연 월(월별 창)을 기준으로 계산됩니다. 연간 가용성은 12개월의 자연 개월의 산술 평균입니다. SLA 보상은 회계주기로서 자연월을 기준으로 합니다. 위의 모든 값은 실제 측정 결론이 아닌 설계 목표입니다. 목표 값이 공식적으로 발표되기 전에는 플랫폼이 대중을 대상으로 SLA가 포함된 서비스 계약을 체결하지 않을 것입니다. 2단계 SLA 상용화는 이 발표를 엄격한 전제 조건으로 기반으로 합니다. 플랫폼 장애시 "실패시 과금되지 않습니다" 과금 및 보상 규정은 목표값과 동시에 공지됩니다.

공급측면의 경제학과 독점적인 풀 잉여물 처리. 플렉서블 모드에서 단일 RTX 4090급 기기의 월별 수익 범위, 전기 요금 및 감가상각비, "유휴/재판매" 기회 비용에 대한 비교 계산표 [출시 전 공지 · D-24] - 이 계산은 §9.2의 노드 유지 및 규모 목표에 대한 첫 번째 근거입니다. 전용 풀이 기준에 도달하고 마스터/백업 쌍이 장기간 판매 주문을 초과하는 경우 유휴 용량은 탄력적 풀로 이전되어 중단 가능한 작업을 수행하거나 일방적인 유휴 상태를 피하기 위해 용량 예약 계약에 따라 엔터프라이즈 테넌트와 정산됩니다.

일정 결정 의사결정의 참조 구현은 다음과 같습니다(제한된 필터링 + 탐욕스러운 점수, 의사 코드 표시).

일정 가격 책정 메커니즘: 작업 가격 책정은 "공개 기본 가격 + 품질 보너스" 구조를 채택합니다. 기본 가격은 공개 규칙에 따라 수요와 공급에 따라 변동하며(EIP-1559의 가격 발견 아이디어 참조, §3.4 참조) 품질 보너스는 리소스 계층(Tier-S/A/B/C) 및 SLA 수준에 따라 부과됩니다. 모든 가격 매개변수는 공개적으로 이용 가능하며 어떠한 왜곡도 방지하기 위해 확인할 수 있습니다.

5.4 자원 계층 스케줄링 제약표

제대와 수행할 수 있는 임무 범위 간의 해당 관계는 다음과 같습니다(§4.6의 CU 분류와 일치).

5.5 작업 수명 주기 및 분쟁 처리

작업 상태 머신: 보류 중 → 예약됨 → 실행 중 → (일시 중단됨) → 완료됨/실패함/이의 제기됨. 분쟁 중인 동결 작업은 대기 중인 수익에 해당하며 대화형 재생 포지셔닝에 들어갑니다. 즉, 확인 클러스터에서 작업 조각을 재생하고 책임 당사자(노드, 플랫폼 또는 테넌트 입력)를 찾고 책임에 따라 보상을 나눕니다.

그림 5-2 A12 작업 수명 주기 상태 머신: 분쟁이 있는 작업은 보류 수입을 동결하고 책임 당사자를 찾기 위해 대화형 재생에 들어갑니다.

5.6 테넌트 대상 콘솔 및 보안 샌드박스 런타임

기존 클라우드 플랫폼보다 열등하지 않은 테넌트 경험을 제공하기 위해 레이어 2는 테넌트 상호 작용 계층과 보안 실행 환경을 캡슐화합니다. 다음은 설계 목표이며, 합격 지표는 0단계 내부 테스트를 통해 공개됩니다.

• 웹 터미널 및 파일 채널: 노드가 등록된 후 디스패치 게이트웨이에 대한 아웃바운드 암호화된 WebSocket(WSS) 연결을 적극적으로 설정하여 역방향 프록시 터널을 형성합니다. 테넌트 콘솔은 웹 터미널 에뮬레이션 구성 요소를 사용하여 노드에 직접 연결하므로 공용 네트워크 IP 포트 매핑 및 키 배포 프로세스가 필요 없으며 모든 NAT/방화벽 환경과 호환됩니다. 콘솔은 온라인 노트북 서비스 및 파일 스토리지 서비스의 에이전트 역할을 동시에 수행하며, 대용량 데이터 세트 및 교육 스크립트의 안정적인 전송을 보장하기 위해 HTTP 청크 및 중단점 재개를 사용하여 업로드합니다.
• 컨테이너화된 2차 인스턴스 예약: 기존 가상 머신 모드를 사용하는 대신 경량 컨테이너 런타임이 샌드박스로 사용됩니다. 플랫폼은 간소화된 기본 이미지(Ubuntu LTS + CUDA + PyTorch 추론 스택 + 공통 종속성)로 사전 설정되어 있으며 이미지의 읽기 전용 레이어는 유휴 기간 동안 미리 로드됩니다. 작업이 시작되면 몇 메가바이트의 사용자 정의 레이어만 실시간으로 가져옵니다. 설계 목표: 단일 인스턴스 콜드 스타트 ​​시간 ≤ 10초(동일한 지역, 미러 캐시 적중 계층, 지역 간 또는 캐시 부적중 시나리오는 노드 업스트림 대역폭을 기준으로 서로 다른 대상으로 나뉘며 실제 측정된 데이터는 공개 승인 보고서의 적용을 받습니다).
• 물리적 수준 할당량 격리: cgroups v2 및 Seccomp를 사용하여 컨테이너의 CPU, 메모리 및 IO 대역폭에 대한 엄격한 제한을 설정합니다. NVIDIA 컨테이너 런타임을 사용하여 할당된 GPU 장치만 컨테이너에 표시되도록 합니다. 이러한 격리는 공격 표면을 크게 줄이고 부차 프로세스가 테넌트 메모리를 읽는 것을 방지할 수 있지만 컨테이너 탈출을 완전히 제거할 수는 없으며(잔존 위험은 10장 참조) 플랫폼은 남용 보상 기금을 사용하여 비용을 충당합니다.

육도 음정6장 계층 3: 모델 서비스(MaaS)

6.1 모델 액세스 및 버전 관리

통합 모델 레지스트리는 모델 소스, 버전, 가중치 요약, 운영 환경 및 평가 결과를 기록합니다. 엔터프라이즈 프라이빗 모델은 호스팅만 되며 지적 재산권의 소유권을 변경하지 않습니다. 이 약속은 §4.7 보안 메커니즘 및 §5.6 격리 조치에 의해 제한됩니다. 탄력적 노드 모드의 IP 보호는 컨테이너 격리에 의존합니다(컨테이너 탈출을 완전히 제거할 것을 약속하지 않으며 잔여 위험은 §4.7 보험 및 남용 보상 기금으로 보장됩니다). IP 격리에 대한 요구가 강한 테넌트는 독점 보증 모드를 사용하거나 §4.7의 미래 지향적인 TEE 기밀 컴퓨팅 계층(연구 프로젝트)을 채택하는 것이 좋습니다. 모델을 선반에 올려놓으려면 의도된 용도, 알려진 제한 사항 및 평가 벤치마크를 기록하고 이를 플랫폼 측정 시스템과 연결하기 위해 모델 카드를 제출해야 합니다.

6.2 수직적 산업 모델 파이프라인

플랫폼 기획은 "하나의 수직 방향" 접근 방식으로 모델 레이어의 경쟁력을 확립합니다. 첫 번째 수직 방향은 Web3 코드 및 보안 엔지니어링입니다(공개된 팀 배경과 일치합니다. 이 섹션의 모든 지표는 계획 목표이며 완성된 사실이 아닙니다).

• 코퍼스 관리: 오픈 소스 계약 웨어하우스, 공개 취약성 공개 커뮤니티 및 체인의 검증된 계약의 소스 코드를 수집하고 라이선스를 부여하기 위해 구조화된 데이터 수집 파이프라인을 구축합니다. 사전 훈련 코퍼스는 구문 트리 필터링, 대략적인 중복 제거 및 수동 샘플링 후에 형성됩니다. 규모 목표: 사전 훈련 코퍼스 ≥ 100억 토큰의 첫 번째 배치입니다. 라이선스 거버넌스: 라이선스 화이트/블랙리스트 설정 - 허용 라이선스(MIT/Apache/BSD)가 우선적으로 포함됩니다. GPL/AGPL 및 기타 카피레프트 라이센스 말뭉치의 포함 범위와 "훈련 가중치가 파생 저작물인지 여부"에 대한 법적 수준은 특별한 법적 의견의 적용을 받습니다. [법적 의견: 공개 전 보충 및 공개 · D-25] 중복 제거 및 라이선스 심사 규칙은 코퍼스 파이프라인 문서와 함께 공개됩니다. 10B 토큰은 첫 번째 규모 배치이며 모델 규모는 친칠라 스케일링 법칙 및 코퍼스 양(효율 우선의 중소 매개 변수 기어)과 동시에 계획됩니다. 후속 배치의 데이터 예산 및 일정 [보충 및 출시 전 발표 · D-26].
• 연속 사전 학습(CPT) 및 감독 미세 조정(SFT): 오픈 소스 코드 기반 모델을 현장에서의 연속 사전 학습의 출발점으로 사용한 후 감독 미세 조정을 위한 "결함 위치 → 공격 경로 구성 → 결과 예측 → 패치 제안 → 회귀 테스트" 다단계 추론 지침 세트를 중첩합니다. 훈련은 5장의 이중 경로 규칙에 따라 중앙 집중식 컴퓨팅 센터(Tier-S echelon)에서 수행됩니다. 훈련 규모(인스턴스 수, 병렬 전략, 컨텍스트 길이)는 단계 예산과 함께 발표되며 고정된 약속은 없습니다.
• DPO(Tool Call Alignment): 모델 출력을 외부 도구 샌드박스(컴파일 테스트 프레임워크, 정적 분석 도구)에 연결하고 도구 실행 결과를 사용하여 직접 선호도 최적화를 위한 선호도 데이터를 구성하여 "고스트 취약점" 오탐을 줄입니다. 이 메커니즘은 결정론적 개선입니다. 즉, 도구를 통해 모델 결론을 검증할 수 있어야 합니다.

두 훈련 단계의 목적함수는 다음과 같다(설계 목표 구경).

SFT 단계는 마스크된 교차 엔트로피 손실을 사용합니다. 보조자의 응답 부분에 대해서만 손실이 계산되고 프롬프트 단어 부분이 마스크됩니다.

L_SFT(θ) = − (1/|y|) · Σ_{t=1}^{|y|} log p_θ(y_t | x, y_{&lt;t})

여기서 x는 입력(다단계 추론 지침 템플릿 포함)이고, y는 목표 출력 시퀀스입니다. |y| 는 목표 시퀀스의 길이이고 p_θ는 매개변수 θ에 따른 모델 조건부 확률입니다. 다단계 추론 명령어 세트(결함 위치 → 공격 경로 구성 → 결과 예측 → 패치 제안 → 회귀 테스트)는 구조화된 템플릿으로 구성되어 손실이 추론 체인의 생성 품질과 결론에 집중됩니다.

DPO 단계는 도구 실행 결과를 기반으로 선호 쌍(y_w, y_l)을 구성합니다. y_w는 도구 검토(컴파일 통과, 테스트 통과, 정적 분석 확인)를 통과한 출력이고, y_l은 도구에 의해 거부된 출력입니다. 참조 모델 p_ref의 제약 조건에 따라 최적화되었습니다.

L_DPO(θ) = − E_{(x, y_w, y_l)} [ log σ( β·log(p_θ(y_w|x)/p_ref(y_w|x)) − β·log(p_θ(y_l|x)/p_ref(y_l|x)) ) ]

여기서 σ는 시그모이드 함수이고 β는 참조 모델과의 편차 강도 계수(일반적으로 0.1)이며, 암시적으로 독립적인 보상 모델 훈련을 대체합니다. 이 경로의 엔지니어링적 중요성은 선호 신호가 수동 주석의 주관적인 판단에 의존하지 않고 도구 실행의 객관적인 결과에 고정되어 "고스트 취약점의 오탐지 감소"를 일회성 매개변수 조정 결과가 아니라 재현 및 회귀할 수 있는 최적화 목표로 만든다는 것입니다.

훈련 규모 계획: 친칠라 스케일링 법칙. 수직 모델 훈련 예산은 목표 손실 L, 모델 매개변수 수 N, 훈련 토큰 수 D에 의해 결정되며 Chinchilla와 유사한 경험적 형식을 따릅니다.

그 중 E는 환원 불가능한 오류이고 A, B, α, β는 작업과 관련된 경험 계수입니다. 이 공식은 데이터를 늘리지 않고 단순히 모델을 확장하거나, 모델을 확장하지 않고 단순히 데이터를 늘리면 한계 수익 체감 영역에 진입하게 됨을 보여줍니다. 이를 기반으로 플랫폼은 "모델 크기 ⇔ 코퍼스 크기 ∅ 컴퓨팅 파워 예산"의 3원 계획을 세우고, 단계 예산에 따라 학습 규모(인스턴스 수, 병렬 전략, 컨텍스트 길이)를 공개하며 고정된 약속을 하지 않습니다.

규정 준수 경계: 모델 기능은 보조 참조 도구로 배치되며 출력은 개발 지원 및 내부 보안 평가에 사용됩니다. CVSS 등급이 포함된 공식 감사 보고서는 외부에서 발행되지 않으며 해당 서비스는 자격을 갖춘 파트너가 발행해야 합니다. 연락 프로세스가 시작되었으며, 최소 한 명의 적격 파트너 서명이 완료되었으며 대상 공개 베타가 출시되기 전에 이름이 공개되었습니다. 제품 라인은 서명 이전에는 공식적으로 상용화되지 않으며, 협력 진행 상황은 공식 웹사이트에 단계적으로 업데이트될 예정입니다(제10장 미래예측 진술에 따름).

6.3 OpenAI 호환 API 게이트웨이

게이트웨이는 OpenAI 인터페이스 표준을 엄격하게 따르며 기존 애플리케이션의 제로 코드 마이그레이션을 실현합니다.

• 표준 엔드포인트: /v1/chat/completions, /v1/models 및 /v1/embeddings의 이전 버전과의 호환성을 제공하고 SSE(서버 측 이벤트) 스트리밍 반환을 지원합니다. OpenAI SDK, LangChain 또는 LlamaIndex가 통합된 애플리케이션은 게이트웨이 주소와 키만 교체하면 됩니다.
• 동적 로드 밸런싱: 게이트웨이는 각 리소스 계층에 따라 추론 큐 깊이를 할당합니다. 긴 컨텍스트의 고부하 작업은 Tier-A 이상의 리소스로 라우팅되고, 빈도가 높은 짧은 작업은 에지 리소스 풀로 라우팅됩니다. 설계 목표: 공개 베타 기간 동안 TTFT(첫 번째 단어 지연 중앙값)는 400ms 이하입니다(8K 컨텍스트 기어 이하, 32K 긴 컨텍스트 기어는 공개 베타 측정 데이터와 별도로 설정됨).
• 로드 밸런싱 알고리즘: "두 가지 선택의 힘" 전략은 동일한 계층 내에서 채택됩니다. 두 개의 후보 인스턴스가 무작위로 선택되고 요청은 대기열 깊이가 더 작은 인스턴스로 전송됩니다. 이 전략은 전역 최소 검색이 필요하지 않으며 O(1)의 통신 오버헤드가 있지만 전역 무작위 지수 분포에서 다항식 붕괴로 큐 길이를 줄일 수 있습니다. 고전 큐잉 이론의 결론은 시스템 로드가 포화에 가까울 때 2차 선택이 평균 큐 길이를 O(n)에서 O(log log n)로 줄인다는 것입니다. "항상 가장 비어 있는 인스턴스를 선택"하는 글로벌 스캐닝 솔루션과 비교할 때 스케줄러 자체의 낮은 대기 시간과 수평 확장성은 게이트웨이 TTFT 목표와 일치하는 천 수준 인스턴스 규모에서 매우 작은 롱테일 비용으로 교환됩니다.

대기열 이론 용량 계획. 요청이 대략적인 포아송 프로세스, 단일 인스턴스 서비스 속도 μ, 동시 인스턴스 수 c로 도착할 때 대기 대기 시간은 Erlang C 공식(M/M/c 모델)으로 제공됩니다.

그 중 T_prefill(s)는 prefill 단계의 계산 시간(컨텍스트 길이 s에 따라 선형적으로 증가)이고 C(c, ρ)는 Erlang C 대기 확률입니다. 이 모델은 두 가지 엔지니어링 결정에 사용됩니다. 첫째, TTFT 목표(400ms)가 주어진 각 계층에 필요한 최소 동시 인스턴스 수 c를 역결정합니다. 둘째, 큐 깊이가 포화 상태에 도달하기 전에 확장을 트리거합니다(ρ → 1). 이는 로드 밸런서가 큐 깊이를 라우팅 신호로 사용하는 이론적 기반입니다. 퍼블릭 베타 기간 동안 측정된 도착률 λ로 μ를 보정한 후 용량 계획표를 발표할 예정이다.

6.4 추론 성능 엔지니어링: 지속적인 배치 처리 및 콜드 스타트 ​​최적화

• 반복 수준 연속 일괄 처리: 반복 세분성에서 동적으로 요청을 삽입하고 종료합니다. 요청이 종료되면 해당 비디오 메모리 페이지가 즉시 재활용됩니다. 새 요청은 준비 대기열에 들어가 다음 반복이 삽입될 때까지 기다리므로 정적 일괄 처리의 "배럴 효과"가 제거됩니다. 설계 목표: GPU 유효 로드율 ≥ 75%(공개 수용 보고서의 실제 측정에 따름)
• 비디오 메모리 페이징 관리: 페이징 키-값 캐시(PagedAttention 유형 솔루션)를 채택하고 KV 캐시를 고정 길이 비디오 메모리 페이지로 나누고 페이지 테이블과의 논리적 매핑을 유지합니다. 불연속적인 물리적 할당을 지원하고 조각화 속도를 줄입니다. 접두사 비디오 메모리 블록을 공유하기 위해 다중 라운드 대화 분기를 지원합니다.
• 콜드 스타트 ​​캐시: 각 리소스 풀 노드에 기본 모델의 읽기 전용 가중치를 미리 로드합니다. 사용자 정의 LoRA 가중치(보통 수십 MB)는 분산 캐시를 통해 근처로 당겨지고 핫스위치되어 동일한 GPU에서 다중 테넌트와 다중 모델의 원활한 전환을 지원합니다.

KV 캐시 용량 계획(설계 목표). 페이징 관리의 용량 요구 사항은 다음과 같이 추정됩니다.

M_KV = 2 × L × H_kv × d_head × s × b × bytes_per_elem

그 중 2는 K/V 캐시, L은 레이어 수, H_kv는 키 값 헤드 수(GQA 그룹화를 사용하여 attention을 쿼리하는 경우 H_kv `` attention 헤드 수, 캐시를 크게 압축할 수 있음), d_head는 각 헤드의 차원, s는 시퀀스 길이, b는 동시 배치 크기, bytes_per_elem은 정밀 바이트 수입니다. 80 레이어, H_kv = 8, d_head = 128, 32K 컨텍스트를 전달하는 FP16 모델을 예로 들면: 단일 시퀀스 KV 캐시 ≒ 2 × 80 × 8 × 128 × 32768 × 2 B ≒ 10.7GB - 이 크기는 모델 무게 자체가 아닌 KV 캐시가 종종 긴 컨텍스트 서비스의 비디오 메모리 병목 현상이 된다는 것을 보여줍니다. 페이징 메커니즘은 조각화 비율의 상한을 "시퀀스당 1페이지 미만"(일반적인 페이지 크기 16개 토큰, 이론적 낭비 ≤ 페이지 크기 × 시퀀스 수)으로 낮추고 접두사 공유를 통해 동일한 시스템 프롬프트 단어를 사용하여 여러 라운드의 대화 및 요청을 허용하여 동일한 물리적 페이지 배치를 재사용할 수 있습니다.

지속적인 일괄 처리를 위한 처리량 모델입니다. GPU 페이로드 속도는 대상 연산자의 실제 실행 시간의 비율로 정의됩니다.

Util = T_busy / (T_busy + T_idle + T_overhead)

정적 일괄 처리에서 T_idle은 "배치에서 가장 느린 요청을 기다리는 빠른 요청"(배럴 효과)에서 비롯됩니다. 배치가 클수록 폐기물이 더 무거워집니다. 연속 일괄 처리는 반복 세분성으로 일괄 처리를 재구성하므로 T_idle이 0에 가까워지고 나머지 오버헤드는 스케줄링 자체(T_overhead, 밀리초 수준)만 됩니다. KV 캐시 온디맨드 할당과 결합되어 스케줄러는 "배치 크기 상한 × 시퀀스 길이 상한"으로 구성된 메모리 엔벨로프 내에서 동시 시퀀스 수를 동적으로 최대화할 수 있습니다. 이는 놀라운 숫자가 아닌 75% 페이로드 속도 설계 목표(공개 승인 보고서의 실제 측정에 따라 다름)를 위한 메커니즘의 소스입니다.

루프라인 퍼포먼스 모델. 단일 카드 추론의 최대 처리량은 산술 강도 I(FLOP/바이트)에 따라 달라집니다.

그 중 π_peak는 최대 컴퓨팅 성능이고 β_mem은 메모리 대역폭입니다. 산술 강도가 낮은 작업(예: 대부분 메모리에 바인딩된 디코딩 단계)의 실제 처리량은 최대 컴퓨팅 성능이 아닌 β_mem·I에 의해 결정됩니다. 이는 KV 캐시 압축, 저정밀도 추론, PagedAttention, 연속 배치 처리 등 '토큰당 메모리 접근량 감소'를 추구하는 기술의 이론적 기반이다. 성능 엔지니어링 예측(연구 항목, §9.3 참조). 추론 최적화 커뮤니티의 주요 방향은 다음을 포함하여 MaaS 계층의 지속적인 발전 경로로 추적됩니다.

• 추론적 디코딩: 소형 모델 초안 작성 및 대형 모델 병렬 검증 생성 방법을 사용하여 출력 품질은 변경되지 않은 상태에서 디코딩 지연이 여러 번 압축됩니다. 초안 검증 구조는 A12 검증 클러스터 아키텍처에 자연스럽게 맞습니다.
• 저정밀도 추론(FP8/FP4): KV 캐시 및 행렬 곱셈을 하드웨어의 기본 저정밀도 형식으로 전달하고 비디오 메모리 점유 및 대역폭 요구 사항을 동일하게 압축합니다. §6.4의 M_KV 공식에 따르면 FP8은 동일한 카드가 전달할 수 있는 동시 긴 컨텍스트 시퀀스 수를 직접 두 배로 늘릴 수 있습니다.
• 사전 채우기/디코드 분리 아키텍처(분리형 서빙): 첫 번째 단어 생성(계산 집약적)과 후속 디코딩(대역폭 집약적)을 서로 다른 리소스 풀로 분할합니다. 이는 A12의 "통신-계산 비율로 분할" 스케줄링 철학과 동일합니다.
• KV 캐시 계층적 오프로딩: HBM → DDR → NVMe의 3레벨 캐시 계층, 온도 인식 페이지 마이그레이션을 통해 서비스 가능한 컨텍스트 길이 확장
• 의미론적 캐싱: 의미론적으로 반복되는 요청에 대해 캐시된 답변을 직접 재사용하여 지식 기반 Q&A 로드에서 컴퓨팅 전력 소비를 크게 줄입니다.
• MoE 전문가 병렬: 하이브리드 전문가 모델의 전문가 가중치의 교차 노드 배포 및 동적 라우팅을 통해 "수백억 개의 매개변수 수준 모델이 분산 리소스 풀에서 제공"될 수 있습니다. 이는 분산 컴퓨팅 성능 네트워크와 독립형 솔루션을 차별화할 수 있는 기회입니다.

그 중 그래픽 메모리 사용량에 대한 GQA 및 저정밀도 추론 메커니즘의 정량적 효과는 그림 6-1에 나와 있습니다(나머지 메커니즘의 이점은 용량 제한 및 처리량 향상의 형태로 반영됩니다. 5장 참조).

그림 6-1 KV 캐시 용량 모델: GQA 압축 효과 및 비디오 메모리 사용량에 대한 낮은 정밀도(80 레이어 모델, 단일 시퀀스)

6.5 모델시장과 측정 및 정산

• 청구는 통화 수, 토큰 수, 컴퓨팅 성능 기간 또는 구독을 기반으로 합니다. 결제는 기본적으로 법정통화 또는 안정적인 통화로 이루어지며, A12 Token은 수수료 할인 및 인센티브 바우처로 사용됩니다(8장 참조).
• 모델 개발자는 콜을 기반으로 수익을 공유하며, 공유 비율은 모델 상장 계약에서 합의 및 발표됩니다. 감사를 위해 측정 기록을 내보낼 수 있습니다.

제칠7장 계층 4: 에이전트 및 애플리케이션(AaaS)

7.1 시각적 에이전트 오케스트레이션 캔버스

엔지니어링 개발 능력이 없는 사용자를 위해 로우 코드 드래그 앤 드롭 에이전트 오케스트레이션 시스템이 제공됩니다.

• 구성 가능한 노드: 트리거 클래스(웹후크, 타이밍, 이벤트 모니터링, 대화 상자), 추론 클래스(레이어 3 모델 또는 외부 모델 호출, 매개변수는 실시간으로 조정 가능), 도구 클래스(코드 실행, SQL 쿼리, 외부 API, 정적 분석), 제어 클래스(분기, 루핑, 구문 분석, 오류 복구 및 보상).
• 워크플로 DSL 컴파일: 프런트 엔드 캔버스가 방향성 그래프로 렌더링됩니다. 컴파일러는 연결성과 순환 종속성을 확인한 다음 이를 선언적 워크플로 정의(JSON/YAML)로 변환하여 버전 관리 가능한 자산으로 저장합니다.
• DAG 실행 엔진: 백그라운드 무상태 실행 엔진은 토폴로지 순서에 따라 노드를 예약하고, 비종속 노드는 동시에 실행하며, 종속 노드는 컨텍스트 상태 트리를 통해 중간 결과를 전달합니다. 분쟁 재생 과정 전반에 걸쳐 실행 기록이 유지됩니다.

실행 스케줄링의 수학적 속성은 다음과 같습니다. 워크플로가 방향성 비순환 그래프 G = (V, E)로 컴파일된 후 엔진은 Kahn 알고리즘을 사용하여 토폴로지 정렬을 수행하여 각 노드의 차수 내 테이블을 유지합니다. in-degree가 0인 노드는 동시 실행을 위해 준비 대기열에 들어갑니다. 완성된 각 노드는 후속 in-degree를 1씩 감소시키고 전체 복잡성은 O(|V| 스케줄링 병렬성 정도는 그래프의 최대 링크 방지 너비에 의해 제한됩니다(너비 w인 그래프는 언제든지 최대 w개의 노드를 동시에 가질 수 있음). 전체 워크플로의 완료 시간에는 하한이 있습니다. 즉, 소스에서 싱크까지의 가중치가 부여된 가장 긴 경로인 임계 경로 길이는 각 노드의 예상 시간 소비에 가중치를 적용하여 계산됩니다. 이를 기반으로 오케스트레이션 캔버스는 사용자 중요 경로 하이라이트 및 예상 완료 간격을 확인하여 "어느 노드가 전체를 느리게 하는지"를 경험적 판단에서 계산 가능한 결론으로 변경합니다.

DAG 위상 정렬(칸 알고리즘)의 참조 구현:

• 도구 프로토콜 표준화(미래 지향적): 도구 노드는 MCP(모델 컨텍스트 프로토콜)와 같은 개방형 도구 액세스 프로토콜과 점차적으로 정렬되므로 외부 도구 제조업체는 "한 번 적응하고 여러 플랫폼에서 사용할 수 있습니다". 다중 에이전트 워크플로우 간의 A2A(에이전트 대 에이전트) 프로토콜을 기반으로 작업 위임 및 상태 상호 인식을 탐색하고 조직 간 에이전트 협업을 위한 표준 인터페이스를 예약합니다. 위의 사항은 모두 설계 목표이며 실제 프로토콜 버전의 성숙도에 따라 달라질 수 있습니다.

7.2 개발자 도구 체인: VS Code 플러그인 및 Web IDE

• 코드 지원 플러그인: 레이어 3 추론 게이트웨이에 연결하고 코드 작성 시 컨텍스트(Fill-in-the-Middle)에서 완성, 문서 설명 및 단위 테스트 생성 제안을 제공하는 LSP(Language Server Protocol) 기반 편집기 확장입니다.
• 내장형 정적 검사: 이 플러그인에는 실시간 검색을 위한 경량 AST 파서가 내장되어 있으며 일반적인 위험한 패턴에 대한 내장형 경보 및 원클릭 복구 제안을 제공합니다. 경보 규칙은 모델 출력과 같은 보조 참조로 배치되며 수동 감사 및 공식 감사 보고서를 대체하지 않습니다.
• Cloud Web IDE: IDE의 브라우저 버전이 콘솔에 내장되어 있습니다. 한 번의 클릭으로 격리된 컨테이너 환경을 시작하여 컴파일 및 테스트를 수행할 수 있습니다. §5.6의 샌드박스 런타임과 동일한 격리 및 할당량 메커니즘을 재사용합니다.

7.3 사전 설정된 산업 에이전트 매트릭스

플랫폼 계획은 즉시 배포할 수 있는 세 가지 유형의 상용 에이전트 템플릿을 미리 설정합니다(온라인 계획은 9장, 3단계 참조). 이 템플릿은 모두 §7.1의 오케스트레이션 시스템으로 구현되고 6장의 모델 서비스를 추론 백엔드로 사용합니다.

• 코드 및 보안 평가 도우미: 다중 역할 협업 워크플로 - 프로토콜 구조 분석, 공개 취약성 데이터를 기반으로 한 사용 사례 생성, 샌드박스의 동적 검증 및 구조화된 결과 요약. 워크플로우의 최하위 계층은 ReAct 및 CoT와 같은 주류 추론 모드 및 모델 라우팅을 지원하고 입력 복잡성에 따라 비용과 정확성의 균형을 자동으로 조정합니다. 출력은 내부 참조 보고서이며 공식 CVSS 등급을 포함하지 않습니다. 공식 감사는 자격을 갖춘 파트너가 발행합니다(아직 결정되지 않았으며 확인 후 공개됩니다).
• 온체인 데이터 연구 보고서 에이전트: 분산형 거래소 거래량, 대출 계약 잠금 변경 및 고래 주소 변경을 모니터링하고 시계열 분석을 결합하여 정기적으로 정량적 연구 보고서를 생성합니다. 데이터 소스와 수준은 공개적으로 이용 가능합니다. 연구 및 보고 에이전트는 재배포 승인이 있는 공개 데이터 소스에만 액세스합니다. 상용 데이터 공급자는 반드시 라이선스 동의서 서명을 완료한 후에 접근해야 하며, 승인 여부는 제품 문서와 함께 공개된다. [데이터 출처 목록 및 승인 현황: 공개 전 보완 및 공개·D-27]
• 기업 지식 베이스 Q&A 에이전트: 벡터 데이터베이스 + 하이브리드 검색 + 다중 테넌트 격리, 기업 및 커뮤니티를 위한 FAQ 및 지식 Q&A 답변에는 소스 추적 기능이 포함되어 있으며 소스 추적에 실패한 질문은 "답변 거부"로 처리됩니다.

7.4 개방형 플랫폼과 통합 계산원

• 개방형 API 게이트웨이: 타사 SaaS 공급자(IDE 공급업체, 보안 도구 공급업체, 데이터 터미널 등)에 암호화된 API 액세스를 제공하고 호출 수, 동시성 및 좌석을 기반으로 권한 및 할당량 관리를 지원하며 청구서 세부정보 내보내기를 제공합니다.
• 혼합 매입: 통합 계산원은 현재 안정적인 통화(USDT/USDC)를 허용합니다. 법정화폐 지불 경로는 필요한 허가를 얻은 후에만 개설할 수 있으며, 인수 주체와 지불 서비스 제공업체가 이를 결정하고 공고합니다. 이에 앞서 통합 계산원은 병행 법정화폐 입금 채널을 제공하지 않습니다. 채널이 개설된 후 임차인은 필요에 따라 법정 통화 채널과 안정적인 통화 채널 중에서 선택할 수 있습니다. 모든 거래는 플랫폼에 의해 균일하게 측정되고 조정됩니다. 법정화폐 취득에는 결제 서비스 및 자금 보관 약정이 포함되며 이는 §2.4와 동일합니다. 필요한 허가를 받기 전에는 해당 업무를 수행하지 않습니다. [취득자 및 결제 서비스 제공자: 확인 후 공시 · D-28]. 온체인 자동 교환 및 드립 배당과 같은 표현은 더 이상 사용되지 않습니다. 온체인 결제는 §8.6 프로토콜 계층의 선택 기능일 뿐이며 규제 평가를 통과한 후 별도로 발표됩니다.

법정화폐 획득 집행 가능성 확보: 획득 주체와 결제 서비스 제공업체가 확정 및 공개되기 전에는 플랫폼에서 법정화폐 예금 채널을 개설하지 않으며 통합 계산원은 안정적인 통화(USDT/USDC) 결제만 허용합니다. 기업 고객을 위한 수집, 환불 및 조정 경로는 라이선스를 취득한 법인과 홍보 페이지에 공개된 해당 서비스 약관의 적용을 받습니다. 인수자의 공개는 기업 고객을 위한 법적 통화 채널을 개설하기 위한 유일한 전제 조건인 공개 폐쇄 루프 추적 양식(§2.2, 부록 C No. D-28)에 포함되었습니다.

7.5 AaaS 정산 및 회계

정산 링크: 사용자 작업 → 에이전트 서비스 → 모델 및 도구 호출 → 컴퓨팅 파워 실행 → 통합 측정 → 수익은 기여도에 따라 에이전트 개발자, 모델 당사자 및 컴퓨팅 파워 당사자 간에 분배됩니다. 회계 규칙은 공개되며 감사를 위해 기록을 내보낼 수 있습니다.

여덟 번째8장 토큰 경제 모델

8.1 설계 원칙

• 실질 소득 우선: 플랫폼 가치의 핵심은 토큰 유통 시장 가치가 아닌 서비스 소득입니다.
• 총액 고정 : A12는 최초 1억개로 발행되며, 추가 발행되지 않습니다.
• 인센티브와 정산의 분리: 서비스 정산은 법정 통화/안정 통화로 이루어집니다. 토큰은 인센티브 발행, 수수료 할인, 거버넌스 제안 등에 사용되며, 임차인은 토큰 보유를 강요받지 않습니다.
• 모든 수학적 계산: 이 장의 각 메커니즘에는 제약 조건과 예가 포함되어 있으며 "공개되지 않은 매개변수"에 의존하는 숨겨진 모순은 없습니다.

8.2 토큰 분배 모델

팀의 0% 예약 인센티브 메커니즘에 대한 설명: 팀은 토큰 주식을 보유하지 않습니다. 이는 팀의 수입이 2차 시장의 토큰 가격과 완전히 분리된다는 것을 의미합니다. 팀의 통화 보유로 인한 매도 압력이 없으며 대리 보유 또는 다크 풀이 없습니다(팀은 온체인 투명성 및 제3자 감사를 통해 확인할 수 있는 자신의 이름으로 실현 가능한 토큰 포지션을 갖고 있지 않습니다). 팀의 실제 수익과 운영 비용은 토큰의 실현이 아닌 운영 주체의 지분 평가 및 서비스 수입에서 비롯됩니다. 이 설계의 비용은 팀 인센티브와 통화 가격 간의 관계가 약화된다는 것입니다. 따라서 수익연계 환매 및 파기(§8.3)를 통해 서비스 소득 증가는 모든 보유자의 공동 이익으로 전환되어 간접적인 합의를 형성합니다.

에어드랍 순환의 분석 및 차등 형태(t는 출시 후 개월 수):

생태 풀의 연간 상한선을 추가한 후의 전체 순환 곡선은 그림 8-1에 나와 있습니다. 공급 확장 속도는 수학적으로 제한되며 환매 및 소각은 실제 순환을 상한선 아래로 더욱 감소시킵니다.

그림 8-1 토큰 공급 출시 모델: 선형 에어드롭 + 연간 생태 풀 상한(환매 및 폐기로 인해 실제 유통량이 낮아짐)

8.3 환매 및 파기 메커니즘

• 파괴 출처: 플랫폼은 이전 분기의 실제 순 서비스 수익의 20%(초기 비율, 거버넌스 제안에 따라 조정 가능, 상한은 30%)를 사용하여 2차 시장에서 A12를 재구매하고 파괴합니다.

순이익의 수준을 감사합니다(자격 조작의 여지 제거):

그 중 GrossRevenue_q는 해당 분기의 총 플랫폼 서비스 수익입니다(모두 CaaS/MaaS/AaaS에서 받은 수익). C_compute_q는 컴퓨팅 파워 조달 및 노드 공유 비용입니다. C_infra_q는 검증 클러스터, 대역폭 등 직접적인 인프라 비용입니다. 인적, 마케팅 및 관리 비용은 공제에 포함되지 않습니다(운영 손실이 "낮은 순이익"으로 전가되는 것을 방지하기 위해). 분기별 3개 데이터는 제3자 회계법인의 검증보고서 발행 후 파기 거래와 함께 공개됩니다. 인증 기관은 다음 기준에 따라 선정됩니다. 4대 국제 네트워크 또는 이에 준하는 규모의 회원사 자격을 보유하고 있으며, Web3 또는 기술 기업 감사 경험이 있으며, 운영 주체 및 관련 당사자와 독립성 문제가 없습니다. 퍼블릭 베타 출시 이전에 위탁을 완료하고 기관명을 공개하는 것을 목표로 하고 있다. [인증기관 : 확인 후 공식 채널을 통해 공지·D-12]

• 하드캡 : 분기별 환매금액은 해당 분기 환매예산의 100%를 초과할 수 없다. 그리고 생태학적 공동 건설 풀의 잔량이 5,000,000 미만인 경우 파기를 중단하고, 환매 부분을 생태 풀에 주입하여 장기 인센티브 풀이 고갈되지 않도록 할 것입니다. (이 임계값은 장기 보호 조항으로, 연간 릴리스 한도는 10,000,000개입니다. 5년 이상의 운영 이후에 발동될 수 있을 것으로 추정됩니다. 퍼블릭 베타 및 초기 운영 단계에서는 "분기별 파기"가 발생합니다. ≤ 현재 분기 환매 예산'이 실제 제약임).
• 계산 예: 특정 연도의 플랫폼 순 서비스 수입이 US$2,000,000이고 해당 연도의 환매 예산이 US$400,000라고 가정합니다. 분기별 실행, 시장 가격 구매 및 온체인 공공 파괴 거래. 파괴의 양은 전적으로 실질 소득에 의해 결정됩니다. 소득이 0이면 파괴가 전혀 없으며 "디플레이션 이야기를 유지하기 위해 준비금을 매도"할 인센티브가 없습니다.

환매 및 유통 공급에 대한 회계 공식. 분기별 환매예산 및 파기수량은 다음과 같이 정의됩니다.

그 중 VWAP_q는 해당 분기의 가중 평균 거래 가격이고, ΔS_q는 해당 분기에 소각된 수량으로, 단일 시점의 가격이 아닌 거래량 가중치를 기준으로 실행되므로 타이밍과 조작의 여지가 없습니다. 파기 거래는 체인을 통해 공지되며, "순이익 바우처 → 환매 거래 → 파기 거래" 3단계 링크를 따라 누구나 독립적으로 확인할 수 있습니다.

순환 공급 곡선. 에어드랍 풀이 온라인화된 후 누적 유통량은 §8.2에 명시된 릴리스 공식을 따릅니다(첫 달에 600만, 이후 매달 100만씩 선형적으로 증가하여 24번째 달에 상한선 3000만 도달). 생태 풀의 "연간 방출량 ≤ 전체의 10%"라는 엄격한 상한(§8.2)을 겹쳐서 순환 디스크의 확장 속도는 수학적으로 제한되며 이는 환매 및 파괴의 수축 효과와 일치합니다. 위 공식을 사용하면 "출시 리듬 - 판매 압력 관리 - 수익 환매"를 독립적으로 계산할 수 있으므로 공개되지 않은 매개변수에 의존하는 숨겨진 모순을 피할 수 있습니다.

8.4 에어드롭 및 포인트

공개 테스트 및 초기 기여는 포인트를 통해 기록되며, 이는 공개 규칙에 따라 토큰 에어드랍으로 전환됩니다. 포인트 획득은 유효 업무량(완료된 작업량, 인증 통과율, 온라인 시간)과 연결되며 단순 계정 수와 분리됩니다. 에어드랍 풀의 20%는 출시 첫 번째 단계에서 잠금 해제되며 나머지 80%는 출시에 대한 집중적인 판매 압력을 피하기 위해 2년 내에 선형적으로 출시됩니다(§8.2 참조). 공개 베타 기간 동안의 구경 약속: 포인트 측정 구경은 출시 후 CU·기간의 정산 구경과 동일합니다. 변환 계수는 조정 가능하고 측정 구경은 변경되지 않으며 변환 원칙은 공개 베타 시작 전에 발표됩니다. 퍼블릭 베타 기간 동안의 결제 통화, 결제 주체 및 결제 주기[공개 전 보충 및 공시 · D-29] (§9.2 "정산 정시율"이란 공시 기간에 따른 전액 결제 비율을 말한다.) USDT 신용 보증금은 고가치 작업의 경우 선택 사항이며(언제든지 상환 가능, 상환 시 평판 재설정이 발생함) 토큰 스테이킹에 의존하지 않는 공개 베타 기간에서 악의 비용에 대한 하한을 제공합니다.

변환 계수 조정에 대한 제약: 포인트 변환 계수 조정에는 세 가지 제약이 적용됩니다. 단일 조정의 진폭은 ±20%를 초과할 수 없습니다. 두 조정 사이의 간격은 90일 이상이어야 합니다. 축소는 30일 전에 공고 페이지에 공지해야 하며 그 이유를 설명해야 합니다. 모든 조정 기록은 점검을 위해 보관되며 조정 절차 및 상한선은 거버넌스 헌장(§8.7)의 공개 범위에 포함되어 "측정 수준이 변하지 않는다"고 해서 "거래소 수준이 일방적으로 하향 조정될 수 있다"는 의미가 되지 않도록 합니다.

최초 변환 계수 결정: 위에서 언급한 삼중 제약 조건(±20%/90일/30일 전)은 "기존 계수의 조정"을 규제합니다. 최초 계수는 다음 규칙에 따라 결정됩니다. 결정 원리: 퍼블릭 베타 기간 동안 적분 측정 구경과 출시 후 CU·시간 정산 구경의 변환 기준에 의해 고정됩니다. 즉, 최초 계수는 "두 구경 아래 단위 유효 작업량의 동등성"을 "CU 시간"의 역수로 하여 구경 전환으로 인해 포인트 보유자의 상대적 위치가 변하지 않도록 합니다. 주제 결정: 운영 주체(플랫폼 측)가 거버넌스 제안을 청취한 후 결정하며, 주요 차이점은 거버넌스 헌장에 규정된 절차에 따라 제출됩니다. 공개 시간: 늦어도 공개 베타(인센티브 활동 포함) 시작 전, §8.5 인센티브 활동 규칙과 동시에 발표되고 거버넌스 헌장(§8.7)의 공개 범위에 포함됩니다. 최초 계수가 결정되면 삼중 제약 조건이 적용되며 해당 결정 기준과 측정 기록은 공개 폐쇄 루프 추적 양식과 함께 보관됩니다.

8.5 공개 베타 인센티브에 대한 설명

공개 테스트 및 에어드랍에는 전제 조건으로 §2.4에 언급된 라이센스 상태 및 증권 법적 의견이 적용됩니다. 구체적인 날짜는 충족된 후 별도로 발표됩니다. 라이선스를 취득하기 전에 인센티브 없이 개방형 네트워크 공개 테스트(토큰 발행을 포함하지 않고 네트워크 및 제품 기능만 확인)를 수행할 수 있습니다. 토큰 에어드랍을 포함한 인센티브 활동은 필요한 라이센스를 취득하고 법적 의견 검토를 완료한 후 시작됩니다. 총 인센티브 예산(인센티브 활동이 시작될 때 실행됨): 30,000,000 A12(즉, 에어드롭 풀의 전체 금액, 분배는 §8.2 릴리스 리듬을 엄격하게 따릅니다. 6,000,000 포인트는 첫 번째 단계에서 잠금 해제되고 나머지 24,000,000 포인트는 2년 내에 선형적으로 릴리스됩니다) + 5 BTC + 900,000 USDT가 모두입니다. 운영 주체(플랫폼 당사자)의 자체 자금으로 부담합니다. 이벤트 규칙, 참여 자격, 총 보상 금액 및 수령 조건은 플랫폼 공식 홈페이지를 통해 공개됩니다. 토큰 보상에는 §8.2의 출시 규칙이 적용됩니다. 법정화폐와 BTC 보상은 운영예산에 포함되며 총 상한액이 있어 '인센티브와 정산의 분리' 원칙에 어긋나지 않습니다.

지리적 규정 준수 경계: 공개 베타 인센티브 및 에어드롭 활동에 참여하려면 KYC 및 제재 목록 심사를 통과해야 합니다(§2.4 참조). 다음 지역의 사용자는 토큰 에어드랍 및 인센티브 배포에 참여할 수 없습니다: UN 안전보장이사회 제재 목록 및 OFAC 제재 지역; 중국 본토(국내 규제 요건에 따라 국내 거주자에게는 어떤 형태의 토큰 인센티브도 발행되지 않습니다) 플랫폼 위험 통제를 통해 식별된 기타 고위험 관할권. 미국 이용자의 참여 자격은 증권법적 의견서가 발행된 후 추후 발표될 예정이다. 유럽 ​​연합(MiCA 규정), 영국(FCA), 싱가포르(MAS), 한국, 일본 및 암호화폐 자산에 대한 명확한 규제 요구 사항이 있는 기타 관할권, 액세스 상태 및 규정 준수 경로는 공식 발표의 적용을 받습니다. 전체 지역 액세스 조건은 공식 웹사이트의 이벤트 규칙에 발표되며 수집 과정에서 두 번 확인됩니다.

8.6 프로토콜 계층

플랫폼은 로드맵의 핵심 기간 동안 자체 퍼블릭 체인을 개발하지 않습니다. 결제 및 인증서 예치의 프로토콜 계층은 성숙한 퍼블릭 체인/L2에 스마트 계약을 배포하여 구현됩니다. 계약은 결제 인증서 예치, 파기 및 홍보, (규제에서 허용하는 경우) 안정적인 통화 결제 채널을 담당합니다. 자체 개발된 합의 체인은 어떤 단계에서도 약속 범위 내에 있지 않습니다. DEX 관련 계획은 두 가지 이유로 취소되었습니다. 첫째, 자체 구축된 온체인 교환 및 시장 조성 기능으로 인해 핵심 R&D 리소스가 분산될 수 있습니다. 이는 §9.1 "리소스는 일정 관리 플랫폼, 콘솔, MaaS 및 AaaS의 4가지 제품 라인에 중점을 둡니다"의 원칙에 위배됩니다. 둘째, DEX는 여러 관할 구역의 분산 거래 라이선스에 대한 불확실성을 포함하며 규정 준수 경로가 명확해질 때까지 레이아웃이 없습니다. 토큰 유동성은 공개적이고 투명한 시장 관행에 따라 전통적인 방식으로 전문 시장 조성 기관에 의해 제공됩니다. 초기 유동성은 §8.2 유동성 및 시장 조성 풀(10%)에서 주입됩니다. 구체적인 마켓조성기관명 및 협력조건은 온라인 오픈 1주일 전 공식홈페이지를 통해 공지합니다. [마켓조성기관 : 확인 후 온라인 오픈 1주일 전 공지·D-30]

폐기 공개 계약의 참조 인터페이스는 다음과 같습니다(최종 구현이 아닌 4단계 결과물이 표시됩니다. Ethereum EIP 표준 인터페이스 및 OpenZeppelin 감사 관행에서 교훈을 얻습니다).

수익 보관 및 슬래싱을 위한 참조 계약 인터페이스(파기 계약과 동일한 프로토콜 계층 4단계 전달 가능 표시에 속하며 확정되지 않았습니다. "수익 지연 릴리스 + 조건부 슬래싱" 구조는 Filecoin의 채굴자 베스팅/슬래싱 계약과 출처가 동일합니다):

보안 감사 계획: 4단계 배포에 들어가기 전에 위에 언급된 계약은 독립적인 제3자 보안 기관의 완전한 감사를 완료해야 합니다. 선택 기준은 §8.3 보증 기관과 일치합니다(국제 네트워크 회원사이거나 Web3 계약 감사 자격이 있고 운영 기관과 독립 문제가 없음). 감사 보고서 전문이 공개됩니다. 감사가 통과되기 전에 계약은 메인 네트워크를 배포하지 않으며 실제 자금 보관 및 몰수 프로세스에 연결되지 않습니다.

8.7 거버넌스

플랫폼 운영 결정(일정 전략, 가격 책정, 위험 통제 규칙)은 운영 주체의 책임입니다. 생태 거버넌스는 A12 글로벌 거버넌스 DAO를 통해 수행됩니다.

DAO는 커뮤니티 기여자, 업계 창작자, 기술 기여자 및 뛰어난 직원에게 열려 있습니다. 글로벌 거버넌스 좌석은 총 300개이며, 그 중 40개가 1단계에 개설됩니다(공식 모집 공고에 따라 다름).

거버넌스 메커니즘(설계 목표 범위, 매개변수는 거버넌스 헌장 발표에 따름): 회원은 "자체 추천 신청 + 커뮤니티 검토 발표"를 통해 선정되며, 기간은 12개월이며, 1회 재선될 수 있습니다. 제안은 투표되기 전에 회원의 10% 이상의 서명을 받아야 합니다. 일반 사항은 단순 다수결로 통과되고 법정 참여율은 25% 이상입니다. 분배 매개변수 조정, 벌금 및 몰수 규칙 변경과 같은 주요 문제는 3분의 2 이상의 찬성을 얻어야 합니다. 결의안은 운영업체가 기한 내에 이행해야 하며, 집행 결과는 공식 홈페이지에 발표됩니다. 이유 없이 3회 연속 투표에 참여하지 않거나 이익회피 규정을 위반한 회원은 제명됩니다. 기술 매체는 오프체인 스냅샷 투표 + 온체인 홍보 및 인증서 저장을 사용합니다(§8.6 프로토콜 레이어와 일치하며 자체 구축된 퍼블릭 체인에 의존하지 않음).

DAO 회원 권리:

• 생태학적 제안, 투표 및 주요 이벤트 거버넌스에 참여합니다.
• 플랫폼 규칙 및 관련 거버넌스 결정에 참여합니다.
• 생태학적 기여에 따라 상응하는 인센티브를 얻습니다.
• 특별한 포인트와 관련 생태권을 누리세요.
• A12 글로벌 생태건설 참여를 우선으로 합니다.

DAO와 운영 주체 간의 권리와 책임의 경계("중앙 집중식 운영 대 DAO"의 긴장 제거): DAO는 플랫폼 운영 계층이 아닌 생태학적 거버넌스 계층입니다. 생태학적 문제는 실질적으로 DAO가 결정하는 반면, 플랫폼 운영 문제는 운영 주체의 책임으로 DAO의 권고 사항을 수용합니다. 경계는 다음과 같습니다.

이 구분은 §2.1 "중앙 집중식 운영 + 분산 실행"의 위치와 일치합니다. 플랫폼 운영에 대한 책임 주체는 독특하고 명확하며("아무것도 말하지 않음"이라는 장식적인 거버넌스를 피하기 위해) 생태 자원의 배포 권한은 본질적으로 DAO에 넘겨집니다("유사 분산화"에 대한 인식을 피하기 위해).

거버넌스 방지 방지 메커니즘(설계 목표 범위, 세부 사항은 거버넌스 헌장 발표에 따름): ① 제안의 이중 임계값 - 제안은 단일 저비용 시트가 직렬로 연결되는 것을 방지하기 위해 의석의 공동 서명 ≥ 10% 및 제안자의 최소 통화 보유/평판 임계값을 충족해야 합니다. ② 단일제안금액 상한 - 어느 생태풀에서든 제안에 사용할 수 있는 금액 ≤ 생태풀 미발행 잔액의 5% 이하이며, 큰 사항은 별도로 투표한다. ③ 이익 회피 - 제안자 및 그 계열사는 자신에게 이익이 되는 제안에 대해서는 투표할 수 없습니다. 위반자의 제안은 무효화되고 상장폐지 절차가 시작됩니다(거버넌스 헌장에 "이자 회피"의 정의가 명시되어 있습니다). ④ 긴급 정지 - 운영주체는 불법적이거나 악의적인 제안에 대하여 최대 14일 동안 집행을 정지하고 그 사유를 공지할 수 있습니다. 제한 시간 이후에도 복원되지 않으면 DAO 전체 투표에 제출해야 합니다. ⑤ 동일한 표준 인증 - 생태풀 발행 및 §8.3 환매 및 폐기에는 동일한 제3자 회계보증 및 공개 기준이 적용됩니다. ⑥ 1단계 목록이 먼저 진행됩니다. 선정 기준과 1단계 40석의 선출 목록은 DAO 출시 전에 발표됩니다.

제구9장 기술 로드맵

9.1 자원중심 원칙

핵심 리소스는 스케줄링 플랫폼(Layer 1/2), 테넌트 콘솔 및 샌드박스 런타임, 모델 서비스(MaaS, 첫 번째 수직 모델 파이프라인 포함), AaaS 도구 체인(오케스트레이션 캔버스 + 개발자 도구 + 사전 설정된 에이전트)의 네 가지 제품 라인에 집중되어 있습니다. 나머지 방향(크로스 벤더 심층 적응, 프로토콜 계층 심화, 보다 수직적인 산업 모델)은 장기적인 실험 항목이며 로드맵에 진입하기 전에 이전 단계의 종료 기준을 통과해야 합니다.

9.2 단계별 로드맵(종료 기준 포함)

9.2.1 승인 보고서 사양(고정 부속품)

각 단계가 끝나면 승인 보고서가 공개됩니다. 보고서는 "9개의 고정 필드 + 단계에 대한 추가 필드"라는 두 부분으로 구성됩니다. 고정 필드는 단계에 따라 조정되지 않습니다. ① 노드 규모(리소스 계층으로 나눈 등록/활성/표준 노드 수, 교차 ID 중복 제거 통계 포함 - 선언된 장치 수/중복 제거/차이 후 장치 수, 전역적으로 고유하고 §4.5의 일련 번호와 상호 배타적 대응) ② 작업량(당기 총 작업수 및 작업 유형별 분포) ③ 검증 합격률(§4.2 L2 및 L4 검토 구경 통계 기준) ④ 스케줄링 성공률(최초 스케줄링 성공 비율, 탄력적 최선 노력과 전용 보증 모드 구별) ⑤ 인스턴스 콜드 스타트 ​​P50/P95; ⑥ TTFT P50/P95(≤ 8K 컨텍스트 기어, 32K 긴 컨텍스트 기어 단일 열); 7 GPU 페이로드 속도(연속 일괄 처리 장비, P50 사용) ⑧ 사고목록(사고수준, 영향기간, 근본원인 및 시정항목) ⑩ 부적합 사항 및 사유(이 단계의 Go/No-Go 기준을 하나씩 비교하고, 편차 값과 귀인을 나열) 단계 추가 필드는 출시 공지의 각 단계별로 나열되며 추가만 가능하고 축소할 수는 없습니다. 고정 필드는 삭제하거나 교체할 수 없습니다. 첫 번째 승인 보고서는 0단계 종료 후 7일 이내에, 그리고 각 후속 단계 종료 후 7일 이내에 발표됩니다. 다음 단계로 진입하기 위한 유일한 조건은 이전 단계의 모든 기준이 충족되고 승인 보고서가 공개된다는 것입니다(달력 날짜는 약속이 아님). 이 독점권 선언은 자금 조달 진행 상황, 시장 창구 또는 인력 배치로 인해 예외가 적용되지 않습니다.

9.3 첨단 기술 전망(연구 지평선)

A12의 장기 청사진은 한 문장으로 요약할 수 있습니다. 전 세계의 모든 유휴 GPU가 신뢰할 수 있는 통합 인터페이스를 통해 AI 가치 사슬에 참여하고 지능형 에이전트가 컴퓨팅 성능의 기본 소비자가 되도록 합니다. "CaaS → MaaS → AaaS"라는 수직적 가치 사슬을 따라 기술 진화는 세 가지 지평으로 나누어집니다.

포커스 노트: 이 장은 의도적으로 플랫폼의 핵심 기능(스케줄링, 추론, 에이전트 실행)과 직접 관련된 지침만 유지합니다. 연합 학습, 차등 개인 정보 보호, 동형 암호화, 모델 워터마킹, 탄소 인식 스케줄링, WASM 샌드박스, 포스트 양자 암호화 등과 같은 보다 장기적인 또는 교차 필드 방향은 이 기사에서 논의되지 않으며 수직 산업이 확장됨에 따라 후속 기술 블로그에서 별도로 논의될 것입니다. 이는 "모든 것을 하고 싶지만 깊이 있는 작업은 수행하지 않습니다"라는 인식을 피하기 위한 것입니다.

Horizon 1: 컴퓨팅 파워 계층(현재 → 2027) - 분산 컴퓨팅 파워를 "신뢰할 수 있고, 이용 가능하며, 예약 가능"하게 만듭니다.

Horizon 2: 모델 및 실행 계층(2027 → 2028) - 최첨단 모델 효율성과 분산 실행을 긴밀하게 결합합니다.

Horizon 3: 에이전트 및 경제 계층(2028+) - 에이전트 경제를 위한 결제 인프라입니다.

에이전트가 컴퓨팅 성능의 주요 소비자가 되면 일정 관리 플랫폼은 "사람을 위한 클라우드"에서 "에이전트를 위한 컴퓨팅 성능 시장"으로 발전할 것입니다.

• MCP/A2A 도구 및 협업 프로토콜(§7.1 참조): 에이전트는 표준 프로토콜을 사용하여 도구를 검색하고 작업을 위임하며 상호 인식 상태를 확인합니다.
• 테스트 시간 계산: CoT/ToT/다중 샘플링 투표와 같은 전략을 통해 모델은 어려운 문제에 대해 "더 많이 생각"하고 비용과 품질을 교환할 수 있습니다. 스케줄링 플랫폼은 이를 기반으로 "빠른/표준/깊이"의 3단계 추론 서비스를 제공합니다.
• 에이전트 자율 결제: 에이전트는 사전 설정된 예산 및 전략을 사용하여 독립적으로 컴퓨팅 성능(입찰, 가격 잠금, 패키지)을 구매하고 결제 기록을 감사할 수 있습니다. 이는 §8.6의 프로토콜 계층의 스마트 계약 결제 기능과 연결됩니다.
• 컴퓨팅 파워 팩터의 시장화: 평판, 계층, SLA 및 실시간 공급 및 수요가 함께 개방형 컴퓨팅 파워 가격 신호를 형성하여 리소스 가격 책정이 "목록 시스템"에서 "시장 기반 매칭"으로 발전할 수 있도록 합니다.

위에서 언급한 Horizons 1과 2는 엔지니어링 발전 경로인 반면 Horizon 3는 방향성 비전입니다. 세 가지 사이의 관계는 계층별 의존성과 단계별 검증입니다. 신뢰할 수 있는 컴퓨팅 성능 계층이 없으면 효율적인 실행 계층도 없고, 실행 계층의 규모가 없으면 지능형 경제 계층에 대한 합의 요구 사항도 없을 것입니다. 이 섹션 전체에는 10장의 미래 예측 진술이 적용됩니다.

제십10장 위험 요소 및 면책 조항

• 실행 위험: 플랫폼 제공은 핵심 엔지니어링 팀의 가용성과 안정성에 따라 달라집니다. 팀 공개 정보는 §2.2를 참조하세요. 독자는 완전한 공개에 앞서 관련 위험을 스스로 평가할 책임이 있습니다. 완화: 단계적 로드맵은 정량적 Go/No-Go 종료 기준을 설정하고 각 단계에 대한 승인 보고서는 §9.2.1 "승인 보고서 사양"(단계에 대한 9개의 고정 필드 + 추가 필드, 단계 종료 후 7일 이내에 릴리스됨)에 따라 게시됩니다.
• 기술적 위험: 컨테이너 격리로 모든 탈출 위험을 제거할 수는 없습니다. 검증 시스템은 초과 예약을 절대적으로 방지할 수 없으며 경제적, 운영적 수단을 통해서만 억제할 수 있습니다. 공급업체 간 적응의 구축 기간에 불확실성이 있습니다. 수직 모델 파이프라인의 코퍼스 구성 및 훈련 효과에는 불확실성이 있습니다. 완화: 컨테이너 격리의 3단계 보호 + 사용 검토 + 남용 보상 기금(§4.7 참조) 초과 예약을 억제하기 위한 SLA 기본 및 백업 중복성 및 평판 허용(§5.3, §4.5 참조).
• 시장 위험: 컴퓨팅 전력 가격의 변동, 클라우드 공급업체 간의 경쟁, AI 로드 구조의 변화는 플랫폼 수익 가정에 영향을 미칠 수 있습니다. 완화: 이중 경로 스케줄링은 작업 특성에 따라 최적의 경로를 선택하고 수익 구조는 CaaS/MaaS/AaaS의 3개 계층을 포함하여 단일 시장에 대한 의존도를 줄입니다(§5.2, §3.1 참조).
• 규제 위험: 디지털 자산 관련 활동은 관할권마다 다른 요구 사항에 직면하며 토큰의 사용 가능한 기능은 감독을 통해 조정될 수 있습니다. 하이브리드 획득 및 프로토콜 계층 기능은 규제 평가를 받습니다. 완화: 관할권별 액세스 매트릭스 및 수집 프로세스에 대한 2차 검증(§8.5 참조) 라이센스와 관련된 사업은 라이센스를 취득하기 전에는 수행되지 않습니다(§2.4 참조).
• 스마트 계약 위험: 스마트 계약에는 발견되지 않은 취약점(예: 재진입, 정수 오버플로, 권한 구성 오류)이 있을 수 있습니다. 제3자 보안 감사가 완료되기 전에는 계약 상호작용에서 자금 손실이 발생할 위험이 있습니다. 완화: 계약에는 결제 바우처를 예치하고 파기하는 프로토콜 계층의 선택적 기능만 있습니다(§8.6 참조). 배포하기 전에 독립적인 제3자 감사를 통과하고 감사 보고서의 전체 텍스트를 공개해야 합니다. 감사 전에는 메인 네트워크로 이동하지 않으며 실제 자금이 연결되지 않습니다.
• 미래 예측 진술: 본 백서에 포함된 모든 지표는 설계 목표이며 모든 로드맵은 계획된 것이며 수익 약속을 구성하지 않습니다. 실제 결과는 계획된 결과와 크게 다를 수 있습니다.
• 면책조항: 본 백서는 투자 조언, 증권 발행 문서 또는 법률 자문을 구성하지 않습니다. 제3자 상표와 관련된 권리는 해당 권리 보유자에게 귀속됩니다.

충수부록 A 용어집

충수부록 B 차트 색인

그림: 그림 3-1 4계층 아키텍처 계층 다이어그램(§3.2); 그림 4-1 5단계 검증 시스템(§4.2); 그림 5-1 이중 경로 오프로드(§5.2); 그림 5-2 작업 수명주기 상태 머신(§5.5); 그림 6-1 KV 캐시 용량 모델(§6.4); 그림 8-1 공급 릴리스 모델(§8.2).

주요 표: 의무 공개 목록(§2.2); 폐쇄 루프 임계 경로 공개(§2.2) 8개 항목의 법인정보 공개현황표(§2.2) 약속된 지출 및 자원 보장 표(§2.5) 설계 참조 시스템(§3.4) 자원 계층 스케줄링 제약(§5.4) 고정된 승인 보고서 필드(§9.2.1) DAO 운영 주체의 권리와 책임 경계(§8.7) 토큰 할당 모델(§8.2) 환매 및 폐기 매개변수(§8.3) 위험요소(제10장) 용어집(부록 A) 공개 폐쇄 루프 추적 테이블(부록 C) 차트 매개변수 표(부록 D)

충수부록 C 공개 폐쇄 루프 추적 양식(D-01 ~ D-30)

이 표는 총 30개 항목으로 구성된 "공개 폐쇄 루프 추적 양식"의 전문으로, §2.2 공개 목록 표의 "번호" 열에 한 줄씩 대응하며, 본 버전의 전문에서 보완해야 할 모든 사항을 다루고 있습니다. 운영 주체 등록 정보(§2.2의 첫 번째 행)가 제공되고 공개적으로 검증될 수 있으며 보완할 수를 차지하지 않습니다. 넘버링 구경: 이전 버전에는 21개의 숫자가 명시되어 있지만 실제로는 전문에 30개의 표시가 추가됩니다(9개의 등록 누락). 이번 판에서는 30개의 마크를 D-01부터 D-30까지 하나씩 등록했는데, 이는 새로운 약속이 아닌 보충 등록이다. 본 판의 본문 표시는 26개로 수렴되었으며, 다른 장에서 동일한 내용이 반복적으로 등록된 경우에는 동일한 번호로 통합되었습니다. 분할 및 병합은 약속의 범위를 변경하지 않습니다. 번호 부여 세분성: 독립적으로 마감되고 외부에서 독립적으로 검증될 수 있는 데이터 포인트는 독립적인 번호로 분리됩니다. 예를 들어 "재무상태 공개"는 데이터 출처가 다르고 규모 범위(D-17), 투자 계정(D-18) 및 12개월 자금 격차(D-19)의 상업적 민감도가 다르기 때문에 분할되고 3개는 별도로 마감될 수 있습니다. 동일한 공개 행위에 대한 여러 표시에는 반복되는 숫자가 없습니다. 현장 구경: 요구 사항 양식은 문제가 외부 세계에 제시되는 방식을 나타냅니다. 현재 상황은 "보완/보완, 실증/공표"의 3단계로 구분됩니다. 약정일은 목표 약정일(비계약 약정)로 운영기관 담당자의 승인 후 효력이 발생됩니다. 리듬 구경: 약속 날짜는 평가 노드이며 기한이 지나면 기한이 지난 처리 규칙이 트리거됩니다. 주간 업데이트는 프로세스 공개이며 약속 날짜가 우선합니다. 홍보 링크: 이 열은 홍보 페이지의 기준점을 제공합니다. 루트 주소 전환 기간은 aeliontwelve.vercel.app/disclosure입니다(§2.2 이중 드롭인 포인트 참조). 전체 주소 = 루트 주소 + 앵커 포인트; 공식 홈페이지 메인 도메인명이 활성화된 후 72시간 이내에 본 칼럼과 홍보 페이지가 동시에 공식 도메인명으로 업데이트되며 이전 링크는 점프 및 아카이브를 유지합니다. 공지 페이지의 첫 번째 버전(이 표에 있는 30개 항목의 초기 상태 포함)은 늦어도 2026-09-21까지 온라인에 게시될 예정이며, 이후 매주 월요일(UTC)에 업데이트되며 모든 과거 버전이 유지됩니다. 담당직위 : 과목정보 8개 항목은 §2.2의 8개 항목 상태표를 참조한다. 나머지 사항은 운영 주체를 담당하는 해당 기능 담당자가 부담합니다. 기한이 지난 처리: 기한이 지났고 종료되지 않은 문제가 있는 경우 §2.2의 8개 항목 표 아래 규칙이 적용됩니다(이유와 개정 날짜는 영업일 기준 5일 이내에 명시되며, 2회 연속 기한이 있는 경우 수정 지침이 게시되어야 함). 이 테이블은 동시에 업데이트되며 모든 기록 버전이 유지됩니다.

충수부록 D 차트 매개변수 표(그림 5-1 / 그림 6-1)

이 부록은 추적 번호 D-21 및 D-22(상태: 보완 및 검증 보류)에 해당하는 그림 5-1 및 그림 6-1의 재계산 매개변수 표를 제공합니다. 지원 경로: 표의 값은 §5.2 Hockney 통신 모델, Roofline 처리량 추정 및 §6.4 M_KV 공식에 따라 얻은 설계 추정치입니다. 지원 방법은 0단계 내부 테스트 중 플랫폼 검증 클러스터의 5가지 유형의 작업과 2가지 모델 수준에 대한 실제 측정 및 재계산입니다. (50~100개의 NVIDIA 스택 노드가 초대됩니다. §9.2 참조) - 실제 측정 T_comm/T_compute/Video 메모리 사용량은 이 테이블과 항목별로 비교되며, 실제 측정 기록은 공고 페이지에 보관됩니다. 제3자도 이 부록의 매개변수에 따라 독립적으로 다시 계산하고 비교할 수 있습니다. 버전 식별: 두 매개변수 테이블은 버전 관리에 따라 유지됩니다. 각 업데이트에는 버전 번호(예: D-1.1/D-2.1)와 날짜 스탬프가 표시되어 있습니다. 모든 기록 버전은 쉽게 참조하고 비교할 수 있도록 /archive 아카이브에 보관됩니다. 0단계에서 측정된 샘플이 확장됨에 따라 매개변수 범위가 분기별로 검토되고 업데이트됩니다. 표 D-1은 또한 T_comm(대역폭 수준에 따라) 및 T_compute(하드웨어 기어 가정 포함)라는 두 개의 열을 제공하므로 α_comm = T_comm ¼ T_compute를 단계별로 다시 계산할 수 있으며 더 이상 비율만 제공하고 분모는 제공하지 않습니다.

표 D-1 그림 5-1 매개변수 표: α_comm 추정 간격(대역폭별 bin), T_comm/T_compute 값 및 분포 귀속(D-21)

표 D-2 그림 6-1 매개변수 표: 모델 기어(7B/70B 레벨), GQA 구성 및 KV 메모리 사용량(D-22)

참고: 두 MHA 행은 모두 "GQA 압축 없음"을 비교하기 위한 기준 행입니다. 압축 전과 후의 동일한 값은 예상되는 동작입니다. 페이징 메커니즘은 비디오 메모리 조각만 제거하고 압축을 수행하지 않으므로 페이징이 효과가 없다고 오해해서는 안 됩니다. 압축 효과는 기준 행에 비해 GQA 행의 비디오 메모리 감소에 반영됩니다(7B 수준 17.2 → 4.3GB, 70B 수준 85.9 → 10.7GB). 레벨 70B는 §6.4의 텍스트 예와 동일한 구성입니다(80개 레이어, H_kv = 8, FP16 단일 시퀀스 ≒ 10.7GB). 레벨 7B는 단일 카드 동시성 시나리오를 위한 일반적인 장비입니다. 두 수준은 각각 "압축 효과 비교"와 "단일 카드로 동시성을 처리할 수 있음"이라는 두 가지 재계산 목표에 해당합니다.

참조하다참고자료

다음은 본 기사에 인용된 주요 학술 논문, 기술 표준 및 공식 문서입니다. 본문의 메커니즘 이름과 공식 구경은 위에서 언급한 소스를 기반으로 합니다. "설계 목표"라고 표시된 지표는 이 기사에서 자체 정의되었으며 확인되지 않은 타사 측정 데이터를 인용하지 않습니다. 온라인 소스의 접근 날짜가 2026-09-14로 통일되었습니다.

학술 논문

• Hoffmann et al., 컴퓨팅 최적의 대형 언어 모델 훈련(Chinchilla Scaling Law, §6.2 참조), 2022, arxiv.org/abs/2203.15556
• Rafailov 외, 직접 선호 최적화: 언어 모델은 비밀리에 보상 모델입니다(DPO, §6.2 참조), NeurIPS 2023, arxiv.org/abs/2305.18290
• Hu et al., LoRA: Low-Rank Adaptation of Large Language Models，2021，arxiv.org/abs/2106.09685
• Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs，2023，arxiv.org/abs/2305.14314
• Leviathan 외, 추측 디코딩을 통한 변환기의 빠른 추론(§6.4 참조), ICML 2023, arxiv.org/abs/2211.17192
• Ainslie et al., GQA: 다중 헤드 체크포인트에서 일반화된 다중 쿼리 변환기 언어 모델 훈련(§6.4 참조), 2023, arxiv.org/abs/2305.13245
• Rajbhandari et al., ZeRO: Memory Optimizations Toward Training Trillion Parameter Models，SC 2020，arxiv.org/abs/1910.02054
• Shazeer 외, 엄청나게 큰 신경망: 희소하게 문이 지정된 전문가 혼합 계층(MoE, §6.4, §9.3 참조), ICLR 2017, arxiv.org/abs/1701.06538
• Micikevicius 외, 딥 러닝을 위한 FP8 형식(§9.3 참조), NVIDIA, 2022, arxiv.org/abs/2209.05433
• Dao 외, FlashAttention: IO 인식을 통한 빠르고 메모리 효율적인 정확한 주의(§9.3 참조), NeurIPS 2022, arxiv.org/abs/2205.14135
• Shah, Bikshandi, Zhang 외, FlashAttention-3: 비동기 및 낮은 정밀도를 사용한 빠르고 정확한 주의(FlashAttention-3, §9.3 참조), 2024, arxiv.org/abs/2407.08608
• Williams, Waterman & Patterson, Roofline: 멀티코어 아키텍처를 위한 통찰력 있는 시각적 성능 모델(§5.2, §6.4 참조), ACM 통신, 2009, doi.org/10.1145/1506609.1506623
• Kahn, A.B., 대규모 네트워크의 위상적 정렬(§7.1 참조), ACM 통신, 5(11): 558–562, 1962, doi.org/10.1145/368996.369025
• Erlang, A.K., 자동 전화 교환의 유의성 확률 이론의 일부 문제 해결(M/M/c 및 Erlang C 대기열 모델, §6.3 참조), Elektroteknikeren, 13, 1917

기술 표준 및 공식 문서

• ERC-20 토큰 표준, 이더리움 개선 제안(§8.6 참조)
• OpenZeppelin 계약 보안 규칙(SafeERC20/Math)(§8.6 참조)
• Solidity 공식 문서(§8.6 참조)
• MCP(모델 컨텍스트 프로토콜) 사양(§7.1, §9.3 참조)
• NIST 포스트퀀텀 암호화폐(PQC) 표준화 프로젝트(§9.3 참조)
• WebAssembly(WASM) 및 eBPF(§4.7, §9.3 참조)

디자인 참조 프레임

• 이더리움 백서——계정 시스템 및 가스 측정 참조(§3.4 참조)
• Filecoin 백서 - 담보 몰수 및 보관 증명 참조(§3.4, §4.5 참조)