Buzz Mesh: যখন কমিউনিটি নিজেই মডেল চালায়

কয়েক সপ্তাহ আগে আমি আমাদের চারপাশে অব্যবহৃত কম্পিউটিং ক্ষমতা নিয়ে লিখেছিলাম। ধারণাটি ছিল কম্পিউটের একটি smart grid: ব্যক্তি, দল বা আঞ্চলিক কমিউনিটি স্বেচ্ছায় তাদের খালি ক্ষমতা দেয়, অন্যরা সেটি ব্যবহার করে, আর প্রতিটি AI অনুরোধ একই বড় provider-দের data center-এ যেতে বাধ্য হয় না।

তখন এটি মূলত একটি architecture idea ছিল। Buzz এখন দেখাচ্ছে এর প্রথম বাস্তব উপাদান কেমন হতে পারে। প্রকল্পটি মানুষ ও AI agent-দের workspace, Nostr identity এবং কমিউনিটির compute pool-কে একত্র করে। একজন সদস্য local model দেন, অন্য সদস্যদের agent সেটি ব্যবহার করে। ভবিষ্যৎ পরিকল্পনায় একাধিক device এমন একটি model-এর আলাদা অংশও রাখতে পারে যা একক machine-এ ধরে না।

এটি আমাদের আগের ভাবনার খুব কাছাকাছি। কিন্তু Buzz এখনো কোনো বিশ্বব্যাপী AI supercomputer নয়, আর খালি RAM জাদুর মতো shared memory হয়ে যায় না। এটি প্রথমে আস্থাভিত্তিক একটি ছোট cell তৈরি করে। সম্ভবত এটিই বেশি যুক্তিসঙ্গত সূচনা।

Buzz আসলে কী

Buzz হলো Jack Dorsey পরিচালিত Square-এর পেছনের কোম্পানি Block-এর open-source project। একে শুধু “Jack Dorsey-এর নতুন app” বলা ঠিক নয়। এটি Block project হিসেবে তৈরি হচ্ছে এবং public source code GitHub-এ Apache 2.0 license-এ পাওয়া যায়।

প্রথম দেখায় Buzz-কে Slack, GitHub এবং agent platform-এর মিশ্রণ মনে হয়। মানুষ ও AI agent একই channel-এ কাজ করে, task নিয়ে আলোচনা করে, code পরিচালনা করে এবং workflow চালায়। প্রতিটি agent নিজস্ব cryptographic identity ও সীমিত permission পায়। ফলে কোন ব্যক্তি action অনুমোদন করেছেন এবং কোন agent সেটি চালিয়েছে, তা আলাদা করে বোঝা যায়।

এটি শুধু cosmetic user management নয়। অনেক system-এ bot একটি shared service account বা অতিরিক্ত ক্ষমতাসম্পন্ন API key ব্যবহার করে। পরে জানা যায় “automation” কিছু করেছে, কিন্তু কোন instance কোন নির্দেশে করেছে তা স্পষ্ট থাকে না। Buzz authorization এবং authorship আলাদা করে দৃশ্যমান করতে চায়।

Workspace self-host করা যায়। প্রকাশিত architecture-এ রয়েছে Buzz Relay, event ও search-এর জন্য PostgreSQL, Pub/Sub ও presence-এর জন্য Redis এবং media-র জন্য S3-compatible storage। পরিচালনার বাস্তবতা লুকিয়ে রাখলে decentralization বেশি বিশ্বাসযোগ্য হয় না।

Nostr হলো ভিত্তি

Nostr-এর অর্থ Notes and Other Stuff Transmitted by Relays। User cryptographic key pair রাখে, event sign করে এবং relay-তে publish করে। Client এক বা একাধিক relay দিয়ে প্রয়োজনীয় event subscribe করে।

Event-এ sender-এর public identity, timestamp, type, content, reference ও signature থাকে। Private key user-এর কাছে থাকে; public key identity ও verification-এর জন্য ব্যবহৃত হয়। Nostr secp256k1-এ Schnorr signature ব্যবহার করে, যে elliptic curve Bitcoin-এও কেন্দ্রীয়।

