オンプレミスのAIソフトウェア開発プラットフォーム: いつ重要か

オンプレミスのAIソフトウェア開発プラットフォームは、ループ全体。AI支援の構築、テスト、ガバナンス、デプロイ、を御社が所有し運用するインフラに持ち込みます。それは利用可能な最も強い制御姿勢です: 御社のネットワーク、御社のハードウェア、御社のルール、そして最も厳格な構成では、実行時にいかなる外部サービスにも依存しません。少数の組織にとって、これは好みではなく、法律、規制、契約に書き込まれた要件です。

それはまたデプロイの範囲で最大のコミットメントでもあります。オンプレミスは、御社のチームがベンダーなら運用するもの、容量、アップグレード、プラットフォーム自体のインシデント対応、を運用することを意味します。正直な枠組みは、オンプレミスが運用の利便性を制御と引き換えにし、その取引は制御が本当に必要とされるときにのみ報われるというものです。オンプレミスの会話を始める多くの買い手は、自社クラウドアカウントまたはプライベートVPCへのデプロイが、彼らが従うべき実際のルールを満たすと発見します。

この記事は、オンプレミスが正しい選択であるサイン、そうでないという反対のサイン、デプロイの範囲全体にわたる比較、そしてコミットする前に、何よりモデル戦略を、決着させるべき問いを与えます。参考までに、Automoではオンプレミスは別条件のもとで利用可能であり、それ自体が業界全体で予期すべきパターンです: オンプレミスは常にスコープの切られた合意であって、チェックボックスではありません。

一部の組織は、そのソフトウェアがどこで動いてよいかを告げられます。政府機関とその供給業者は、管轄区域を、時には施設を名指しする主権ルールに直面します。防衛関連の作業は、いかなる共有インフラも満たせないクリアランスとエアギャップの要件をもたらします。特定の国の特定の金融・ヘルスケアの規制当局は、外部ネットワークを通過してよいものをまったく制約します。これらの買い手にとって、デプロイモデルは評価が始まる前に決まっています。

第2のグループは規制ではなく契約経由で到着します: 特定のデータが特定のインフラを決して離れないと自らの顧客に約束した企業です。それらの約束はしばしば何年も前に交わされ、今日拘束し、それを再交渉することはそれを守ることより遅いのです。第3のグループは運用技術環境、公益事業、製造、を運用しており、そこではネットワーク分離はポリシーの好みではなく安全アーキテクチャです。

これらの買い手を結びつけるのは、通常のクラウドの保証が、どれほど強くても、彼らが尋ねることを許されていない問いに答えることです。データ保持ゼロの契約と認証は重要ですが、彼らのルールは場所と制御についてのものであり、彼らが運用するインフラだけがそれを満たします。彼らにとっての評価はオンプレミスかどうかではありません、どのプラットフォームが自らのループを彼らの壁の中で本当に走らせられるか、そしてそれを運用するのに何がかかるかです。

御社の組織をこれらのグループの1つに認めるなら、この記事の残りは要件が本物であると想定し、実行計画に移ります。認めないなら、動機が本能、インシデントの記憶、または制御への一般的な好みなら、次の2つのセクションをゆっくり読んでください。なぜなら、制御を望むことと、インフラを所有することを要求されることの間のギャップこそ、ほとんどのオンプレミスの後悔が製造される場所だからです。デプロイの範囲は、ほとんどの買い手が使うより多くの位置を持ち、中間の位置は運用の重みのわずかな割合で制御の便益のほとんどを運びます。御社のルールが実際にどの位置を要求するかを名指すことが、勝負のすべてです。

オンプレミスの本能の背後にある要件が当社のデータは当社の制御下に留まらなければならないなら、自社クラウドアカウントまたはプライベートVPCへのデプロイが実際のルールを満たすかどうかをテストしてください。しばしば満たします: テナンシーは御社のもの、ネットワーク境界は御社のもの、そしてプラットフォームの運用の負担はベンダーに留まります。多くのオンプレミスの会話は実は制御の会話であり、制御には複数の住所があります。

コストについても同様に正直であってください。オンプレミスは、遅いプラットフォームのアップグレード、インフラのインシデント経路に入る御社のチーム、急増するAIワークロードの容量計画、そして御社が所有しなければならないモデル戦略、それが壁の中でモデルをホストすることであれ、推論のために厳密にスコープされた送信を承認することであれ、を意味します。これのどれも、オンプレミスが要求されるときにそれを避ける理由ではありません。すべては、より軽いモデルが同じルールを満たすときにオンプレミスを既定の姿勢として選ばない理由です。

アップグレードは背景の事実ではなくスケジュールされたイベントになります。クラウドプラットフォームは継続的に進化します。オンプレミスのデプロイは、御社のチームが制御する計画された窓の中で動きます。それはまさに一部の買い手が望んだ制御であり、誰かが今所有しなければならない頻度です。定期的なアップグレードのリズムに予算を組み、先送りの誘惑に抵抗してください、3バージョン遅れたデプロイこそ、サポートケース、セキュリティ姿勢、ベンダー関係のすべてが一度に劣化する場所です。

容量計画はAIの次元を獲得します。構築活動はバースト的です: 新しいアプリケーションを立ち上げるチームは、安定したポートフォリオを保守するチームよりはるかに多くの計算需要を生み出し、推論ワークロードは従来のライン・オブ・ビジネスシステムにはない形で使用とともに急増します。役立つインフラのパターン、下層のKubernetes、隔離されたワークロード、アイドルプロジェクトのハイバネーション、は、署名の前にプラットフォームの設計で確認する価値があります。なぜならそれらこそ、御社の容量計画と調達の緊急事態の間に立つものだからです。

最後に、拘束する動機をレビューのカレンダーに載せてください。ルールは変わります: レジデンシー法は明確化され、規制当局はクラウドのガイダンスを公表し、契約は再交渉されます。組織は時折、2年前に緩んだ要件のためにオンプレミスの運用の重みを担っていると発見します、あるいはその逆に、新しいルールが手放しかけた姿勢を正当化すると。動機の文書を毎年読み直すことが、デプロイモデルを相続ではなく決定に保ちます。

Automoは意図的に範囲全体をカバーします: 速さのためのAutomoクラウド、制御された環境のための御社自身のAWS、Azure、GCPアカウントまたはプライベートVPCへのデプロイ、そして最も厳格なもののための別条件のもとのオンプレミス。プラットフォームのインフラ設計。Kubernetes、隔離されたポッド、ハイバネーションと復帰、マルチリージョン対応、こそが、より厳格なモデルを理論的ではなく実用的にするものであり、モデル戦略がそれを要求する買い手のために自社モデルのオプションが存在します。

ガバナンスの話はデプロイとともに移動します。プラットフォームがどこで走ろうと、Guardrailsは平易な言葉のポリシーを適用し、すべてのマージの裏に監査証跡を伴って人によるレビューを記録し、QAは公開前に変更をゲートし、Securityは稼働中のアプリに対して検出結果を確認します。主権の買い手は通常、誰よりもこれを気にします: 変更に対する制御の証拠のないインフラの制御は、彼らの監査人が必要とする答えの半分にすぎません。

商業的に: 本格的な開発プログラムは年間10,000米ドルから、オンプレミスの取り決めは別条件のもとで営業とともに個別にスコープが切られます。決定の初期にいるなら、御社の拘束する動機とモデル戦略から会話を始めてください、その2つの答えが、御社がそもそもオンプレミスを必要とするか、そしてもしそうならそれがどう見えるべきかを決めます。