Open-weight・Local AI・Edge AIとは何か｜量子化・GPUメモリ・実行環境から考えるAIモデルの配置設計

生成AIを利用する方法は、クラウド上のAIサービスへ質問を送信することだけではありません。

AIモデルの重みを取得し、自分のPCや社内サーバー、産業用コンピュータ、組込み機器などで推論を実行する方法もあります。

こうした技術を理解するための重要なキーワードが、Open-weight、Local AI、Edge AIです。

例えば、工場設備の異常検知を考えてみましょう。

設備のセンサーデータをクラウドへ送信し、AIに解析させる方法があります。

一方、工場内のPCで解析する方法や、設備に組み込まれた小型コンピュータで解析する方法もあります。

どれが適切かは、AIモデルの性能だけでは決まりません。

通信環境、応答時間、機密性、ハードウェア、保守性、コストなどの条件によって変わります。

本記事では、AIモデルの公開形態と実行環境を分離し、工学的な観点からAIシステムの配置設計を考えます。

今日の到達点

この記事では、次の5項目を理解することを目指します。

• Open-weightとOpen-sourceの違いを説明できる
• Local Inference、On-device AI、Edge AIを区別できる
• パラメータ数と量子化精度から、モデルの重み容量を概算できる
• Privacy・Latency・Cost・Hardwareから実行環境を選定できる
• 工場設備・設計端末・ソフトウェア開発に適したAI配置を設計できる

Open-weightとは何か

AIモデルの重みを公開する

Open-weightとは、学習済みAIモデルの重み（Weights）を利用者が取得できる形で公開することです。

ニューラルネットワークでは、学習によって大量のパラメータが調整されます。

例えば、単純なニューラルネットワークの一層を考えると、\[ \mathbf{y}=f(\mathbf{W}\mathbf{x}+\mathbf{b}) \]

と表現できます。

ここで、

• $\mathbf{x}$：入力ベクトル
• $\mathbf{W}$：重み行列
• $\mathbf{b}$：バイアス
• $f$：活性化関数
• $\mathbf{y}$：出力ベクトル

です。

大規模言語モデルでは、これに相当するパラメータが非常に大量に存在します。

学習済みの重みを取得できれば、対応する推論プログラムとハードウェアを用意することで、自分の環境でモデルを実行できます。

ただし、Open-weightだからといって、学習データや学習プログラムまで公開されているとは限りません。

Open-weightとOpen-sourceの違い

両者は混同されやすい用語です。

Open Source Initiativeが2024年に公開したOpen Source AI Definition 1.0では、AIシステムを利用・研究・改変・共有する自由が重視されています。

また、学習済みパラメータだけでなく、学習・実行に必要なコードや、学習データに関する十分な情報も対象になります。

したがって、重みをダウンロードできるという理由だけで、そのモデルを厳密な意味でOpen-source AIと断定することはできません。

参考：Open Source AI Definition 1.0

Open-weightでもライセンス確認は必要

Open-weightモデルには、Apache 2.0などの比較的自由度の高いライセンスで提供されるものがあります。

一方、独自ライセンスによって、利用・再配布・商用利用などに条件が設けられる場合もあります。

例えば、Llama 4は独自のLlama 4 Community Licenseを採用しています。

このライセンスには、一定規模を超えるサービスに対する追加条件などが含まれています。

参考：Llama 4公式Model Card

モデルを実務で採用する際には、最低限、商用利用、改変、再配布、派生モデル、利用制限、ライセンス表示義務を確認する必要があります。

Open-weightは技術的な公開形態であり、利用条件そのものを保証する言葉ではありません。

Cloud AI・Local AI・Edge AIの違い

Cloud Inference

Cloud Inferenceは、クラウド上のサーバーでAIモデルを実行する方式です。

一般的なAPI型AIサービスが代表例です。

User Application
       |
       v
    Internet
       |
       v
   Cloud API
       |
       v
   AI Model
       |
       v
    Response

利用者は大規模なGPUを所有する必要がありません。