Signed log, blockchain নয়

Nostr blockchain নয়। এখানে mining, global consensus বা এমন single chain নেই যার জন্য সব relay অপেক্ষা করে। Relay নিজস্ব rule অনুযায়ী event গ্রহণ ও সংরক্ষণ করে এবং client-কে দেয়। অন্য relay-তে একই বা ভিন্ন event থাকতে পারে।

Buzz message, reaction, agent task, workflow step এবং Git event-এর জন্য এই model ব্যবহার করে। Community-তে relay কেন্দ্রীয় source-ই থাকে: membership যাচাই করে, event বিতরণ করে এবং state ধরে রাখে। Protocol identity ও format portable করে, কিন্তু operator, database, backup, retention rule বা failure risk সরায় না।

Signature প্রমাণ করে কোন key event sign করেছে, কিন্তু relay সেটি চিরকাল দেবে এমন নিশ্চয়তা দেয় না। Self-hosting-এর জন্য backup, export, monitoring ও সঠিক key management দরকার। হারানো private key সাধারণ password নয় যা administrator reset করতে পারেন; চুরি হওয়া key attacker-কে বৈধভাবে সেই identity ব্যবহার করতে দেয়।

Bitcoin-এর সঙ্গে সম্পর্ক

Nostr সাংস্কৃতিক ও প্রযুক্তিগতভাবে Bitcoin community-র কাছাকাছি। NIP-57 Lightning Zaps সংজ্ঞায়িত করে, যার মাধ্যমে client ব্যক্তি বা event-কে satoshi পাঠাতে এবং payment receipt-কে event হিসেবে দেখাতে পারে।

তবুও Bitcoin বাধ্যতামূলক নয়। Nostr blockchain বা coin ছাড়াই চলে। Buzz Shared Compute-ও এখন এমন open market নয় যেখানে অচেনা computer প্রতি token-এ satoshi আয় করে। Capacity কমিউনিটির মধ্যে স্বেচ্ছায় share হয়। Lightning ভবিষ্যতে compensation বা quota-তে সহায়তা করতে পারে, কিন্তু বিদ্যুৎ, ক্ষয় ও operation-এর অর্থনীতি এখনো সমাধান করে না।

Shared Compute যেভাবে কাজ করে

Buzz Mesh community membership-কে compute pool access-এর সঙ্গে যুক্ত করে। সদস্য sharing চালু করেন, hardware-এর উপযোগী model বেছে নেন এবং অন্যদের inference দেন। Agent কোনো external AI service-এর API key ছাড়াই “Buzz shared compute” provider হিসেবে নির্বাচন করতে পারে।

Relay trust ও coordination layer হিসেবে কাজ করে। সে জানে কারা member এবং কোন node model দিচ্ছে। আসল request machine-গুলোর মধ্যে সরাসরি ও encrypted অবস্থায় যায়। Prompt Buzz server দিয়ে যায় না, কিন্তু requester-এর device ছেড়ে অন্য সদস্যের machine-এ পৌঁছায়।

Transport encryption পথকে সুরক্ষিত করে, endpoint-কে অন্ধ করে না। অন্যের hardware ব্যবহার করতে তার operator-কে বিশ্বাস করতে হয়। Mesh vision স্পষ্টভাবে বলে: community ততটাই private, যতটা তার member-রা বিশ্বাসযোগ্য।

Remote inference মানেই distributed inference নয়

সহজ ক্ষেত্রে পুরো model একটি শক্তিশালী workstation-এ চলে, আর অন্য device request পাঠায়। Network দিয়ে মূলত prompt, token এবং protocol overhead যায়; calculation একটি machine-এই থাকে।

কঠিন ক্ষেত্রে model কয়েকটি computer-এ ভাগ হয়। প্রতিটি node কিছু weight বা calculation ধরে এবং token তৈরির সময় intermediate result বারবার আদান-প্রদান করে। Bandwidth, latency, topology ও failure সরাসরি speed নির্ধারণ করে।

