მოდელი მოწყობილობაზე და ობიექტების პარკი: განახლება firmware-ივით და არა ჩატივით

Red Hat-მა ათასობით მოწყობილობაზე მოდელების მართვაზე საუბარი დაიწყო. Hugging Face-მა ბიბლიოთეკის 1.0 ვერსია გამოუშვა, რომლითაც iPhone-ზე ან Mac-ზე აპლიკაცია ლოკალურ მოდელთან მუშაობს. NVIDIA-მ აჩვენა, როგორ დავაკავშიროთ რვა სამაგიდო DGX Spark, n8n-მა კი ერთ ასეთ ყუთზე პატარა კომპანიისთვის მოდელების მთელი ნაკრები ააწყო ღრუბლოვანი API-ის გარეშე. რამდენიმე ობიექტის მქონე ბიზნესის მფლობელისთვის მთავარი კითხვა ასე ჟღერს: ვინ და როგორ განაახლებს მოდელს თითოეულ მათგანზე.

რა გამოვიდა

Red Hat-მა 20 ოქტომბერს სტატია გამოაქვეყნა MLOps-ზე edge AI-სთვის, ანუ მოწყობილობებზე მომუშავე AI-სთვის. მას შემდეგ, რაც მოდელი ოპტიმიზებული და შეფუთულია, მართვის კითხვები რჩება. რომელი ვერსია სად მუშაობს და როგორ განვაახლოთ ის მთელ პარკზე ინციდენტის გარეშე. ჩემთან მხოლოდ სტატიის დასაწყისია, ამიტომ Red Hat-ის პასუხებს არ ვყვები.

Hugging Face-მა 20 ოქტომბერს გამოუშვა AnyLanguageModel 1.0, Apple Foundation Models ფრეიმვორკის შემცვლელი. ცვლი იმპორტის სტრიქონს, და სესიის იგივე კოდი მუშაობს სისტემურ მოდელთან, ღია მოდელებთან llama.cpp-ით, MLX-ით და Core ML-ით, ან ღრუბლოვან პროვაიდერებთან, რომელთა შორისაა OpenAI, Anthropic, Gemini და Ollama. ინსტრუმენტების გამოძახება და სტრუქტურირებული გამოსავალი ყველა პროვაიდერთან მუშაობს. API გასაღები ფუნქციით ეთითება და არა სტრიქონით, რომ აპლიკაციამ საკუთარი სერვერიდან ხანმოკლე ტოკენები მიიღოს. დასაწყებად დასახელებულია Gemma 4 E2B, დაახლოებით 3,4 GB, და LFM2.5 2.6B, დაახლოებით 1,7 GB; ორივე iPhone-ზე ეტევა. Qwen3.8 27B დაახლოებით 16 GB-ს იკავებს და 32 GB მეხსიერების მქონე Mac-ს მოითხოვს.

NVIDIA-მ 22 ოქტომბერს GTC Berlin-ზე გამოაცხადა, რომ რვამდე DGX Spark კვანძის დაკავშირება შეიძლება მოდელებისთვის, რომლებსაც ასობით გიგაბაიტი მეხსიერება სჭირდება. ეს ანონსია, და დეტალები მასში ცოტაა.

n8n-მა 19 ოქტომბერს აჩვენა, როგორ შეიძლება ერთ DGX Spark-ზე 128 GB საერთო მეხსიერებით პატარა კომპანიის სამუშაო პროცესების ყველა მოდელის შენახვა: ჩატი და მონაცემების ამოღება Qwen3.6-35B-A3B-ზე, ემბედინგები, რერანკერი, Whisper მეტყველებისთვის, GLM-OCR დოკუმენტებისთვის, სურათების გენერაცია და მეტყველების სინთეზი. ყველაფერი ერთი OpenAI-თავსებადი მისამართის უკან დგას LiteLLM-ით, ყოველ გუნდს თავისი გასაღები აქვს. ავტორი წერს, რომ კლინიკას, იურიდიულ ფირმას ან ბუღალტერს ხშირად არ შეუძლია კლიენტების მონაცემები ღრუბლოვან API-ში გაგზავნოს, და ციფრებიც მოჰყავს: 120 ტოკენი წამში ერთი მომხმარებლისთვის და ჯამში 359 რვაზე. ჩემთვის ყველაზე სასარგებლო ნაწილი დისციპლინაზეა. ყოველი მოდელი ერთხელ ჩამოიტვირთება და ზუსტი კომიტი models.lock-ში იწერება, კონტეინერები ვერსიით მაგრდება, ხოლო გაშვებამდე ამოწმებენ, vLLM-ის რომელი ვერსიაა იმიჯის შიგნით. ავტორთან nightly-ტეგი ხუთი თვის წინანდელი აღმოჩნდა vLLM 0.19-ით, და მოდელი არ ჩაიტვირთა შეცდომით, რომელიც დაზიანებულ ჩეკპოინტს ჰგავდა.

მაგალითი: ფერმა ორ ობიექტზე

ავიღოთ ფერმა ორი ობიექტით და კონტროლერებით თითოეულზე. ვთქვათ, ობიექტებზე დგას პატარა მოდელი, რომელიც ფოტოთი მცენარეების დაავადებას ადგენს. ერთ ობიექტზე ის განაახლეს, მეორეზე არა. ერთი თვე ორივე ობიექტი აგზავნის „ყველაფერი რიგზეა“, მაგრამ სხვადასხვა წესით. შეუსაბამობას ერთი თვის შემდეგ იპოვიან, და ვერავინ გაიხსენებს, რომელი ვერსია სად იდგა და რომელი დღიდან.