一方、ネットワーク接続、API利用条件、サービス提供状況などに依存します。

Local Inference

Local Inferenceは、利用者が管理するPCやサーバーなどで推論を実行する方式です。

User Application
       |
       v
   Local API
       |
       v
   Local Model
       |
       v
    Response

モデルを自分のPCへ保存し、CPUやGPUを使用して推論できます。

ただし、Localという言葉は必ずしも個人用PCだけを意味しません。

社内ネットワークに設置した推論サーバーも、広い意味でローカル環境として扱われます。

On-device AI

On-device AIは、AIを利用する端末そのもので推論を実行する方式です。

例えば、スマートフォン内で音声認識や文章生成を実行する場合です。

Local Inferenceと重なる概念ですが、特に端末内での実行を強調します。

Edge AI

Edge AIは、データが発生する場所や利用される場所の近くでAI処理を実行する構成です。

例えば、工場設備の近くに設置した産業用PCで画像解析を行う場合です。

Camera / Sensor
       |
       v
  Edge Computer
       |
       v
    AI Model
       |
       v
 Analysis Result
       |
       v
  Control System

Edge AIは、必ずしも小型LLMを意味しません。

画像分類モデル、物体検出モデル、時系列異常検知モデルなども含まれます。

また、Edge AIであっても、モデルの更新やログ管理にクラウドを利用する構成があります。

AIの実行環境を比較する

この表は一般的な設計傾向を示したものであり、すべての製品に当てはまるわけではありません。

例えば、クラウドでも専用ネットワークや地域指定などの選択肢があります。

逆に、Local AIでも外部サービスへ通信するアプリケーションを組み合わせれば、完全なオフライン環境にはなりません。

2026年の代表的Open-weightモデル

2026年10月11日時点で公式情報を確認できた代表的なModel Familyを整理します。

Gemma 4

Gemma 4は、2026年4月に公開されたOpen-weightモデル群です。

E2B、E4B、12B、26B A4B、31Bなどのモデルがあり、DenseとMixture of Expertsの構成が含まれます。

小型モデルはモバイルやローカル環境での利用を想定しており、推論、コーディング、画像理解などに対応しています。

Gemma 4はApache 2.0で公開されています。

参考：Gemma 4公式Model Card

gpt-oss

gpt-ossは、2025年8月に公開されたOpen-weightのReasoning Modelです。

20Bと120Bのモデルがあり、Apache 2.0で提供されています。

20Bモデルは、比較的限られたメモリ容量での推論を考慮した構成です。

ただし、20Bという名称は総パラメータ規模を示すものであり、推論時にすべてのパラメータが同じように活性化されることを意味しません。

gpt-ossはMixture of Experts構成を採用しています。

参考：gpt-oss公式モデル情報

Qwen3

Qwen3は、複数のパラメータ規模と構成を持つModel Familyです。

Qwen3-8Bの公式Model Cardでは、Apache 2.0ライセンスが確認できます。

比較的小規模なモデルをローカルで利用する場合、検討対象となるファミリーの一つです。

ただし、同じファミリーでも、モデルの種類、推論形式、量子化版によって必要な環境は異なります。

参考：Qwen3-8B公式Model Card

Ministral 3

Ministral 3は、2025年12月に発表されたMistral 3ファミリーの小型モデル群です。

3B、8B、14Bが用意され、Base、Instruct、Reasoningなどのバリエーションがあります。

Apache 2.0で公開され、EdgeやLocal環境への配置が想定されています。

参考：Mistral 3公式発表（2025年12月2日）

Llama 4

Llama 4にはScoutやMaverickなどのモデルがあります。

Mixture of Expertsを採用し、テキストや画像を扱う構成です。

ただし、独自Community Licenseを採用しているため、Apache 2.0モデルと同一条件では扱えません。

また、モデルの総パラメータ数が大きいため、Local Deploymentでは必要なメモリ容量や推論環境を慎重に評価する必要があります。

モデル比較で重要なこと