Buzz দুই দিকই বর্ণনা করে। Public development guide app থেকে local বা remote inference পর্যন্ত বাস্তব পথ দেখায়। এক model কয়েকটি device-এ ভাগ করা Mesh vision-এর অংশ: যুক্তিসঙ্গত লক্ষ্য, কিন্তু এখনো ইচ্ছামতো scale করা production platform নয়। কিছু function feature flag-এর পেছনে আছে।

Mac Studio cluster নেটওয়ার্ক সমস্যাটি দেখায়

NetworkChuck চারটি Mac Studio যুক্ত করেন, প্রতিটিতে 512 GB Unified Memory, অর্থাৎ GPU-accessible 2 TB local cluster। কিন্তু পাঁচ Mac-এর আগের পরীক্ষায় তাঁর তুলনা অনুযায়ী inference 91 শতাংশ ধীর হয়েছিল।

Video pipeline ও tensor parallelism-এর পার্থক্য ব্যাখ্যা করে। Pipeline-এ একটি Mac তার layer process করে ফল পরেরটিকে দেয়। বড় model ধরে, কিন্তু node-গুলো অপেক্ষা করে। Tensor-এ সব Mac একই layer-এ একসঙ্গে কাজ করে এবং অল্প data খুব ঘন ঘন বিনিময় করে। Latency তখন নির্ণায়ক।

NetworkChuck প্রায় 300 থেকে 3 microsecond-এ নামা দেখান। Llama 70B-তে output pipeline-এর প্রায় 5 tokens per second থেকে tensor ও RDMA-তে প্রায় 16 হয়। পুরো cluster 100 গুণ দ্রুত হয় না; connection latency প্রায় সেই factor-এ কমে, model throughput তিন গুণের একটু বেশি বাড়ে।

macOS 26.2 থেকে Thunderbolt 5-সহ Apple silicon Mac, RDMA over Thunderbolt সমর্থন করে। RDMA registered memory region-এর মধ্যে কম overhead-এ data সরায়; Apple এটি MLX Distributed ও JACCL-এর সঙ্গে সমন্বয় করেছে।

তবু physics বদলায় না। Apple minimum latency-এর জন্য fully meshed topology সুপারিশ করে: দুই Mac-এ এক link, তিনটিতে তিন cable এবং চারটিতে ছয়। পাঁচ node থেকে port limit-এর কারণে ring দরকার হতে পারে, তখন data intermediate node দিয়ে যায়। বর্তমান implementation সর্বোচ্চ দশ UC Queue Pairs এবং two-sided send/receive-এ সীমিত।

Community internet-এ আলাদা machine-এ কয়েকটি complete model দিতে পারে। কিন্তু Zurich, Berlin ও New York জুড়ে একটি model ভাগ করা অন্য সমস্যা। প্রতিটি hop token generation ধীর করে, আর একটি slow node পুরো pipeline থামাতে পারে।

RAM সরাসরি যোগ হয় না

Model weight, KV cache, runtime data এবং দীর্ঘ context-এর reserve কোথাও রাখতে হয়। দুই সদস্য 64 GB RAM-এ আলাদা model চালালে দুই inference node হয়, 128 GB shared memory-র এক machine নয়। কেবল real model sharding সীমা বদলায়, বিনিময়ে communication, complexity ও failure risk বাড়ে।

2026 সালে DRAM market-ও কঠিন। TrendForce তৃতীয় quarter-কে খুব tight বলেছে, আর AI server demand record price ধরে রেখেছে। Shared Compute existing hardware-কে বেশি উপযোগী করে, কিন্তু বেশি RAM-সহ নতুন local system সস্তা করে না।

আগে থেকেই থাকা তিন workstation share করা যুক্তিসঙ্গত হতে পারে। শুধু cloud bill এড়াতে তিনটি দামি machine কেনা খারাপ investment হতে পারে। বিদ্যুৎ, cooling, parts, internet, administration এবং outage risk হারিয়ে যায় না।

Buzz Mesh-এর সত্যিকারের ভালো দিক