მოწყობილობაზე მდგომ მოდელს firmware-ივით უნდა მიხედოთ: ვერსიის ნომრით, ყოველ მოწყობილობაზე დაყენების თარიღით, უკან დაბრუნების გეგმით. ღრუბელში ჩატს თქვენ მაგივრად აახლებენ, თქვენს ობიექტზე მოდელს კი თქვენ აახლებთ.

როგორ მაქვს ეს მოწყობილი

2023 წლიდან აშშ-ში ჰიდროპონიკური ფერმის სერვერსა და ქსელზე ვაგებ პასუხს. აპარატურას იქ 25 კონტროლერი მართავს Raspberry Pi-ის ბაზაზე, 2 ობიექტზე. ობიექტების ქსელებს საჯარო IP არ აქვს, ამიტომ reverse proxy, NAT, firewall და VPN დავაყენე. გამოვიდა ერთი ქსელი, რომელშიც Google Cloud-ში Debian-ზე მდგომი სერვერი MariaDB-ით ყველა კონტროლერს ხედავს. კონტროლერებიდან მონაცემები ბაზაში მოდის, ბრძანებები კი უკან მიდის: მორწყვა, ტუმბოები.

კონტროლერებზე სისტემა დახურულია. REST API მას არ ჰქონდა, მხოლოდ ლოკალური სოკეტები. გავარკვიე, როგორ არის ეს ინტერფეისი მოწყობილი, და მის საფუძველზე სერვერთან ინტეგრაცია ავაწყე; ეს კავშირი ახლაც მუშაობს. ავტომატიზაციის ლოგიკასა და ინტერფეისს სხვა გუნდი აკეთებს, ჩემზეა ქსელი, ბაზა, განახლებები და მხარდაჭერა. თავად ამას DevOps-ს ვუწოდებ.

ამ სამუშაომ განახლებების წინასწარ დაგეგმვა მასწავლა: განახლებებსა და გამართვას დისტანციურად ვაკეთებ, იმავე ქსელით, ერთი სერვერიდან. ფერმაში ობიექტზე მოდელი რომ დასჭირდეს, მას იმავე გზით ვუძღვებოდი, როგორც კონტროლერების დანარჩენ პროგრამულ უზრუნველყოფას: ვერსია, თარიღი, მოწყობილობა, უკან დასაბრუნებელი გზა. ამ სიახლეების აპარატურა და სტეკები ჩემთან არ შემიმოწმებია.

რას გავაკეთებდი

ერთ სერვერს გამოვყოფდი, რომელმაც იცის, მოდელისა და კონტეინერის რომელი ვერსია დგას თითოეულ მოწყობილობაზე. ფერმაში კონტროლერების მონაცემები ისედაც ერთ სერვერზე მიდის MariaDB-ით; ვერსიების ჩანაწერს იქვე შევინახავდი.

ვერსიებს ფაილით დავამაგრებდი, როგორც n8n-ის models.lock, და მხოლოდ მისით გავუშვებდი. ტეგი latest ინტერნეტის გარეშე მდგარ ობიექტზე არაფერს ნიშნავს.

საფეხურებად განვაახლებდი: ერთი მოწყობილობა, ერთი ობიექტი, ყველა. საფეხურებს შორის ძველი და ახალი ვერსიის შედეგებს ერთსა და იმავე მონაცემებზე შევადარებდი.

უკან დაბრუნების გზას განახლებამდე შევამოწმებდი და არა ინციდენტის დროს.

გადავწყვეტდი, რას აკეთებს მოდელი ადგილზე და რა მიდის მაინც სერვერზე. ფოტოს ამოცნობა ობიექტზეც შეიძლება, გადაწყვეტილება კი იმაზე, რა ვუყოთ მცენარეების პარტიას, ჯობია იქ მივიღოთ, საიდანაც ორივე ობიექტი ჩანს.

დაკავშირებული მასალები

რატომ სჭირდება სისტემას საერთო ცენტრი, რომელიც მდგომარეობას ინახავს და დამუშავებას აკოორდინირებს, სტატიაში სერვერი: მონაცემები, წვდომა და პროცესის შესრულება დავწერე. მიმართულებები: სათბურებისა და ჰიდროპონიკის ავტომატიზაცია და აპარატურის მონიტორინგი და შეტყობინებები. თავად პროექტი: ჰიდროპონიკური ფერმა აშშ-ში: 25 კონტროლერი 2 ობიექტზე. იმავე თემაზე: როგორ ვირჩევ საკუთარ მოდელსა და API-ს შორის, რამდენი დაკვირვებადობა სჭირდება სისტემას ერთ სერვერზე და zero trust 30-კაციანი კომპანიისთვის. ადრე ვწერდი, რომ მოწყობილობაზე მოდელის გამოშვება უფრო მნიშვნელოვანია, ვიდრე ერთი სწრაფი პასუხი, და ანალიტიკაზე სამრეწველო არქივის გვერდით. თუ რამდენიმე ობიექტზე აპარატურა გაქვთ და იქ მოდელის დაყენებაზე ფიქრობთ, მომიყევით, რა დგას იქ უკვე და როგორ ახლდება ახლა. ამოცანის განხილვა.