ここで重要なのは、単純な性能ランキングを作らないことです。

実際の選定では、対象言語、必要な推論能力、対応する入力形式、ライセンス、ハードウェア、実測Latencyなどを評価します。

パラメータ数とモデル容量

パラメータ数とは何か

LLMの規模を表す際、7B、8B、20Bなどの表記が使われます。

BはBillion、つまり10億を意味します。

8Bモデルなら、約80億個のパラメータを持つことを示します。

ただし、MoEモデルでは総パラメータ数と、1回の推論で活性化されるパラメータ数を区別する必要があります。

また、モデル容量はパラメータ数だけでなく、数値の保存精度によって変わります。

FP32・FP16・INT8・INT4とは何か

数値表現の精度

ニューラルネットワークの重みは、数値として保存されます。

代表的な表現形式には、次のものがあります。

実際の量子化方式には、Scale、Zero Point、Group Sizeなどの追加情報が必要な場合があります。

そのため、INT4モデルのファイル容量が、必ずFP16の4分の1になるわけではありません。

モデル重み容量の概算

パラメータ数を $P$、1パラメータ当たりのビット数を $b$ とすると、重みデータの理論容量は、\[ M_{\mathrm{weight}}=\frac{P\times b}{8} \]

です。

単位はByteです。

例えば、8BモデルをFP16で保存する場合、\[ M_{\mathrm{weight}} = \frac{8\times10^9\times16}{8} \]\[ M_{\mathrm{weight}} = 16\times10^9\ \mathrm{Byte} \]

となります。

つまり、重みだけで約16 GBです。

同じ8Bモデルを理想的な4 bit表現で保存すると、\[ M_{\mathrm{weight}} = \frac{8\times10^9\times4}{8} \]\[ M_{\mathrm{weight}} = 4\times10^9\ \mathrm{Byte} \]

となります。

重みだけなら約4 GBです。

ここでのGBは10進単位です。2進単位では、それぞれ約14.9 GiB、約3.73 GiBに相当します。

8Bモデルの理論容量比較

これは、すべての重みを同一ビット数で保存すると仮定した概算です。

実際のモデルファイルには追加情報が含まれ、推論時には別のメモリも必要になります。

VRAMとRAMの違い

VRAM

VRAMは、GPUが利用するメモリです。

GPUへモデルを配置して推論する場合、モデル重みや計算用データを保持するために利用されます。

VRAM容量が不足すると、モデルをGPUへ完全に配置できない場合があります。

RAM

RAMは、CPU側のメインメモリです。

CPU推論や、GPUへ配置しきれないデータの保持に使用されます。

推論エンジンによっては、モデルの一部をGPUへ配置し、残りをCPU側で処理する構成も可能です。

ただし、CPUとGPUの間でデータ転送が発生するため、推論速度が低下する場合があります。

重み容量だけでは判断できない

実際の推論に必要なメモリは、次のように考えられます。\[ M_{\mathrm{required}} = M_{\mathrm{weight}} + M_{\mathrm{KV}} + M_{\mathrm{workspace}} + M_{\mathrm{runtime}} \]

ここで、

• $M_{\mathrm{weight}}$：モデル重み
• $M_{\mathrm{KV}}$：KV Cache
• $M_{\mathrm{workspace}}$：計算用作業領域
• $M_{\mathrm{runtime}}$：推論エンジンなどの管理領域

です。

この式は概念的なメモリ予算モデルです。実際にはメモリ共有や再利用もあるため、各項目が常に独立して確保されるわけではありません。

特にKV Cacheは、Context Lengthやモデル構造、同時実行数によって大きく変わります。

したがって、8Bモデルを4 bit量子化したからといって、4 GBのVRAMで必ず動作するわけではありません。

Quantizationとは何か

Quantizationは、モデルの数値表現を低精度化し、メモリ使用量や計算負荷を削減する技術です。

Post-training Quantization

学習済みモデルを、学習後に量子化する方法です。

比較的導入しやすい一方、量子化方法によっては精度が低下します。

