ASIC таңдау
Қазақстанда ASIC қалай таңдалады: қуат, хэшрейт және толық баға
ASIC-ті хэшрейтпен ғана емес, нақты қуат, J/TH, алаң сәйкестігі, кепілдік, тест және толық иелену құны бойынша таңдаңыз.
Қазақстанда ASIC сатып алғанда каталогтағы TH/s тек құрылғының теориялық есептеу қабілетін көрсетеді. Ол алаңның электрі жеткілікті ме, жазда жылуды шығара ала ма, ақау кезінде кім жауап береді және салынған қаражат сақтық сценарийінде қайтарыла ма деген сұрақтарға жауап бермейді. Дұрыс салыстыру бір бағаға емес, бірдей электр, uptime, жөндеу және қалдық құн болжамдары бойынша есептелген толық нәтижеге сүйенеді.
Бұл нұсқаулық API-сыз сатып алу процесін береді. Кандидат ASIC-тердің ресми сипаттамасын, сатушы құжатын, орындағы тестті, электр шартын және өзіңіздің шығын моделіңізді бір кестеге жинайсыз. Алдымен алаңға сәйкес келмейтін немесе дерегі толық емес құрылғыларды алып тастап, содан кейін энергия тиімділігін, тиімді хэшрейтті және толық иелену құнын салыстырасыз.
Деректер 2026-08-09 күні UTC+8 бойынша тексерілді. Сипаттама, firmware, кепілдік, жеткізілім және баға өзгеруі мүмкін. Тапсырыс алдында өндірушінің соңғы құжаты мен сату шартын қайта тексеріңіз. Мақаладағы модельдер салыстыру әдісін түсіндіру үшін ғана қолданылған және бренд ұсыну болып саналмайды.
Мазмұны
- ASIC таңдаудың дұрыс реті
- Алдымен алаңға сәйкестікті тексеріңіз
- Хэшрейт, қуат және тиімділікті салыстыру
- Тек құрылғы бағасын салыстырмаңыз
- Ауамен салқындату, шу және орта
- Жаңа, қолданылған және қалпына келтірілген ASIC
- Сатушы мен құжаттарды тексеру
- Қабылдау және стресс-тест
- Партиямен сатып алу тәуекелі
- Салмақталған бағалау кестесі
- Қай жағдайда ұсыныстан бас тарту керек
- Сатып алу аудитін тереңдету
- Жиі қойылатын сұрақтар
- Ресми және бастапқы дереккөздер
ASIC таңдаудың дұрыс реті
Таңдау «қайсысының хэшрейті жоғары?» деген сұрақтан емес, қабылдауға болмайтын шарттардан басталады. Бес сүзгіні ретімен қолданыңыз.
- Алгоритм мен өндірім сәйкестігі. Құрылғы алгоритмін, өндірілетін активті және жоспарланған пулды растаңыз. Bitcoin әзірлеуші құжаттамасы ASIC блок header хэшін үздіксіз есептейтінін, ал пул майнер жіберген share бойынша түсімді бөлетінін түсіндіреді. Алгоритм сәйкес болмаса, баға салыстырудың мәні жоқ.
- Электр сәйкестігі. Кернеу, фаза, жиілік, ток, коннектор, PDU, кабель, автомат және жалпы қуатты тексеріңіз. Адаптер электр инфрақұрылымының сәйкессіздігін шешпейді.
- Орта сәйкестігі. Кіріс ауа температурасы, ылғал, биіктік, шаң, коррозиялық газ, шу және ыстық ауаны шығару жолын бағалаңыз.
- Экономика сәйкестігі. Нақты қуат, тиімді хэшрейт, uptime, электр, алаң, жөндеу және қалдық құнды бір модельге енгізіңіз.
- Мәміле және сервис. Сатушыны, сериялық нөмірді, шотты, кепілдік басталуын, жөндеу орнын, тасымал жауапкершілігін және қабылдамау шартын тексеріңіз.
Осы рет арзан ұсынысқа қызығып, кейін алаңды қымбат қайта жабдықтау, шуды басқара алмау немесе кепілдіктің күткеннен ерте біту қаупін азайтады. Алғашқы төрт сүзгіден өтпеген құрылғының бағасы талқыланбауы керек.
Алдымен алаңға сәйкестікті тексеріңіз
Кернеу мен ток жай ғана ескерту емес
BITMAIN S21 Pro ресми сипаттамасында 220–277V AC, 50–60Hz және бір фазалы 20A кіріс көрсетілген; максимал жағдайда ұсынылатын қуат көзі 4000W деп берілген. S21 XP орнату нұсқаулығында да 220–277V AC және 20A көрсетіліп, құрылғыда екі power input бар екені, жұмыс үшін екеуін де қосу және өшіргенде екеуін де ажырату керектігі жазылған. Бұл шарттарды басқа ASIC-ке автоматты түрде қолдануға болмайды: әр кандидаттың соңғы құжатын пайдаланыңыз.
Сатып алу кестесіне мыналарды енгізіңіз:
| Электр өрісі | Кандидат A | Кандидат B | Алаң шарты |
|---|---|---|---|
| Кіріс кернеу диапазоны | Ресми құжат | Ресми құжат | Өлшенген және шарттағы мән |
| Максимал кіріс ток | Ресми құжат | Ресми құжат | Кабель мен автомат рейтингі |
| Power input саны | Ресми құжат | Ресми құжат | PDU порты |
| Типтік қабырға қуаты | W | W | Сыйымдылық шегі емес |
| Төзімділікпен қуат | W | W | Стресс-тест үшін |
| Бір ASIC-ке резерв | kW/kVA | kW/kVA | Электр маманы растайды |
Алаң сыйымдылығын «шарттық kW / каталог қуаты» деп қана есептеуге болмайды. Тарату мен трансформатор шығыны, желдету немесе салқындату, желі жабдығы, жарық, іске қосу жағдайы, қуат төзімділігі және қауіпсіздік резерві қосылады. Schneider Electric деректер орталығы қуат құралында да толық қажеттілік IT load-пен шектелмей, cooling, lighting және power backup сияқты инфрақұрылым жүктемелерін қамтиды.
Кабель қимасы, автомат, PDU және қорғаныс нақты алаңға сай білікті электр маманымен есептелуі тиіс. Өндіруші көрсеткен 20A санын розеткаға жазылған 20A белгісімен ғана салыстыру жеткіліксіз; тұрақты жүктеме, қоршаған температура, монтаж әдісі және жергілікті норма маңызды.
Биіктік пен температура бірге қаралады
S21 Pro ресми беті жұмыс температурасын -20–45°C, биіктікті 2000m-ге дейін деп көрсетеді. Сонымен бірге 900m-ден 2000m-ге дейін биіктік әр 300m артқанда максимал жұмыс температурасы 1°C төмендейтіні жазылған. Сондықтан «температура диапазонда» және «биіктік диапазонда» деген екі жеке белгі жеткіліксіз; олардың комбинациясы тексеріледі.
Егер жазда кіріс ауа жоғарғы шекке жақындаса, модель желдеткіш пен ауа шығаруға кететін қуатты көбейтіп, күтілетін uptime-ды азайтып, throttling немесе қорғаныс тоқтауын стресс сценарийіне енгізуі керек. Қыстағы сынақ бүкіл жылдың дәлелі емес.
Хэшрейт, қуат және тиімділікті салыстыру
Үш мәнді қатар қараңыз
- Хэшрейт, TH/s — құрылғының бір секундтағы hash әрекет саны.
- Қабырғадағы қуат, W — power supply шығынын қосқандағы электр желісінен алынатын қуат.
- Энергия тиімділігі, J/TH — бір TH/s үшін энергия; мән төмен болған сайын электр тиімділігі әдетте жоғары.
Энергия тиімділігі (J/TH) = қабырғадағы қуат (W) / хэшрейт (TH/s)
Ресми типтік мәндермен әдісті көрсетейік. S21 Pro — 234 TH/s және 3510W, өндіруші 15 J/TH деп береді. S21 XP нұсқаулығында 270 TH/s және 3645W көрсетілген; бөлу арқылы шамамен 13,5 J/TH шығады. Бұл сатып алу ұсынысы емес. Екі құжат та нақты хэшрейт ±3%, қуат пен тиімділік ±5% ауытқуы мүмкін екенін ескертеді. Сондықтан бір нүктені емес, төзімділік диапазонын салыстыру керек.
Номинал емес, тиімді хэшрейт
Бизнеске dashboard-тағы бір сәттік максимум емес, пул қабылдаған жұмыс маңызды.
Тиімді хэшрейт = ұзақ орташа хэшрейт × uptime × (1 − rejected share)
Тиімді J/TH = ұзақ орташа қуат / тиімді хэшрейт
Каталогта 15 J/TH болған ASIC қызып жиі қайта қосылса, желі үзіліп немесе hashboard жоғалса, нақты тиімділігі нашарлайды. Қолданылған құрылғы үшін бес минуттық screenshot емес, жеткілікті ұзақ тест журналын сұраңыз.
Барлық кандидатқа бірдей болжам
Салыстыру кезінде мыналар бірдей болуы тиіс:
- BTC өндірімін есептеу әдісі және тексеру уақыты;
- электр бағасы және қолданылатын төлем;
- пул төлем әдісі мен комиссиясы;
- uptime, rejected share және жазғы температура;
- жөндеу резерві мен иелік мерзімі;
- сату айы және қалдық құн әдісі.
A моделіне оптимистік BTC бағасын, B моделіне сақтық бағасын қолдансаңыз, рейтинг шешімге жарамайды.
Тек құрылғы бағасын салыстырмаңыз
Салыстырылатын сатып алу бағасы — ASIC тұрақты жұмысқа дайын болғанға дейінгі толық құн.
Толық алу құны = құрылғы + тасымал + сақтандыру + қолданылатын импорт шығыны + монтаж + кабель/PDU + электр қайта жабдықтау + желі/мониторинг + алғашқы қосалқы бөлшек
Содан кейін иелік кезеңін есептеңіз:
Иелік кезеңінің толық құны = алу құны + электр + қолданылатын төлем + алаң + ортақ қуат + жөндеу + downtime шығыны + қаржы құны − таза қалдық құн
Downtime шығынын орындалмаған ең жоғары ықтимал түсіммен шексіз үлкейтпеңіз. Сол кезеңдегі дәлелді базалық өндірімді пайдаланыңыз. Қарыз болса нақты төлем кестесін қолданыңыз; қарыз жоқ кезде капиталды ұстау құнын салыстыру бағанына шығаруға болады, бірақ оны төленген ақша ретінде көрсетпеңіз.
TH/s бағасы жалғыз шешім емес
Бір TH/s алу құны = толық алу құны / номинал хэшрейт
Бұл жылдам сүзгі, бірақ сатып алу шешімі емес. Арзан және тиімсіз ескі ASIC өте арзан электрде жұмыс істеуі мүмкін немесе жазғы қуат, сыйымдылық және жөндеу салдарынан артықшылығын жоғалтады. Пайдалырақ көрсеткіш:
Бір тиімді TH/s иелік құны = иелік кезеңінің толық құны / жинақталған тиімді TH/s
Модельдерді BTC бағасы төмен, қиындық жоғары, электр қымбат және downtime көп сценарийлеріне салыңыз. Аз ғана өзгерісте рейтинг ауысса, шешім болжамға өте сезімтал; партия санын кішірейткен дұрыс.
Ауамен салқындату, шу және орта
Шу — алаң шығыны
S21 Pro және S21 XP құжаттары шамамен 76 dBA шу көрсетеді. Нақты шу құрылғы санына, бөлме шағылуына, ауа арнасына, қашықтыққа және ғимаратқа тәуелді. Бір ASIC каталог мәнін ферма шекарасындағы шу деп қабылдамаңыз. Кеңсе, тұрғын аймақ немесе ұзақ жұмыс істейтін персонал бар болса, дыбыс оқшаулау, ауа арнасы, жеке қорғаныс және өлшеу шығыны пайда болады.
Шаң мен коррозия тек тазалау жиілігі емес
S21 XP нұсқаулығы жұмыс бөлмесінде жарылғыш, электр өткізгіш, магниттік және коррозиялық шаң болмауын талап етіп, ластану көздері мен коррозиялық газдарға қатысты шарттарды береді. Мұндай орта радиатор бітелуіне, желдеткіш, коннектор және hashboard мерзіміне әсер етеді. Көмір шаңы, тұз, жоғары ылғал немесе өндірістік ластану бар алаңда алдымен орта мен фильтрацияны бағалаңыз.
Ауа жолын жылу бойынша жобалаңыз
ASIC тұтынған қуаттың басым бөлігі жылуға айналады. Air cooling үшін ауа көлемі, кіріс және шығыс температурасы, cold/hot aisle, желдеткіш қуаты және жазғы ең нашар жағдай есептеледі. Сыртқы өлшемі ұқсас ASIC-тердің ауа кедергісі мен шығу температурасы бірдей деп ойламаңыз. Модельдерді араластырсаңыз, партиямен өлшеп, бір машинаның ыстық ауасы екіншісіне кірмеуін қамтамасыз етіңіз.
Жаңа, қолданылған және қалпына келтірілген ASIC
Жаңа құрылғы
Артықшылығы — шығу тегі, кепілдік және алғашқы күйі әдетте түсініктірек. Тәуекелі — жоғары баға, жеткізу мерзімі және партия нұсқасының өзгеруі. Тапсырыс алдында нақты модель, хэшрейт версиясы, power supply, кабель, жөнелту орны, serial list және кепілдік басталуын жазыңыз.
Қолданылған құрылғы
Қолданылған баға күй тексерілгенде ғана мағыналы. Минимал тексеру:
- control board, барлық hashboard және chip detection;
- ұзақ орташа хэшрейт, бір сәттік мән емес;
- қабырғадағы нақты қуат;
- inlet, outlet және chip температурасы;
- rejected share, restart және board loss тарихы;
- fan дыбысы, айналымы және дірілі;
- шаң, коррозия, күйік, май немесе сұйық іздері;
- сериялық нөмір, firmware көзі, жөндеу белгісі және қалған кепілдік.
Canaan ресми Miner Log Technical Guidance құжаты құрылғы log-ы hashboard, chip, температура, желі немесе power мәселесін ажыратуға көмектесетінін көрсетеді. Басқа бренд сатып алсаңыз да, экспортталатын бастапқы log немесе қайталанатын тест сұраңыз; сатушының ауызша сөзі жеткіліксіз.
Қалпына келтірілген құрылғы
«Refurbished» бірыңғай сапа класы емес. Қандай бөлшек ауысқанын, жаңа немесе donor part қолданылғанын, кім жөндегенін, қанша уақыт тест жасалғанын және кепілдікті кім беретінін нақтылаңыз. Бөлшек тізімі, тест журналы және айқын сервис болмаса, таза корпусқа қарап жаңаға жақын баға бермеңіз.
Сатушы мен құжаттарды тексеру
Тапсырысқа дейін бір папкада ресми offer, компанияның тексерілетін дерегі, төлем алушы атауы, invoice үлгісі, equipment list, serial list, түпнұсқа фото/видео, тест журналы, warranty, shipping және rejection шарттарын сақтаңыз.
Кепілдік басталуы шартта жазылсын
BITMAIN ресми кепілдік беті жаңа BTC miner мен power supply әдетте 365 күн кепілдікке ие екенін, бірақ нақты мерзім sales contract-қа тәуелді және ресми жөнелту күнінен есептелетінін айтады. Демек, reseller-ден сатып алғанда сіз алған күн original warranty басталған күн болмауы мүмкін. Serial арқылы тексеріп, қалған мерзімді қабылдау актісіне енгізіңіз.
«Original warranty бар» деген сөз бүкіл тәуекел сатушыға өтті дегенді білдірмейді. Жөнелту, кеден, downtime, бөлшектеу, spare machine және service center қашықтығы шартта бөлек қаралады.
Төлем кезеңі және дәлел
Ірі немесе партиялық сатып алуда төлемді тексерілетін кезеңдерге бөлу орынды: құжат тексеру, sample pass, shipping document, келген саны және final stress test. Нақты шарт пен төлемді білікті маман қарауы тиіс. Бұл материал нақты төлем құралы немесе заң мәтінін ұсынбайды.
Қабылдау және стресс-тест
Қуат берер алдында
- Қорап саны, модель, версия және serial number-ді тізіммен салыстырыңыз.
- Соғылу, ылғал, пломба және аксессуарды тексеріңіз.
- Корпус, fan, connector, power cable және бөгде затты қараңыз.
- Аккаунт, ішкі URL немесе credential көрінбейтін қабылдау фотоcын жасаңыз.
- Қуат пен жерге қосуды электр маманы растағанын тексеріңіз.
Қуатпен тест
Бүкіл партияны бірден тұрақты rack-қа қоспаңыз. Қуаты расталған оқшауланған тест аймағында әр ASIC үшін мынаны жазыңыз:
- boot уақыты және желі алу;
- firmware версиясы және сенімді көзі;
- барлық hashboard пен chip анықталуы;
- тұрақты кезеңдегі орташа хэшрейт;
- clamp meter немесе есептегіш қуаты;
- inlet, outlet және board температурасы;
- rejected share, hardware error және restart саны;
- fan RPM, бөтен дыбыс және діріл;
- бастапқы log файлы.
Тест ұзақтығы шартта алдын ала көрсетіліп, pass/fail анықтамасы жазылсын. «Қосылады» деген белгі хэшрейт, қуат және тұрақтылық талабын орындамайды.
Төзімділікпен қабылдау
Өндіруші tolerance берсе, қабылдау сол модельдің ресми диапазонынан басталады және келісілген тест ортасын ескереді. 25°C типтік қуатпен басқа кіріс температурада тексерілген ASIC-ті автоматты түрде жарамсыз деуге болмайды. Сол сияқты, сатушы қысқа peak hashrate арқылы ұзақ төмен өнімділікті жасыра алмауы керек.
Партиямен сатып алу тәуекелі
Қауіпсіздеу реттілік: құжат — sample — pilot batch — scale batch.
- Құжат: serial, кепілдік, сипаттама немесе мәміле шарты түсініксіз сатушыны алып тастаңыз.
- Sample: аз құрылғыны өз электріңіз бен температураңызда сынап, қуат, хэшрейт және жылу baseline құрыңыз.
- Pilot batch: rack, PDU, airflow, monitoring, spare және персонал процесін тексеріңіз.
- Scale batch: тек нақты cost model әлі өтсе ғана санды арттырыңыз.
Sample-ды сатушы өзі таңдамасын. Алдымен толық serial list алыңыз, содан кейін қайталанатын кездейсоқ әдіспен таңдаңыз. Қабылдау сәтсіз болса, replacement, discount, full rejection немесе extended test тәртібі алдын ала жазылсын.
Көп модель араластыру spare part, firmware, monitoring және repair complexity-ді өсіреді. Әртүрлі арзан ескі ASIC құрылғы бағасын төмендетіп, operation және downtime шығынын көтеруі мүмкін. Модель санын тек арзан баға емес, техникалық команда мүмкіндігі анықтауы керек.
Салмақталған бағалау кестесі
Алдымен reject шарттарын қолданыңыз, содан кейін өткен кандидаттарды бағалаңыз. Төмендегі салмақ үлгі ғана:
| Критерий | Үлгі салмақ | Дәлел |
|---|---|---|
| Нақты тиімді J/TH | 25% | Ұзақ хэшрейт, қуат, rejected share |
| Толық иелену құны | 20% | Бірдей сценарий моделі |
| Электр және орта сәйкестігі | 15% | Электр шолуы, температура, airflow |
| Күй және тұрақтылық | 15% | Log, restart, температура, сыртқы күй |
| Кепілдік және жөндеу қолжетімділігі | 10% | Serial check, contract, service location |
| Сатушы және құжат толықтығы | 10% | Invoice, payment, shipping, acceptance |
| Қайта сату өтімділігі | 5% | Бірнеше тексерілетін ұсыныс |
Әр баллдың құжаты немесе тесті болсын. Дерек жоқ кезде орта балл бермеңіз: «тексерілмеген» деп көрсетіп, төмендетіңіз немесе алып тастаңыз. Бұл каталог әдемілігінің белгісіз тәуекелді бейтарап баллға айналдыруына жол бермейді.
Қай жағдайда ұсыныстан бас тарту керек
- Модель, хэшрейт версиясы, power supply немесе serial number расталмайды.
- Мәміле субъектісіне қатысы жоқ шотқа төлем сұралады және түсіндірме құжат жоқ.
- Ұзақ тест, бастапқы log немесе қайталанатын қабылдау берілмейді.
- Firmware көзі белгісіз немесе сатушы өз remote access-ын қалдыруды талап етеді.
- Қуат, хэшрейт, board loss немесе restart келісілген шектен тыс.
- Коррозия, сұйық, күйік, ауыр шаң немесе қалыпсыз сым ізі бар.
- Warranty сөзі serial check, shipping date немесе contract-пен сәйкес емес.
- Алаң voltage, current, capacity, temperature немесе heat rejection талабына сәйкес емес.
- ASIC тек BTC бағасын көтеріп, difficulty мен repair-ды елемегенде өтеледі.
- Сатушы толық төлемді алдын ала сұрап, specification, acceptance және fail handling жазбайды.
Reject rule сатып алуға дейін құнды. Құрылғы келіп, ақша төленгеннен кейін адам шығынды мойындамау үшін талапты жұмсартуға бейім.
Жиі қойылатын сұрақтар
Ең жоғары хэшрейтті ASIC алу керек пе?
Міндетті емес. Жоғары хэшрейт жоғары ток, жылу және бастапқы құн сұрауы мүмкін. Тиімді J/TH, толық иелену құны, алаң сыйымдылығы және стресс сценарийін қатар салыстырыңыз.
J/TH төмен болса, әрқашан жақсы ма?
Өзге шарт бірдей болса, төмен J/TH әдетте электр тиімділігін білдіреді. Бірақ баға, reliability, repair, power compatibility және uptime нәтижені өзгерте алады. Каталог J/TH нақты тиімділікпен түзетілуі керек.
Қолданылған ASIC қанша уақыт тестіленеді?
Барлық мәмілеге бірдей уақыт жоқ. Тест thermal stability, hashrate variation, board loss, restart, power және rejected share-ды байқауға жеткілікті болуы және шартта pass criteria-мен жазылуы тиіс. Бес минуттық экран тұрақтылық дәлелі емес.
Әртүрлі модельді араластыруға бола ма?
Болады, бірақ PDU, кабель, airflow, firmware, monitoring, spare және repair complexity құнын қосыңыз. Команда көп платформаны басқара алмаса, модельді азайту баға айырмасынан құнды болуы мүмкін.
Жаңа ASIC кепілдігі мен алған күннен бастала ма?
Болжамаңыз. BITMAIN ашық саясаты мысалында мерзім ресми сату жөнелту күнінен есептеледі және sales contract басым. Reseller мәмілесінде serial мен құжат арқылы қалған мерзімді тексеріңіз.
Сатып алу аудитін тереңдету
Сатып алу талабын ұсыныстан бұрын жазу
Сатушы каталогын ашпас бұрын ішкі requirement sheet дайындаңыз. Егер талап құрылғыны көргеннен кейін жазылса, команда ұнаған модельге сай шарттарды жұмсартуға бейім болады. Талапта алгоритм, мақсатты хэшрейт диапазоны, максимал қабырға қуаты, рұқсат етілген кернеу мен ток, салқындату түрі, шу шегі, жұмыс ортасы, monitoring интеграциясы, firmware саясаты, кепілдік және жөндеу уақыты көрсетілсін.
Талапты үш деңгейге бөліңіз. Must орындалмаса, ұсыныс қабылданбайды. Should салыстыру баллына әсер етеді. Could пайдалы, бірақ экономикасы дәлелденбесе сатып алу шартын өзгертпейді. Мысалы, алаңның электр диапазонына сәйкестік — must; жергілікті spare қолжетімділігі — should; қаптаманың сыртқы көрінісі — could болуы мүмкін. Бұл жіктеу әр жобаға қарай бекітіледі.
Әр талаптың дәлел түрін алдын ала жазыңыз. Өндіруші сипаттамасы, сериялық нөмір тексеруі, ұзақ жүктеме тесті, есептегіш өлшемі, log экспорты немесе шарт тармағы бір-бірін алмастырмайды. «Сатушы растады» деген жол дәлел емес; кім, қандай құжатпен және қай күні растағаны көрінуі керек.
Requirement sheet соңында қабылдау шегі мен fail handling болсын. Құрылғы белгіленген хэшрейтке жетпесе не болады, қуат диапазоннан асса қандай жеңілдік немесе қайтару бар, бірнеше hashboard істемесе бүкіл партия ма әлде жеке бірлік пе қабылданбайды — осының бәрі төлемге дейін келісіледі.
Ұсыныстарды бір форматқа келтіру
Сатушылар бағаны әртүрлі береді: құрылғы ғана, қоймадан алу, жеткізумен, кеден рәсімімен немесе installation-мен. Бір ұсыныста power supply кіруі мүмкін, екіншісінде бөлек. Сондықтан барлық ұсынысты normalized bid sheet-ке көшірмей салыстырмаңыз.
Кемінде мына жолдар болсын:
| Жол | Не жазылады | Қандай дәлел керек |
|---|---|---|
| Модель және нұсқа | Толық атау, hashrate variant, cooling | Өндіруші құжаты және serial list |
| Саны мен күйі | Жаңа, қолданылған, refurb | Invoice және тексеру есебі |
| Баға шекарасы | Device, PSU, кабель, логистика | Коммерциялық ұсыныс |
| Жеткізу шарты | Кім қай нүктеге дейін жауап береді | Шарт тармағы |
| Төлем кезеңі | Deposit, inspection, acceptance | Шарт және шот |
| Кепілдік | Басталу күні, қамту, алып тастау | Өндіруші немесе сатушы шарты |
| Қабылдау | Ұзақ тест, шек, sample әдісі | Acceptance appendix |
| Сәтсіздік тәртібі | Repair, replace, refund, discount | Міндетті шарт тармағы |
Бағаны бір валютаға және бір күнге келтіріңіз. Бірақ валюта бағамын кейін білген нәтижемен ауыстырмаңыз; ұсынысты бағалаған күнгі қолданылған бағам мен дереккөзді сақтаңыз. Болашақ төлем бірнеше кезеңге бөлінсе, әр төлемнің бағам тәуекелін бөлек көрсетіңіз.
Құрылғының қоймадағы жерін және меншік иесін тексеру де маңызды. Фото немесе бейне нақты партияның бар екенін жалғыз өзі дәлелдемейді. Serial list, қойма құжаты, сатушы субъектісі және төлем алушы бір мәмілеге байланысуы керек. Байланыс түсініксіз болса, мәмілені жылдамдату үшін тәуекелді елемеңіз.
Сериялық нөмір мен конфигурацияны басқару
Бір модель атауы астында әртүрлі хэшрейт, power supply, firmware немесе өндіріс партиясы болуы мүмкін. Сондықтан asset register сатып алу кезінде басталады. Әр ASIC үшін serial number, control board, PSU нұсқасы, сатушы, шот жолы, жөнелту күні, кепілдік мәртебесі және жоспарланған rack орны сақталсын.
Serial list төлемге дейін алынғаны дұрыс. Қабылдау кезінде тізімді құрылғыдағы жапсырмамен және интерфейстегі идентификатормен салыстырыңыз. Қайталанған, жоқ немесе жоспардан тыс serial жеке exception болады. Тізімсіз «осы модельден жүз дана» сатып алу warranty мен ақау тарихын байланыстыруды қиындатады.
Firmware нұсқасын да asset register-ге енгізіңіз. Құрылғыны сатушының басқару аккаунтымен немесе белгісіз custom firmware-пен бірден өндірістік желіге қоспаңыз. Ресми көзден алынған нұсқаны, checksum немесе жарияланған тексеру әдісін өндіруші құжатында бар болса пайдаланыңыз. Белгісіз firmware өнімділікті уәде еткенмен, remote access, комиссия, тұрақтылық немесе кепілдік тәуекелін тудыруы мүмкін.
Конфигурация өзгерген сайын кім, қашан және не үшін өзгерткенін жазыңыз. Жөндеуден кейін control board немесе hashboard ауысса, бұрынғы serial байланысы мен жаңа бөлшек тарихы жоғалмасын. Бұл кейін қай партияда қайталанатын ақау барын көруге мүмкіндік береді.
Sample таңдауды сатушыға қалдырмау
Үлгі тест бүкіл партия сапасын көрсетуі үшін sample кездейсоқ және қайталанатын әдіспен таңдалуы керек. Сатушы тек ең жақсы құрылғыларды өзі таңдаса, тест нәтижесі bias болады. Толық serial list-ті алған соң, мысалы, алдын ала бекітілген random seed немесе нөмірлер кестесімен sample таңдаңыз. Әдісті және нәтижені сақтаңыз.
Sample көлемі мәміле құнына, партияның біртектілігіне, күйіне және fail салдарына байланысты. Бір әмбебап сан жоқ. Жаңа, бір өндірістік партия және тікелей өндірушіден келген құрылғы мен бірнеше көзден жиналған қолданылған партия бірдей тәуекелге ие емес. Статистикалық әдіс қажет болса, оны сапа маманы мәміле тәуекеліне сай анықтасын.
Sample тестінен өткен нәтиже бүкіл партияны автоматты түрде қабылдатпайды. Ол pilot немесе arrival inspection көлемін анықтайды. Егер sample ішінде критикалық ақау табылса, тест көлемін кеңейту, партияны бөлу немесе мәмілені тоқтату тәртібі шартта жазылуы керек.
Тест құрылғыларының орны мен жағдайын тіркеңіз: кіріс ауа температурасы, кернеу, желі, пул, firmware және тест ұзақтығы. Сатушы алаңындағы нәтиже сіздің фермадағы нәтижеге тең болмауы мүмкін. Сондықтан off-site sample тек бірінші сүзгі; соңғы baseline нақты алаңда құрылады.
Қабылдау стендін алдын ала дайындау
Жеткізілім келген күні кабель, PDU, желі немесе есептегіш дайын болмаса, қабылдау мерзімі қысылып, команда қысқа экранға қарап қол қоюы мүмкін. Acceptance bench партия жөнелтілмей тұрып тексерілсін. Оның қуаты, қорғанысы, желісі, airflow, температура өлшеуі және log сақтау орны жоспарланған модельге сәйкес болуы керек.
Стенд өндірістік желіден логикалық тұрғыда оқшауланғаны дұрыс. Жаңа құрылғы алдымен басқарылатын quarantine сегментіне қосылады, default credential өзгертіледі, белгісіз remote endpoint пен firmware тексеріледі. Бұл жерде қауіпсіздік командасының саясаты басым; мақала нақты желі конфигурациясын алмастырмайды.
Қабылдау құралының өзі де тексеріледі. Қуат өлшегіштің бірлігі мен дәлдігі, ток қысқышының бағыты, температура датчигінің орны, уақыт синхронизациясы және monitoring сағаты дұрыс болсын. Өлшеу құралы қате болса, жақсы ASIC-ті reject етуге немесе ақаулы құрылғыны қабылдауға болады.
Тест файлына автоматты атау ережесін қолданыңыз: serial, дата, тест нұсқасы және оператор. Скриншот жалғыз дәлел емес; machine log, pool-side hashrate, power reading және оқиға белгісі бірге сақталсын. Жеке аккаунт, token, cookie немесе ішкі URL көрінсе, материалды сыртқа шығарғанда міндетті түрде жасырыңыз.
Көп кезеңді қабылдау тесті
Қабылдауды бір ғана ұзақ жүктемеге қысқартпаңыз. Бірінші кезең — қуатсыз тексеру. Қаптама, пломба, корпус, коннектор, желдеткіш, коррозия, сұйық ізі, күйік белгісі және сериялық нөмір қаралады. Тасымал зақымы болса, құрылғыны қосар алдында фото, акт және carrier хабарламасы жасалады.
Екінші кезең — қауіпсіз іске қосу. Кернеу мен қосылым тексеріліп, екі кірісі бар модельде өндіруші нұсқаулығы орындалады. Құрылғының boot log-ы, fan, board detection, температура датчигі және желі күйі бақыланады. Күйік иісі, қалыпсыз дыбыс немесе қорғаныс аппаратының іске қосылуы болса, тест тоқтатылады.
Үшінші кезең — тұрақтану. Құрылғы бірден номиналға жетпеуі мүмкін; warm-up және autotune жүрсе, оны log-та белгілеңіз. Тұрақтанғаннан кейін ғана хэшрейт, қуат, температура және rejected share салыстырылады. Қысқа peak мәнді орташа нәтиже ретінде жазбаңыз.
Төртінші кезең — ұзақ жүктеме. Мақсат restart, board loss, температура ауытқуы, желі үзілуі және қуат тұрақтылығын көру. Ұзақтығын мәміле тәуекелі мен шарт анықтайды. Тест кезінде firmware немесе режим өзгерсе, нәтижені бір кезеңге араластырмай, жаңа run ретінде бастаңыз.
Бесінші кезең — controlled restart және қалпына келу. Құрылғы жоспарлы қайта іске қосылғаннан кейін конфигурацияны, пулды және барлық board-ты дұрыс қалпына келтіре ме — тексеріңіз. Бұл әрекет өндіруші тәртібі мен алаң қауіпсіздігіне сай орындалуы керек; қоректі ретсіз үзу тест әдісі емес.
Pass, conditional pass және fail
Қабылдау қорытындысын тек pass/fail деп шектеу кейбір басқарылатын айырманы жасырады. Үш нәтиже қолдануға болады. Pass — барлық must шек орындалды. Conditional pass — қауіпсіздікке қатысы жоқ, құжатталған шағын айырма бар және оның бағасы, жөндеуі немесе мерзімі шартпен жабылған. Fail — қауіпсіздік, сәйкестік, тұрақтылық немесе келісілген экономика шегінен асқан ақау.
Conditional pass мәмілені асығыс қабылдау жолы болмауы керек. Әр exception-да owner, түзету, соңғы мерзім, ұсталған төлем және қайта тест шарты болсын. Мысалы, бір желдеткіш ауыстырылғанша құрылғы өндірістік актив ретінде есептелмейді. Түзету мерзімі өтсе, шарттағы fail handling іске қосылады.
Партия деңгейіндегі ереже бөлек жазылады. Бір құрылғы fail болса бүкіл партия қайтарыла ма, sample кеңейе ме, тек сол бірлік ауыса ма — бұл шешім ақау түрі мен шартқа байланысты. Жүйелік белгі, мысалы бір өндіріс партиясында қайталанатын board loss, жеке ақаудан маңыздырақ болуы мүмкін.
Acceptance certificate барлық exception жабылғаннан кейін ғана түпкілікті қол қойылады. Тауардың физикалық келуі техникалық қабылдау, ownership transfer және final payment бір мезетте болды дегенді білдірмейді. Осы үш кезең шартта анық бөлінсін.
Қуат дерегін қалай тексеру керек
Өндіруші қуат мәні сатып алу алдындағы baseline, бірақ нақты қабырға қуатын есептегішпен өлшеу керек. Өлшеуде кіріс кернеуі, температура, жұмыс режимі және firmware нұсқасы тіркелсін. Бір кандидат салқын бөлмеде, екіншісі ыстық aisle-де өлшенсе, нәтижені тікелей салыстыруға болмайды.
Орташа қуатпен бірге ауытқуды қараңыз. Қысқа peak PDU мен қорғанысқа әсер етуі мүмкін; тұрақсыз sawtooth режимі температура немесе tuning мәселесін көрсетуі ықтимал. Нақты электр дизайнын білікті маман бағалайды, ал сатып алу командасы өлшенген профильді соған береді.
J/TH есептегенде бір уақыт терезесінің қуаты мен тиімді хэшрейті қолданылсын. Номинал TH/s-ті нақты қуатпен бөлу салыстыруды бұрмалайды. Pool-side hashrate қысқа терезеде құбылуы мүмкін, сондықтан machine-side және pool-side метриканы қатар сақтап, ұзақ жеткілікті кезең қолданыңыз.
Қуат айырмасы тек электр шотына емес, алаң сыйымдылығына әсер етеді. Бір құрылғыдағы шағын W айырмасы жүз құрылғыда transformer, PDU және cooling жүктемесін өзгерте алады. Дегенмен nominal санды жай көбейтіп электр жабдығын таңдамаңыз; diversity, continuous load, harmonics және жергілікті талаптарды электр инженері есептейді.
Хэшрейт сапасын талдау
Бір экрандағы «average hashrate» жеткіліксіз. Қабылдауда nominal, machine-reported, pool-side accepted және rejected үлесін ажыратыңыз. Machine жоғары сан көрсетіп, pool accepted төмен болса, желі, clock, stale share немесе пул конфигурациясы тексеріледі. Құрылғыны тек machine интерфейсімен қабылдау өндірістің шынайы нәтижесін асырып көрсетуі мүмкін.
Әр hashboard нәтижесі бөлек қаралсын. Жалпы хэшрейт шек ішінде болғанымен, бір board әлсіз болса, қалған board уақытша орнын толтыруы немесе ақау кейін күшеюі ықтимал. Chip error, температура айырмасы және board detection оқиғаларын log-пен байланыстырыңыз.
Variance шегі алдын ала белгіленсін. Ол өндіруші жариялаған tolerance, тест ортасы және шартқа сүйенуі керек. Тесттен кейін қолайлы диапазон ойлап табу — acceptance bias. Бір құрылғы fail болғанда оны қайта жүктеп, жақсы бес минутты таңдау орнына толық run тарихын сақтаңыз.
Pool luck немесе қысқа share терезесі әсерін азайту үшін жеткілікті уақыт пен бірнеше дерек көзі қолданыңыз. Дегенмен ешбір тест болашақ табысты кепілдемейді: network difficulty және BTC бағасы құрылғы сапасынан бөлек өзгереді. Acceptance тек сатып алынған жабдықтың келісілген техникалық күйін тексереді.
Кепілдік пен жөндеу жолын нақтылау
«Бір жыл кепілдік» сөзі бес сұраққа жауап бермесе, жеткіліксіз: мерзім қай күннен басталады, кімге тиесілі, қай ақау қамтылады, қай жерге жіберіледі және логистиканы кім төлейді. Өндіруші саясаты мен reseller шарты сәйкес болмауы мүмкін; нақты мәміледе шарттың басымдығын заң маманы тексерсін.
Serial number бойынша қалған кепілдікті жазбаша растаңыз. Қолданылған құрылғыда invoice немесе жөнелту күні жоқ болса, кепілдікті бағаға қоспаңыз. Refurbished сөзі де стандарт емес: кім жөндеді, қандай бөлшек ауысты, burn-in қанша болды және жаңа кепілдік бар ма — жеке сұралады.
Жөндеу turnaround-ы тек сервис орталығындағы күн емес. Диагностика, рұқсат, кеден немесе тасымал, кезек, қайта жөнелту және қайта тест бар. Сондықтан экономикада warranty repair тегін болса да downtime және логистика резерві қалады.
Local repair қолданылса, техникалық мүмкіндік пен бөлшек traceability тексеріледі. Қате немесе белгісіз бөлшек, рұқсатсыз firmware және нашар soldering келесі ақауды тудыруы мүмкін. Жөндеуден келген құрылғы бастапқы acceptance-тің қысқартылған нұсқасынан қайта өтсін.
Төлемді қабылдау нәтижесіне байланыстыру
Толық алдын ала төлем сатып алушының fail handling ықпалын азайтады. Төлем кезеңдерін мәміле тәуекелімен байланыстырыңыз: құжат және serial list, sample тексеруі, жөнелту, physical arrival, technical acceptance және exception жабылуы. Нақты пайыздарды тараптар мен заң маманы бекітеді; басты қағида — соңғы маңызды төлем дәлелденген қабылдаудан бұрын кетпеуі.
Escrow немесе өзге қорғау құралы қолданылса, оның нақты шарты мен дауды шешу тәртібін түсініңіз. «Қауіпсіз төлем» маркетинг сөзі ақша қай жағдайда босатылатынын көрсетпейді. Қай құжат trigger болады, инспекцияға қанша уақыт беріледі, дау кезінде кім шешеді және қандай юрисдикция қолданылады — шартта көрінуі керек.
Төлем алушы шоттағы сатушы субъектісімен сәйкес болсын. Үшінші тұлғаға төлем сұралса, құқықтық байланыс пен негізін құжатсыз қабылдамаңыз. Криптоактивпен төлем жасау ұсынылса, қайтарым, баға бекіту, transaction дәлелі, бухгалтерлік және заңдық салдар алдын ала тексеріледі; қайтарылмайтын төлем әдісі ақаулы партия тәуекелін өсіреді.
Барлық банк немесе transaction дерегін сатып алу папкасында сақтаңыз, бірақ оны мақалаға, скриншотқа немесе сыртқы чатқа шығармаңыз. Аккаунт, әмиян, email және ішкі URL сияқты сезімтал ақпарат редакциялануы керек.
Pilot партиядан кейін экономикасын қайта есептеу
Сатып алу комитеті scale шешімін бастапқы каталог дерегімен емес, pilot фактпен қайта қарауы керек. Нақты қабырға қуаты, pool-side hashrate, uptime, rejected share, температура, auxiliary load, оператор уақыты және алғашқы жөндеу оқиғалары cost model-ге енгізіледі.
Бастапқы және пилот арасындағы айырманы үш топқа бөліңіз. Біріншісі — құрылғы айырмасы: қуат, хэшрейт немесе stability. Екіншісі — алаң айырмасы: airflow, network, PDU, температура. Үшіншісі — процесс айырмасы: мониторинг, spare, response және персонал. Бұл жіктеу мәселені қате тарапқа жүктемеуге көмектеседі.
Scale алдында capacity қайта тексеріледі. Pilot бірнеше ASIC-пен жақсы жұмыс істесе де, көп құрылғы қосылғанда hot spot, network congestion, transformer немесе персонал шегі пайда болуы мүмкін. Инфрақұрылымның headroom-ы нақты инженерлік есеппен расталсын.
Экономикалық қайта есептеуде BTC бағасын pilot кезінде өскені үшін ғана жоғары тұрақты болжамға ауыстырмаңыз. Сақтық сценарийі, difficulty өсуі, жөндеу және қалдық құн бірге жаңартылсын. Егер жаңа нақты дерек сатып алу тезисін нашарлатса, pilot-тың мақсаты орындалды: ол үлкен қателікті ерте көрсетті.
Қабылдаудан кейінгі 30 күндік baseline
Техникалық қабылдау аяқталған соң әр құрылғы үшін өндірістік baseline жасаңыз. Алғашқы 30 күн ішінде күндік accepted hashrate, қуат, температура, restart, rejected share және downtime сақталады. Ерекше оқиғалар — желі жұмысы, жоспарлы электр үзілісі, firmware өзгеруі — дерекпен бірге белгіленеді.
Baseline партия медианасын және әр құрылғының ауытқуын көрсетеді. Бір ASIC тұрақты түрде нашар болса, оны «орташа жақсы» партияның ішінде жасырмаңыз. Ерте ақауды кепілдік мерзімі мен шарттағы notification deadline өтпей тұрып тіркеу маңызды.
30 күндік review-де сатып алу requirement sheet-пен қайта салыстырылады. Қай талап нақты өндірісте маңызды болды, қайсысы артық немесе өлшеуге келмеді, келесі RFP-де не өзгеруі керек — жазылады. Бұл құжат келесі сатып алуға арналған білім базасы болады.
Asset register, acceptance evidence, repair log және cost model бір serial арқылы байланыссын. Сонда «қай модель жақсы?» деген жалпы пікірдің орнына нақты партияның толық өмірлік дерегі пайда болады. Келесі шешім сатушы уәдесіне емес, өз алаңыңыздағы өлшенген нәтиже мен құжатталған шығынға сүйенеді.
Сатып алу комитетіне арналған соңғы шешім парағы
Соңғы парақ бір бетте қорытынды беруі мүмкін, бірақ оның артында тексерілетін қосымшалар тұрады. Бірінші бөлімде ұсыныс: модель, саны, күйі, сатушы, толық жеткізілген баға және төлем кезеңдері. Екінші бөлімде must талаптарының pass/fail кестесі. Үшінші бөлімде базалық, сақтық және стресс экономикасы. Төртінші бөлімде негізгі бес тәуекел, owner және mitigation. Бесінші бөлімде шешім мен қайта қарау trigger-і.
Комитетке тек орташа өтелу санын бермеңіз. Ең нашар қабылданатын сценарийде cash burn, қосымша инфрақұрылым, бір ірі жөндеу және төмен қалдық құн қандай екенін көрсетіңіз. Сонымен қатар ұсыныстан бас тартудың құнын да жазыңыз: жоғалған мүмкіндік бар ма, әлде капиталды сақтау жақсы ма.
Мүдделер қақтығысы ашық көрсетілсін. Сатушы комиссиясы, referral, қызмет көрсету шарты немесе басқа ынталандыруы бар адам техникалық немесе қаржы қорытындысына әсер етсе, комитет оны білуі керек. Осы сайттағы Binance шақыруы ASIC сатушы бағалауына қатысы жоқ; оны құрылғы экономикасына кіріс ретінде қосуға болмайды.
Қорытынды төрт нұсқаның біреуі болсын: толық мақұлдау, шектеулі pilot, нақты шарт орындалғанша күту немесе бас тарту. Әр шешімнің жарамдылық мерзімі болады. Баға, модель нұсқасы, жеткізу күні, электр шарты немесе партия құрамы өзгерсе, ескі мақұлдауды автоматты түрде қолданбаңыз — шешімді жаңартыңыз.
Сатушыны техникалық ұсыныстан бөлек тексеру
Жақсы техникалық сипаттама сатушының мәмілені орындайтынын дәлелдемейді. Vendor due diligence бөлек ағын болуы керек. Заңды атау, тіркеу дерегі, қол қою өкілеттігі, төлем шоты, қоймаға қатысы, бұрынғы жеткізілім және дау байланысы тексеріледі. Қай құжат қажет екенін мәміле көлемі мен қолданылатын құқыққа сай заң және compliance маманы анықтайды.
Email домені мен банк дерегі ұсыныс барысында өзгерсе, оны кәдімгі түзету деп қабылдамаңыз. Белгілі контакт арқылы бөлек арнамен қайта растаңыз. Шоттағы бір әріп айырмасы, асығыс төлем талабы немесе «бүгін соңғы күн» қысымы — тексеруді қысқартуға емес, күшейтуге себеп.
Reference сұралса, сатушы таңдаған бір клиенттің мақтауы жеткіліксіз. Ұқсас көлем, ұқсас модель және жақын мерзімдегі жеткізілім туралы құрылымдалған сұрақ қойыңыз: уақытында келді ме, serial list сәйкес болды ма, fail handling қалай орындалды, кепілдік кезінде кім жауап берді. Reference жеке ақпаратын рұқсатсыз жарияламаңыз.
Сатушының техникалық командасы мен сату командасының уәдесі бір құжатқа түсуі керек. Чатта берілген қосымша хэшрейт, «тегін жөндеу» немесе ерекше қабылдау шарты келісімшартта болмаса, шешімге кірмейді. Соңғы commercial offer, technical appendix және contract арасында қайшылық болса, қол қоюға дейін түзетіледі.
Мәміле кейін делдал немесе басқа қойма арқылы орындалатыны белгілі болса, ownership және liability тізбегін қайта тексеріңіз. «Сол топтың компаниясы» немесе «серіктес қойма» деген ауызша түсініктеме ақау кезінде кімге талап қойылатынын анықтамайды.
Жеткізу мен қойма қабылдауын жоспарлау
ASIC сатып алу тестпен ғана емес, логистикамен де бұзылады. Қаптама өлшемі, жалпы салмақ, pallet саны, тиеу техникасы, қойма уақыты және климат жағдайы алдын ала жоспарланады. Ылғал, конденсат немесе суықтан жылы бөлмеге бірден кіргізу электрондық жабдыққа тәуекел тудыруы мүмкін; нақты acclimatization тәртібін өндіруші және логистика маманы белгілейді.
Incoterm немесе жеткізу шарты атауын білу жеткіліксіз. Кім экспорт құжатын дайындайды, сақтандыруды кім алады, тәуекел қай нүктеде өтеді, кеден және соңғы mile кімде, кешіккенде не болады — шартта түсінікті болуы керек. Мақала құқықтық түсіндіру бермейді; нақты мәмілені кәсіби маман тексереді.
Carrier келгенде seal, pallet және package count тіркелсін. Сыртқы зақым driver кеткенге дейін актіге түседі. Қорап ашылғанда құрылғы serial list-пен сканерленіп, күйі белгіленеді. Қоймадағы қозғалыс кезінде сериялық нөмір жоғалса, кейін сатушыға нақты ақауды байланыстыру қиындайды.
Тест кезегін тәуекелге қарай қойыңыз. Сыртқы зақым белгісі бар, sample партиясына кіретін немесе warranty notification мерзімі қысқа құрылғылар алдымен тексеріледі. Қалған құрылғы secure және құрғақ жерде, белгіленген күйде сақталады. «Келді» және «қабылданды» статустары asset register-де бөлек болсын.
Қаптама мен accessory де саналады: power cable, rail немесе өндіруші нақты комплектке енгізген өзге бөлік. Жетіспеген accessory-ді кейін ұсақ шығын деп қарау жүз құрылғыда үлкен кідіріс тудыруы мүмкін. Комплект тізімі ұсыныс пен өндіруші құжатынан алынады.
Модель аралас фермаға арналған шешім
Әртүрлі ASIC моделі бағаны немесе жеткізу жылдамдығын жақсартуы мүмкін, бірақ операциялық күрделілікті өсіреді. Әр модельге бөлек firmware, monitoring шаблоны, PSU, кабель, spare, жөндеу нұсқаулығы және температура baseline қажет болуы ықтимал. Осы күрделілік ақшаға айналдырылмаса, арзан ұсыныс жалған үнем болып көрінеді.
Модель санын шектеу үшін platform cost есептеңіз. Жаңа модельді енгізуге инженер уақыты, quarantine тесті, dashboard, alert, spare starter kit, құжат және оқу қажет. Бұл бір реттік шығын. Кейін тұрақты шығын ретінде қосымша қойма, жаңарту, incident response және vendor management қалады.
Екі модельдің электр тиімділігі әртүрлі болса, бір rack немесе бір PDU ішінде capacity жоспарлау күрделенеді. Airflow және exhaust температурасы да әртүрлі болуы мүмкін. Rack картасында нақты құрылғы қуаты мен жылуы көрсетілсін; «әрқайсысы шамамен бірдей» деген жорамалға сүйенбеңіз.
Модель араластырудың пайдалы жағы да бар: бір firmware немесе өндіріс ақауы бүкіл фермаға бірдей әсер етпеуі мүмкін, supply тәуекелі бөлінеді. Бірақ әртараптандыру тек команда әр платформаны қауіпсіз басқара алса құнды. Қолдау қабілеті жоқ күрделілік resilience емес.
Scale шешімінде жаңа модельдің marginal пайдасын есептеңіз. Оның J/TH артықшылығы platform cost, қосымша spare және күтілетін downtime-ды өтей ме? Егер жоқ болса, стандартталған аз модель операциялық тұрғыда жақсы болуы мүмкін.
Даулы қабылдау жағдайын басқару
Тест нәтижесі сатушы уәдесінен төмен болса, эмоциялық чатқа көшпей, evidence package жасаңыз. Онда шарттағы шек, нақты serial, тест әдісі, уақыт, орта, firmware, machine log, pool-side дерек, power reading және қайталама тест болады. Сезімтал token, аккаунт және ішкі URL сыртқа жіберер алдында жасырылады.
Сатушы remote диагностика сұраса, оған production credential бермеңіз. Қолжетімділік ұйымның қауіпсіздік саясатына сай уақытша, шектеулі және жазылатын арнамен беріледі немесе экран/лог арқылы орындалады. Сатушының permanent access қалдыру талабы reject белгісі болуы мүмкін.
Қайталама тест бастапқы әдісті мүмкіндігінше сақтасын. Шарттарды өзгертіп, жақсы нәтиже іздеу dispute-ті шешпейді. Егер сатушы басқа firmware немесе режим ұсынса, ол бөлек run ретінде белгіленеді және кепілдікке әсері жазбаша расталады.
Коммерциялық шешім техникалық фактіні өзгертпеуі керек. Discount берілсе, құрылғы «pass» болып кетпейді; ол техникалық fail немесе conditional pass күйінде қалып, экономикалық қабылдау бөлек негізделеді. Қауіпсіздік немесе сәйкестік мәселесін баға жеңілдігімен жабуға болмайды.
Дауды шешу мерзімі, құрылғының кімде сақталатыны, тасымал және insurance жауапкершілігі шарттан алынады. Команда барлық exception жабылмайынша disputed құрылғыны өндірістік fleet-ке араластырмасын.
Ресми және бастапқы дереккөздер
- BITMAIN: S21 Pro ресми сипаттамасы
- BITMAIN: S21 XP орнату нұсқаулығы
- BITMAIN: өнім кепілдігі
- Canaan: Miner Log Technical Guidance
- Bitcoin әзірлеуші нұсқаулығы: Mining
- Schneider Electric: data center power sizing құралы
Соңында, таңдау кестесін тексерілетін procurement record ретінде сақтаңыз: әр сан қай құжат версиясынан, қай тесттен және қай күннен келгені көрінсін. Жақсы ASIC — каталогта ең жарқын модель емес, сіздің электріңізде, температураңызда, жөндеу мүмкіндігіңізде және сақтық табыс сценарийіңізде тұрақты жұмыс істейтін құрылғы.