Buzz-এর শক্তি নতুন distributed-inference technique নয়, existing component যুক্ত করা। Community-তে members, identities ও permissions আছে; agents এবং local models আগেই চলছে। Buzz sharing-কে product setting এবং compute-কে agent-এর স্বাভাবিক provider বানায়।

Trust zone-ও বাস্তবসম্মত: লক্ষ লক্ষ অচেনা পক্ষের বদলে আগে থেকেই একসঙ্গে কাজ করা মানুষ। Agency, small business, research project বা developer group-এর জন্য এটি anonymous GPU market-এর চেয়ে বাস্তব।

Model independence-ও সুবিধা। Open-weight model-এ weight, configuration ও runtime নিয়ন্ত্রণ করা যায়, কিন্তু “model-এর মালিকানা” shorthand। Open weights public domain নয়; license use, redistribution বা commercial operation সীমিত করতে পারে। Sovereignty মানে weight পাওয়া, license বোঝা, runtime নিয়ন্ত্রণ, data export এবং original provider ছাড়া operation।

যা এখনো সন্তোষজনক নয়

Compensation সমাধান হয়নি। Small team-এ voluntary sharing যথেষ্ট, কিন্তু একজন দশ user-এর hardware ও বিদ্যুৎ সবসময় দিলে limits, priorities, metrics এবং fair accounting লাগে। Nostr ও Lightning component দেয়, সম্পূর্ণ economy নয়।

Operations-ও প্রশ্ন: model ও license কে update ও verify করবে, কোন node sensitive prompt দেখবে, overload, sleep, চলন্ত notebook বা response-এর মাঝখানে computer বন্ধ হলে কী হবে। Cloud ব্যয়বহুল, কিন্তু এই বিরক্তিকর কাজের অনেকটাই নেয়।

Buzz arbitrary code নয়, model request forward করে। এটি ভালো boundary। তবুও prompt confidential হতে পারে, model manipulate করা যেতে পারে, agent অতিরিক্ত context পাঠাতে পারে। Membership access control, ভালো আচরণের guarantee নয়। Company-র classification, logging, quota, model approval, endpoint hardening এবং local-only job rule দরকার।

Buzz এখনো তরুণ। Public code, architecture ও concrete test path slide-এর চেয়ে বেশি, কিন্তু feature flag, দ্রুত release ও বদলাতে থাকা document প্রমাণ করে system চলমান। Non-critical data দিয়ে experiment ভালো; exit plan ছাড়া core process নির্ভর করা নয়।

বাস্তবে কী বাস্তবায়িত হচ্ছে

Buzz আগের compute smart grid পুরো তৈরি করে না, কিন্তু সবচেয়ে যৌক্তিক প্রথম layer দেয়: existing social trust structure-এর ওপর সীমিত ও voluntary compute cell।

Open market, stable credit, hardware attestation, independent verification এবং হাজার unknown node-এর operating model এখনো নেই। কিন্তু বোঝা যায় এমন interface ও immediate use case আছে: agent-এর model দরকার, member-এর computer আছে, relay coordinate করে এবং machine calculate করে।

ছোট circle reliably চললে quota, credit, Lightning payment, regional federation বা verifiable job পরে আসতে পারে। আগে ছোট circle-কে ভালোভাবে চলতে হবে।

এই লেখার ভিত্তি ও সীমা

আমি নিজে multi-computer setup-এ Buzz Mesh পরীক্ষা করিনি। বিশ্লেষণ public code, architecture, Mesh vision, development guide, Nostr specification এবং Apple-এর RDMA documentation-এর ওপর ভিত্তি করে, যা 21 আগস্ট 2026-এ যাচাই করা হয়েছে। Stability, throughput ও real load নিয়ে বক্তব্য আমার measurement নয়।

তারপরও distributed compute idea কীভাবে ব্যবহারযোগ্য product হতে পারে, Buzz তার সবচেয়ে স্পষ্ট উদাহরণ। এখনো ছোট, প্রাথমিক এবং অসমাধান করা economy-সহ, কিন্তু আর শুধু theory নয়।

পরেরবার পর্যন্ত,
Joe