Quantization-Aware Training

Quantization-Aware Training（QAT）は、量子化の影響を考慮して学習または追加学習を行う方法です。

2026年6月には、Gemma 4向けのQATモデルも公開されています。

参考：Gemma 4 QAT公式技術記事（2026年6月5日）

量子化のTrade-off

量子化には、次のような利点があります。

• モデルファイルを小さくできる
• VRAMやRAMの使用量を削減できる
• メモリ帯域が律速となる処理を高速化できる場合がある
• より小型のハードウェアへ配置できる可能性がある

一方、注意点もあります。

• 数値精度の低下
• 推論結果の品質低下
• ハードウェアによる高速化効果の違い
• 推論エンジンとの互換性
• 量子化方式ごとの実装差

特に、4 bitにすれば必ず8 bitより高速になるわけではありません。

実際の速度は、演算器、メモリ帯域、量子化・逆量子化処理、推論エンジンなどによって決まります。

Local AIの技術構造

Local AIを動かすには、モデルファイルだけでなく推論エンジンが必要です。

Application
     |
     v
Local API
     |
     v
Inference Engine
     |
     v
Model Weights
     |
     v
CPU / GPU / NPU
     |
     v
Generated Output

推論エンジンの役割

推論エンジンは、モデルの読み込み、Token処理、メモリ管理、演算実行などを担当します。

代表的な選択肢には、llama.cpp、ONNX Runtime GenAI、vLLMなどがあります。

それぞれ得意な環境が異なります。

実際のモデル対応状況は、推論エンジンのバージョンによって変わります。

llama.cpp

llama.cppは、C/C++を中心に開発されているLLM推論プロジェクトです。

GGUF形式のモデルを扱い、CPUや各種GPUで推論できます。

公式READMEでは、ローカルモデルを実行する基本例として、次の形式が示されています。

llama-cli -m my_model.gguf

また、APIサーバーを起動する構成も用意されています。

llama-server -m my_model.gguf

上記はコマンド形式の説明例です。実行には対応するプログラムとモデルファイルが必要です。

参考：llama.cpp公式Repository

GGUFとは何か

GGUFは、モデルの重みやMetadataを保存するためのファイル形式です。

量子化済みモデルの配布などで利用されています。

ただし、GGUFはAIモデルそのものの名称ではありません。

モデルのアーキテクチャ、重み、量子化方式、推論エンジンは別の概念です。

Edge AIの技術構造

Edge AIでは、モデルの推論性能に加え、装置全体の制約を考える必要があります。

例えば、工場設備に設置したカメラで異常を検出する場合です。

Industrial Camera
        |
        v
Image Acquisition
        |
        v
Preprocessing
        |
        v
Edge AI Inference
        |
        v
Anomaly Classification
        |
        v
Decision Logic
        |
        v
PLC / Monitoring System

ここでAIが担当するのは、主として認識や推定の部分です。

設備の安全停止や保護機能を、そのまま生成AIへ委ねるべきではありません。

AIと制御システムの責任境界

工場設備では、AIの推論結果と制御指令を分離することが重要です。

例えば、

AI
 |
 v
異常の可能性を推定
 |
 v
判定ロジック
 |
 v
PLC
 |
 v
設備動作

という構成が考えられます。

安全関連機能については、要求される安全性能に応じて、適切な安全制御系を別途設計・検証する必要があります。

LLMの応答時間や出力内容は、一般に厳密なリアルタイム制御の保証を前提としていません。

AIによる認識・推論と、決定論的な機械制御を混同しないことが重要です。

Latencyを評価する

Latencyは、入力から結果が得られるまでの遅延時間です。

Cloud AIの場合、全体の応答時間は概念的に次のように表せます。\[ T_{\mathrm{total}} = T_{\mathrm{network}} + T_{\mathrm{queue}} + T_{\mathrm{inference}} + T_{\mathrm{transfer}} \]

ここで、

