AI x Crypto Systems 공지: 이 기사는 편집 보조로서 AI의 도움을 받아 작성되었습니다. 아이디어, 사실, 코드, 출처 및 결론은 사람이 검토했습니다.

AI x Crypto Systems 공지: 이 기사는 기술적 설명이며 투자 조언이 아닙니다. AI x Crypto Systems는 어떠한 암호자산(cryptoasset)의 매수, 매도 또는 보유를 권장하지 않습니다.

DePIN GPU 시장

유용한 DePIN GPU 시장에 대한 질문은 데모가 실패한 이후에 시작됩니다. 개발자가 광고된 A100을 대여하고, 마켓플레이스(marketplace)는 작업자(worker)가 검증되었다고 말하며, 결제 경로(payment path)가 준비되었음에도 불구하고, 모델 작업(model job)이 출력 해시(output hash)가 생성되기도 전에 중단되는 상황입니다. 그 실패한 실행은 성공 사례보다 더 많은 것을 드러냅니다. 왜냐하면 분쟁(dispute)이 발생하면 모든 주장이 공급자 주장, 용량 확인(capacity check), 실행 추적(execution trace), 출력 결과물(output artifact) 또는 정산(settlement)이라는 좁은 경로로 강제되기 때문입니다. DePIN GPU 시장의 영수증은 그 경로를 가시화할 때 유용합니다.

사례 파일 (Case File)

DePIN GPU 시장의 평가는 슬로건이 아닌 사례 파일(case file)에서 시작되어야 합니다. 이 기사의 사례 파일은 의도적으로 작게 구성되었습니다: 08:03에 견적 수락, 08:06에 용량 확인 통과, 08:09에 컨테이너(container) 시작, 08:11에 CUDA 메모리 오류, 08:15에 결제 보류. 핵심은 특정 네트워크가 이런 식으로 작동한다는 것이 아니라, 모든 마켓플레이스에는 지루한 고객 지원 티켓(support ticket)에서도 살아남을 수 있는 기록이 필요하다는 점입니다. DePIN GPU 시장의 품질은 실패한 작업이 해당 실패를 올바른 계층(layer)에 할당할 수 있을 만큼 충분한 증거를 가지고 있을 때 나타납니다.

해당 케이스 파일(case file)은 흔히 발생하는 과도한 주장(overclaim)을 방지합니다. io.net의 Proof of Work 문서는 실제적이고 사용 가능한 리소스를 확인하는 데 도움이 되는 검사를 포함하여, 분산된 CPU/GPU 리소스에 대한 시간당 검증을 설명합니다. 그러한 증거는 가치가 있지만, 통과된 용량 확인(capacity check)이 완료된 추론 작업(inference job)과 동일한 것은 아닙니다. DePIN GPU 시장의 영수증은 "작업자(worker)가 실제처럼 보였다"와 "구매자가 선언한 컨테이너가 선언된 출력을 생성했다" 사이의 차이를 반드시 보존해야 합니다.

Quoted Machine (견적 기반 머신)

DePIN GPU 시장의 견적(quote)은 실행 전의 증거입니다. 견적에는 GPU 모델, 메모리, 지역, 드라이버 제품군, 대여 시간대, 제공자 신원 및 가격을 명시할 수 있지만, 견적은 여전히 실행 전의 약속일 뿐입니다. Akash는 자사의 네트워크를 탈중앙화된 컴퓨팅 마켓플레이스로 포지셔닝하며 AI 인프라를 위한 GPU 공급을 홍보합니다. 이는 마켓플레이스의 맥락(context)이지, 워크로드 영수증(workload receipt)이 아닙니다. DePIN GPU 시장의 구매자는 견적을 저장해야 하는데, 그 이유는 견적이 나중에 증거가 무엇을 확인해야 하는지를 정의하기 때문입니다.

견적이 수행된 작업 증명(proof of work)으로 흘러가도록 허용해서는 안 됩니다. 구매자가 "A100 추론을 위해 비용을 지불했다"라고 말하고 판매자가 마켓플레이스 리스팅(listing)으로만 답변할 때 지원 분쟁(support dispute)은 복잡해집니다. 리스팅은 사실일 수 있지만, 실제 실행은 여전히 실패할 수 있습니다. 따라서 DePIN GPU 시장의 영수증은 견적 필드(quote fields)를 용량 필드(capacity fields), 실행 필드(execution fields) 및 출력 필드(output fields)와 별도로 저장해야 합니다. 만약 영수증이 proof라는 이름의 단일 필드를 사용한다면, 그 영수증은 이미 분쟁을 숨기고 있는 것입니다.

Capacity Check (용량 확인)