• $T_{\mathrm{network}}$：通信遅延
• $T_{\mathrm{queue}}$：処理待ち時間
• $T_{\mathrm{inference}}$：推論時間
• $T_{\mathrm{transfer}}$：データ転送時間

です。

これは評価用の簡略モデルです。

Local AIではインターネット通信を省略できる場合がありますが、その分、ローカルハードウェアの推論速度が問題になります。

したがって、

Local AI
    ≠
必ず低Latency

です。

測定すべき指標

実際の評価では、次の指標を分けて測定します。

例えば、対話用途ではTTFTが重要になる場合があります。

一方、大量の文書を夜間処理する用途では、Throughputや総処理コストの方が重要かもしれません。

Costを評価する

Cloud AIのコスト

Cloud AIでは、入力・出力Token数や利用するサービスなどに応じて費用が発生します。

一般化すると、\[ C_{\mathrm{cloud}} = C_{\mathrm{input}} + C_{\mathrm{output}} + C_{\mathrm{tools}} + C_{\mathrm{other}} \]

と整理できます。

実際の料金体系はサービスによって異なります。

Local AIのコスト

Local AIでは、API利用料が不要になる場合があります。

しかし、運用コストがゼロになるわけではありません。\[ C_{\mathrm{local}} = C_{\mathrm{hardware}} + C_{\mathrm{power}} + C_{\mathrm{maintenance}} + C_{\mathrm{operation}} \]

ハードウェア費用は、評価期間に配賦して比較する必要があります。

損益分岐点

仮に、クラウドの1処理当たりの費用を $c_c$、ローカルの変動費を $c_l$、ローカル導入の固定費を $F$、処理回数を $N$ とします。\[ C_c=Nc_c \]\[ C_l=F+Nc_l \]

両者が等しくなる条件は、\[ Nc_c=F+Nc_l \]

したがって、\[ N=\frac{F}{c_c-c_l} \]

となります。

ただし、この式が意味を持つのは $c_c>c_l$ の場合です。

また、両方式で同等の要求品質を満たせることが比較の前提です。

実務では、ハードウェア更新、障害対応、人件費、稼働率なども含めて評価します。

PrivacyとSecurity

Local AIの利点として、外部へデータを送信せずに処理できる可能性があります。

例えば、社内の設計図面や未公開の製品仕様を解析する場合です。

ただし、

Local AI
    ≠
自動的に安全

です。

モデルファイルや推論プログラムの入手元、ログ保存、アクセス権限、外部通信、ソフトウェア更新などを確認する必要があります。

特に、ローカル推論アプリケーションが外部APIやTelemetry機能を利用する場合、完全なオフライン処理にはなりません。

Security設計の基本

機密情報を扱う場合、次の項目を確認します。

• モデルと推論エンジンの入手元
• ファイルの完全性
• 外部通信の有無
• ログの保存場所
• 利用者の認証と権限
• データの暗号化
• モデル更新時の検証
• バックアップと復旧手順

また、Open-weightモデルでもPrompt InjectionやHallucinationが発生する可能性があります。

ローカルで動くことと、出力が正しいことは別問題です。

Cloud・Local・Edgeをどう選ぶか

実行環境の選定では、最初に用途を定義します。

例えば、次の3つを考えます。

用途A：設計技術資料の調査

大量の技術文書を検索し、設計上の判断材料を整理する用途です。

この場合、重要な評価項目は、検索品質、推論能力、出典追跡、機密性です。

機密情報を含まない場合はCloud AIが有力です。

一方、社外送信できない資料を扱う場合は、社内Local AIや承認済みの専用環境を検討します。

用途B：CAD作業の自動化

自然言語からPythonコードやCAD操作スクリプトを生成する用途です。

この場合、コード生成能力、実行権限、テスト、Rollbackが重要です。

AIモデルはCloudでもLocalでも構いません。

ただし、CAD操作やファイル変更は、権限管理された実行環境で行う必要があります。

用途C：工場設備の異常検知

センサーデータや画像から異常を検出する用途です。

通信が不安定で、現場での応答が必要な場合はEdge AIが有力です。

ただし、必ずしもLLMが適切とは限りません。

異常検知専用の小型モデルや、統計的な判定ロジックの方が適している場合もあります。

配置判断表

この表は配置判断の出発点であり、最終的な選定結果ではありません。

Hybrid Architectureという考え方

CloudとLocalを二者択一にする必要はありません。

例えば、次のような構成が考えられます。

User Request
      |
      v
Request Classifier
      |
      +------------------+
      |                  |
      v                  v
Public Information   Confidential Data
      |                  |
      v                  v
Cloud Model         Local Model
      |                  |
      +--------+---------+
               |
               v
          Validation
               |
               v
             Output

この構成では、公開情報を扱う処理と、機密情報を扱う処理を分離できます。

ただし、Request Classifierが誤判定する可能性があります。

機密情報の外部送信を防ぐには、分類結果だけに依存せず、明示的なデータ分類や通信制御を組み合わせる必要があります。

モデルを交換できる設計

将来的なモデル変更を考えると、アプリケーションと推論エンジンを分離することが重要です。

Application
     |
     v
Model Adapter
     |
     +------------------+
     |                  |
     v                  v
Cloud API          Local API
     |                  |
     v                  v
Cloud Model        Local Model

この構造なら、アプリケーション側の処理を大きく変更せずに、モデルや実行環境を切り替えられる可能性があります。

ただし、API形式が似ていても、Tool Calling、Structured Output、Tokenization、Context Lengthなどが完全に互換とは限りません。

モデル変更時には回帰テストが必要です。

実務導入時の評価手順

AIモデルの配置を決める場合、次の順序で評価すると整理しやすくなります。

要求条件を定義する

まず、対象業務の条件を明確にします。

例えば、

Task:
Technical Document Analysis

Input:
PDF / Markdown / JSON

Output:
Structured JSON

Privacy:
Internal Only

Latency:
Interactive

Availability:
Offline Required

Hardware:
Existing Workstation

という形式です。

候補モデルを選定する

次に、要求条件に合うモデルを選びます。

確認項目は、Model Card、License、Input Modality、Output Format、推論エンジン対応状況です。

ハードウェア適合性を確認する

パラメータ数と量子化形式から重み容量を概算します。

そのうえで、KV CacheやRuntime領域を含む実メモリ使用量を測定します。

実際の業務データで評価する

公開Benchmarkだけでは不十分です。

実際の業務データを使い、回答品質、Latency、Memory Usage、Failure Rateを測定します。

運用条件を確認する

最後に、ライセンス、セキュリティ、更新、監視、障害対応、復旧方法を確認します。

モデルを一度実行できたことと、業務システムとして継続運用できることは別です。

よくある誤解

Open-weightなら自由に商用利用できる

正しくありません。

利用条件はモデルごとのライセンスによって決まります。

量子化すれば性能を維持したまま小型化できる

必ずしも正しくありません。

量子化方式や対象タスクによって、品質低下の程度は変わります。

VRAMがモデルファイルより大きければ動作する

必ずしも正しくありません。

KV Cacheや計算用領域などが必要です。

Local AIならCloud AIより速い

必ずしも正しくありません。

ローカルハードウェアの計算性能によっては、Cloud AIの方が速い場合があります。

Edge AIならリアルタイム制御に利用できる

必ずしも正しくありません。

AI推論の応答時間と、制御システムのリアルタイム保証は別の問題です。

小型モデルなら工学計算を任せられる

注意が必要です。

小型モデルでも数式や計算結果を誤る可能性があります。

工学計算では、可能な限り確定的な計算プログラムや検証済みの計算ロジックを利用し、AIは入力整理や結果説明を担当する構成が適しています。

まとめ

Open-weight、Local AI、Edge AIは、それぞれ異なる観点の概念です。

Open-weightは、モデルの公開形態です。

Local AIは、モデルの実行場所に関する概念です。