DePIN GPU Market의 용량 확인 (Capacity Check)은 가짜 또는 잘못 보고된 공급이 실제 위험이기 때문에 매우 유용합니다. io.net은 자사의 검증 프로세스가 공급자가 시뮬레이션되거나 가상화된 환경이 아닌, 실제 작동하는 CPU/GPU 리소스를 제공하는지 확인하기 위한 것이라고 밝히고 있으며, 해당 페이지에서는 장치가 사용 가능할 때 VRAM과 같은 리소스가 완전히 사용 가능한 상태여야 한다고 명시하고 있습니다. 이는 공급 계층 (supply layer)에서 테스트해야 할 올바른 주장입니다. DePIN GPU Market의 용량 확인은 구매자를 유령 작업자 (phantom worker)로부터 보호합니다.

하지만 동일한 용량 확인만으로는 AI 작업 (AI job)의 미결 문제를 해결할 수 없습니다. 검증된 작업자라 할지라도 구매자의 워크로드 (workload)가 시작된 이후에 드라이버 불일치 (driver mismatch), 충돌하는 프로세스 (conflicting process), 컨테이너 풀링 실패 (container pull failure), 또는 메모리 부족 (out-of-memory) 상태가 발생할 수 있기 때문입니다. Gensyn은 일관된 ML 실행, 신뢰가 필요 없는 검증 (trustless verification), 피어 투 피어 (peer-to-peer) 통신, 그리고 탈중앙화된 조정 (decentralized coordination)을 중심으로 프로토콜을 설명합니다. 이는 컴퓨팅 시스템에 여러 계층이 필요하다는 점을 상기시켜 주는 유용한 사례입니다. DePIN GPU Market의 용량 증거는 용량 상태를 증명할 뿐, 모델 출력 (model output)을 증명하는 것은 아닙니다.

Run Gap (실행 간극)

DePIN GPU Market의 실패 사례는 영수증에 실행 간극 (run gap)이 포함될 때 비로소 디버깅이 가능해집니다. 실행 간극이란 "작업자가 확인을 통과함"과 "출력 해시 (output hash)가 존재함" 사이의 공간을 의미합니다. 많은 화려한 컴퓨팅 사례들은 성공한 스크린샷에는 이것이 필요하지 않기 때문에 이 공간을 건너뜁니다. 하지만 실패한 AI 작업에는 이것이 반드시 필요합니다. 영수증에는 컨테이너 이미지 다이제스트 (container image digest), 명령 (command), 모델 해시 (model hash), 입력 매니페스트 해시 (input manifest hash), 시작 시간, 실패 시간, stderr 클래스, 리소스 카운터 (resource counters), 그리고 출력 파일이 작성되었는지 여부가 표시되어야 합니다.

이 실행 간극이야말로 일반적인 설명보다 실질적인 결과물 (artifact)이 힘을 발휘하는 지점입니다:

{
  "quote": {
    "gpu": "A100-80GB",
...

OOM Line (메모리 부족 라인)

OOM Line (메모리 부족 라인)

DePIN GPU 시장의 분쟁 언어는 자동화가 가능할 정도로 간결해야 합니다. 실패 사례에서 가장 유용한 한 줄은 긴 문단이 아니라, capacity=pass execution=fail output=none settlement=hold reason=container_oom과 같은 형태입니다. 이 한 줄은 판매자가 전체 실행을 성공으로 간주하는 것을 방지하며, 구매자가 작업자(worker)가 가짜였다고 주장하는 것을 방지합니다. 이는 용량 증명(capacity evidence)은 통과했으나 워크로드(workload)는 통과하지 못했으며, 출력 품질(output quality)은 테스트 가능한 단계에 도달하지 못했음을 의미합니다.

이 간결한 문장이 중요한 이유는 다음과 같습니다. 영수증은 작업자가 용량 증명을 통과했다는 점과 선언된 실행이 실행 오류(execution error)로 실패했다는 점을 증명할 뿐, 모델의 답변이 좋았는지 나빴는지를 증명하는 것이 아닙니다. DePIN GPU 시장은 약속(commitments), 에스크로(escrow), 결제(settlement)를 위해 암호화 인프라를 사용할 수 있지만, 온체인 약속(chain commitment)이 컨테이너가 종료된 이후에 출력 해시(output hash)를 만들어낼 수는 없습니다. OOM 라인은 화려하지는 않지만, 비용 지불, 재시도(retries), 또는 평판 페널티(reputation penalties)를 논하기 전에 지원 팀이 반드시 필요로 하는 핵심 정보입니다.

Seller Packet (판매자 패킷)

DePIN GPU 시장의 판매자는 자신이 실제로 수행한 부분을 증명할 수 있는 패킷(packet)이 필요합니다. 판매자 패킷에는 견적 ID(quote ID), 작업자 신원(worker identity), 용량 확인 결과(capacity-check result), 예약 수락(reservation acceptance), 컨테이너 풀 로그(container-pull log), 시작 타임스탬프(start timestamp), 리소스 카운터(resource counters), 그리고 실패 유형(failure class)이 포함되어야 합니다. 판매자 패킷에는 구매자가 명시적으로 해당 공개 모델을 선택하지 않는 한, 비공개 프롬프트(private prompts)나 모델 가중치(model weights)를 포함해서는 안 됩니다. 판매자가 구매자의 워크로드를 유출하지 않으면서도 용량 및 런타임 증거(runtime evidence)를 보여줄 수 있을 때 DePIN GPU 시장의 신뢰도가 향상됩니다.

또한 판매자 패킷은 책임 소재를 제한합니다. 만약 작업자가 용량 챌린지(capacity challenge)를 통과했음에도 불구하고 구매자의 컨테이너가 선언된 장치의 가용 메모리보다 더 많은 메모리를 요청했다면, 판매자가 모델 품질에 대한 의미론적 불만(semantic model-quality complaint)까지 떠안아서는 안 됩니다. 반대로 작업자가 실행 전 용량 확인(capacity check)에서 실패했다면, 구매자가 모델 코드에 대해 논쟁할 필요가 없어야 합니다. DePIN GPU 시장의 영수증은 공급자의 가용성(availability)과 구매자의 워크로드 동작(workload behavior)을 분리할 때 더욱 공정해집니다.

Buyer Packet (구매자 패킷)

DePIN GPU Market 구매자는 실패의 일부를 제어하기 때문에 자신들만의 패킷(packet)이 필요합니다. 구매자 패킷에는 컨테이너 이미지 다이제스트 (container image digest), 커맨드 라인 (command line), 모델 아티팩트 해시 (model artifact hash), 입력 매니페스트 해시 (input manifest hash), 예상 메모리 예산 (expected memory budget), 예상 출력 경로 (expected output path), 그리고 평가 규칙 (evaluation rule)이 포함되어야 합니다. Gensyn의 재현 가능한 실행 환경 (Reproducible Execution Environment) 페이지가 이와 관련이 있는데, 재현 가능한 AI 실행은 실행 환경을 검사 가능하게 (inspectable) 만드는 것에 달려 있기 때문입니다. DePIN GPU Market 구매자는 워커(worker)에게 무엇을 실행하도록 요청했는지 정확히 명시하지 못한다면, 결과에 대해 정당하게 불만을 제기할 수 없습니다.

구매자 패킷은 또한 미묘한 실수를 잡아냅니다. 하드웨어에 비용을 지불한다고 해서 모델 작업이 잘 정의되는 것은 아닙니다. 프롬프트 (prompt), 데이터셋 (dataset), 디코딩 설정 (decoding settings), 또는 평가 규칙 (evaluation rule)이 취약하다면 모델이 성공적으로 실행되더라도 무용지물인 답변을 생성할 수 있습니다. DePIN GPU Market 영수증은 컴퓨팅 증거 (compute evidence)가 끝나는 지점과 모델 평가 (model evaluation)가 시작되는 지점을 명시해야 합니다. 이러한 분리는 인프라에 대한 주장 (infrastructure claims)이 AI 품질에 대한 약속 (AI-quality promises)으로 변질되는 것을 방지합니다.

Settlement Hold (결제 보류)

DePIN GPU Market의 결제 (settlement)는 실패한 레이어를 따라야 합니다. 용량 (capacity)은 통과했으나 실행 (execution)이 실패한 경우 결제를 보류할 수 있고, 실행이 완료되고 출력이 전달되면 결제를 해제하며, 구매자가 불가능한 컨테이너를 요청한 경우 부분 환불을 진행하거나, 로그가 일치하지 않을 경우 에스컬레이션 (escalated)할 수 있습니다. 결제 규칙은 마케팅 용어가 아닌 영수증 필드를 참조해야 합니다. 실패 유형이 기계 판독 가능 (machine-readable)할 때 DePIN GPU Market의 경제 구조는 더욱 깔끔해집니다.

실패 사례에 대한 결제 매트릭스 (settlement matrix)는 의도적으로 좁게 설정되었습니다:

Recovery Patch (복구 패치)

Recovery Patch (복구 패치)

DePIN GPU Market의 복구는 문구가 아닌 영수증(receipt)을 변경해야 합니다. 이 실패 사례에 대한 패치는 모든 유료 작업(paid job)에 대해 failure_class, output_hash, 그리고 evaluation_status를 요구하는 것입니다. 만약 output_hash가 null이라면, API는 evaluation_status=not_started 또는 not_applicable을 강제해야 합니다. 만약 execution=fail인 경우, 정산(settlement) 과정에서 해당 실행을 조용히 완료(delivered)로 표시해서는 안 됩니다. DePIN GPU Market 시스템은 불가능한 상태(impossible states)를 불가능하게 만들어야 합니다.

해당 패치는 이 글의 실질적인 테스트입니다. DePIN AI 컴퓨팅 마켓플레이스를 신뢰하기 전에, 컨테이너 시작 후 의도적으로 실패하도록 설정한 저렴한 작업을 하나 실행한 다음 영수증을 요청해 보십시오. 만약 플랫폼이 작업자(worker)가 존재했다는 사실이나 결제가 이루어졌다는 사실만을 보여줄 수 있다면, 그 플랫폼은 컴퓨팅(compute)에 대한 질문에 답하지 못한 것입니다. 만약 플랫폼이 견적(quote), 용량 확인(capacity check), 실행 실패(execution failure), 누락된 출력(missing output), 그리고 정산 상태(settlement state)를 모두 보여줄 수 있다면, 그 플랫폼은 진정한 AI 인프라 영수증의 뼈대를 갖춘 것입니다.

Dispute Ledger (분쟁 원장)

DePIN GPU Market의 분쟁 원장(dispute ledgers)은 구매자의 관점에서 추가 전용(append-only) 방식이어야 합니다. 구매자는 돈이 걸린 상황에서 고객 지원 담당자가 이야기를 다시 쓰도록 신뢰할 필요가 없어야 합니다. 최소한의 원장은 각 전환(transition)마다 하나의 행을 저장할 수 있습니다: 견적 수락(quote accepted), 용량 통과(capacity passed), 컨테이너 시작(container started), 실패 관찰(failure observed), 판매자 패킷 첨부(seller packet attached), 구매자 패킷 첨부(buyer packet attached), 정산 결정(settlement decided). DePIN GPU Market 운영자는 민감한 페이로드(payloads)는 비공개로 유지하면서도, 분쟁 조사가 가능하도록 해시(hashes)와 상태 전환(status transitions)은 공개할 수 있습니다.

아래의 원장 행은 의도적으로 단조롭게 작성되었습니다. 단조로운 행이 자동화하기 더 쉽기 때문입니다:

job_id=run_8841
transition=execution_failed
capacity_status=pass
...

DePIN GPU Market의 원장(ledger)은 분쟁 상태가 변경되었음을 증명할 뿐, 어느 한 쪽이 도덕적으로 옳다는 것을 증명하지는 않습니다. 이 차이는 중요합니다. 판매자는 약속된 기계를 정확히 제공했을 수 있지만, 구매자가 실행 불가능한 작업 부하(workload)를 제출했을 수도 있습니다. 반대로 구매자가 정상적인 작업 부하를 제출했음에도 작업자 환경(worker environment)이 잘못 설정되었을 수도 있습니다. 원장은 스스로 결정을 내리지 않습니다. 다만 결정이 증거로부터 벗어나지 않도록 방지할 뿐입니다.

재시도 계약 (Retry Contract)

DePIN GPU Market의 재시도 계약(retry contracts)은 구매자가 작업을 실행하기 전에 실행 실패(execution failure) 이후에 어떤 일이 발생하는지를 명시해야 합니다. 재시도는 동일한 제공자(provider)를 사용하거나, 다른 제공자를 사용하거나, 더 작은 배치(batch)를 사용하거나, 다른 메모리 제한(memory limit)을 적용하거나, 혹은 환불 경로(refund path)를 따를 수 있습니다. 선택된 규칙은 인센티브(incentives)를 변화시킵니다. 만약 모든 실행 실패 시 판매자에게 비용이 지불된다면, 구매자가 제공자의 설정 오류를 떠안게 됩니다. 만약 모든 실행 실패 시 구매자에게 환불된다면, 판매자가 구매자의 실수를 떠안게 됩니다. 인프라 분쟁은 부분적으로 경제적 설계의 문제이기 때문에, DePIN GPU Market의 영수증에는 재시도 계약이 필요합니다.

합리적인 재시도 계약은 범위를 좁게 설정할 수 있습니다: 용량(capacity)은 통과했으나 출력 해시(output hash) 생성 전 실행이 실패한 경우 1회의 무료 재시도 제공; 구매자가 선언한 메모리 예산이 견적된 기계의 사양을 초과한 경우 자동 재시도 불가; 로그가 일치하지 않을 경우 수동 검토; 출력 해시가 존재하는 경우에만 서비스 품질(service-quality) 정책 적용. DePIN GPU Market 시스템은 영수증 스키마(receipt schema)와 함께 해당 계약을 작성해야 합니다. 그렇지 않으면 첫 번째 실패한 작업이 시장이 압박 속에서 임의로 정책을 만들어내는 지점이 될 것입니다.

현장 노트 (Field Note)