Edge AIは、データ発生源に近い場所でAIを処理するシステム構成です。

これらを組み合わせることで、AIモデルをクラウドだけでなく、PC、社内サーバー、工場設備などへ配置できます。

ただし、実際の配置には、モデル容量、量子化、VRAM、RAM、Latency、Privacy、Cost、Maintenanceなどの制約があります。

AI Deployment Design
        |
        +-- Model Capability
        |
        +-- License
        |
        +-- Hardware
        |
        +-- Quantization
        |
        +-- Latency
        |
        +-- Privacy
        |
        +-- Cost
        |
        +-- Maintenance
        |
        v
Deployment Decision

2026年のAIシステム設計では、モデルの能力だけでなく、モデルをどこへ配置するかも重要な設計変数です。

Cloud AIは大規模な計算資源を利用しやすく、Local AIはデータ管理と実行環境の制御に利点があります。

Edge AIは、通信条件や現場での処理要求に対応する選択肢となります。

重要なのは、Cloud・Local・Edgeのどれか一つを選ぶことではなく、要求条件に応じて適切な実行環境を設計することです。

参考情報

以下は2026年10月11日時点で確認した公式資料です。

モデルとライセンス

• Open Source Initiative：Open Source AI Definition 1.0
• Gemma 4：Official Model Card
• Gemma 4：Quantization-Aware Training（2026年6月5日）
• gpt-oss：Official Open Models
• Qwen3-8B：Official Model Card
• Mistral 3：Official Announcement（2025年12月2日）
• Llama 4：Official Model Card

推論エンジンとDeployment

• llama.cpp：Official Repository
• Gemma：Local・Edge・Cloud Deployment Guide
• ONNX Runtime GenAI：Official Documentation

今日の確認問題／学習課題

問題：Open-weightとOpen-source

次の問いに答えてください。

問題1

学習済みモデルの重みをダウンロードできる場合、そのモデルを必ずOpen-source AIと呼べるでしょうか。

Open Source AI Definitionを参考に、必要な条件を説明してください。

問題：モデル容量の計算

問題2

次のモデルについて、重みだけの理論容量を計算してください。

FP16とINT4の理論容量を求め、どれだけ削減できるか計算してください。

さらに、実際のVRAM使用量が理論容量より大きくなる理由を説明してください。

問題：AI配置判断表を作成する

問題3

次の3つの用途について、Cloud、Local PC、Edge Deviceのいずれを選ぶか検討してください。

各用途について、推奨する実行環境と、その理由を説明してください。

問題：量子化と推論品質

問題4

同じモデルについて、FP16版とINT4版を比較するとします。

モデルファイル容量だけでなく、どのような項目を測定すべきでしょうか。

回答品質、Latency、VRAM使用量、Throughputを含めて評価項目を整理してください。

今日の実習

今回の学習作業票の完成条件は、自分の用途3件をCloud・Local・Edgeへ割り当て、その理由を説明できることです。

次の配置判断表を完成させてください。

さらに、Open-weightモデルを採用する条件と、採用しない条件をそれぞれ一つ以上記述してください。

実習の完成条件： 3用途について、Privacy・Latency・Cost・Hardwareの4軸を用いて配置判断を説明できること。

次回予告

Day 10｜AI for Science

次回は、AIを科学研究や工学的な問題解決へ利用する技術を扱います。

AI for Scienceでは、単にAIへ科学的な質問をするだけでなく、予測、生成、シミュレーション、仮説生成、実験計画などにAIを組み込みます。

主な学習対象は次のとおりです。

• PredictionとGenerationの違い
• AIと数値シミュレーションの関係
• Scientific Foundation Model
• AI Co-scientistとMulti-agent Research
• 科学的検証と再現性
• 物理法則・数学的制約を考慮したAI活用

特に工学分野では、AIが提案した設計案や仮説を、物理法則、数値計算、シミュレーション、実験によって検証する必要があります。

次回は、AIによる仮説生成と、人間・計算機による科学的検証の責任分担を中心に整理します。