關于大模型在企業級應用中的選擇問題疑問回復 原創
?“ 企業級應用和平常學習是兩回事，千萬不能混為一談 ”
在前面的??千萬不要為了節約成本而選擇小模型，特別是開源模型??這篇文章中，簡單說明了為什么盡量不要選擇小模型，然后文章下面有些評論，可能覺得作者說的都是廢話，或者模型不好直接換就行了。
但事實上作者認為這些都是站在純粹的技術角度或者說把企業級應用想的太簡單了。
大模型在企業級應用中面臨的問題
很多技術人員都習慣站在技術的角度來考慮問題，認為某項技術不好換一個就好了；又或者因為某些原因導致某些東西不能用。比如說，有些政府單位或銀行保險部門還在使用xp系統和jsp做開發。
所以很多人就認為政府單位的系統很拉垮，或者自己公司的技術經理腦子有問題，選的都是什么架構和技術棧；包括作者自己在前兩年也是這種想法。
但隨著工作經驗的增加，以及看待問題角度的改變，現在發現一個項目真的沒那么容易給做起來，做好；它會受到多個方面的影響，由于各種各樣的原因可能會導致想的是一回事，做的是另一回事。
友情提示一下，看這篇文章首先要拋開技術至上的理念，要從企業運營，產品，成本，技術等多個角度來看待問題。
現在從實際案例的角度來思考問題，假如某一天你和朋友合伙開公司，然后想做一款基于大模型的產品；然后由于初創企業，資金和人力都有限，無法直接配備完善的企業架構，比如說項目經理，產品經理，技術負責人，再加上其它的行政，財務等等。
可能很多時候都需要一人扮演多個角色，又是項目經理，又是技術經理，同時還需要負責企業的正常運營。
現在假如你是技術經理，讓你負責這款大模型應用的技術架構，以及業務實現；這時你應該怎么做？
前期的需要采集與分析，以及產品經理把需求產品化的過程就不說了；現在產品經理直接給你一份產品的詳細設計方案，然后讓你基于這個方案做一個技術評估，以及一個能落地的技術方案。這時你需要處理哪些問題？
首先，你要評估這個產品在技術上是否可行，也就是說依靠現有的技術能力能否實現產品的功能；然后在技術可行的前提下，怎么設計系統架構，不同的功能模塊怎么拆分；這時你考慮的不僅僅只是技術的實現問題上；還同時需要考慮后續的功能升級，產品上線之后的穩定性，當前自己團隊的技術實力。
前端技術棧的選擇，后端技術棧的選擇，各種中間件的選擇；然后是否會有安全性問題，合規性問題，保密性問題，行業要求，政府規章問題等等。
等這些問題都搞定之后，再來說關于大模型的選擇，畢竟做的就是基于大模型的上層應用。
關于大模型的選擇一般有以下幾種情況：
自己開發大模型，這種對創業公司來說基本可以放棄，除非你就是想做大模型服務
使用第三方模型，這又有幾種情況，是使用一些大模型服務商提供的大模型接口，還是搞幾個開源模型。
選擇大模型服務商的模型，需要考慮幾個個問題，你這個應用是否有保密性要求；比如數據不能上傳到第三方模型服務；只能放在本地， 這時大模型服務商就可以直接拋棄了，只能選擇開源模型本地部署。
其次，開源模型服務商的接口價格問題；比如有些接口調一次幾毛錢就沒了；而在開發測試階段，每天都要花幾百塊錢甚至幾千塊錢的接口調用費；這還不包括上線之后可能面臨的大量用戶調用帶來的巨大成本。
因為一般情況下，產品上線前期很難賺到錢，這時就需要公司的資金做支持。
如果無法承擔巨大的資金成本，這時只能退而求其次去選擇一些價格便宜，但性能可能并沒有那么好的模型服務商。
這時，你覺得模型不好用，直接換一個就行了，有這么容易嗎？ 雖然從技術的角度來說換一個模型很簡單，也就是換一個接口而已。
再有，關于大模型本地部署的問題，大模型本地部署需要大量的算力，而算力問題怎么解決？
是自己買GPU組建機房，還是租用云算力服務？
自己組建機房就需要有專業的團隊來負責機房的穩定運營和功能升級；租用云算力服務就需要面臨巨大的資金壓力；這時應該怎么選擇？
一般情況下，選擇云算力服務肯定會比自己組建機房成本要低的多；因此租用云算力服務是一個比較好的選擇。
ok，現在云算力服務租下來了，要本地部署大模型；這時選擇什么樣的大模型做本地部署？
是選擇功能垂直化的小模型，還是選擇參數量巨大的強大開源模型？
選擇參數量巨大的強大開源模型就意味著單臺算力機無法支持大模型的穩定運行，這時就需要采用多臺算力機并行計算的方式來實現；但大模型由于其體量巨大，而且運行過程中需要面臨各種各樣的問題。
因此，人力運維就很難完成，因此就需要有完整的自動化運維系統；這個系統哪里來？自己開發，還是購買第三方的系統？ 第三方系統能滿足你的全部需求嗎？ 如果不能該怎么辦？
還有，如果選擇功能垂直的小模型，可以進行單機部署，但你這單機模型的運維怎么搞？ 全部靠人工嗎？
如果是前期開發測試階段，由于規模不大靠人力還能扛的住；但上線之后呢？如果面臨每天幾萬，甚至幾十萬的訪問量，單臺機器能扛的住嗎？
如果不行，大模型集群部署該怎么搞？ 是簡單的多買幾臺機器然后把模型復制過去就行了嗎？
怎么保證某臺機器突然掛掉導致業務系統受影響，怎么做到不同機器之間的主動切換？
由于節假日或者某些原因導致系統壓力突然增大，怎么在最快的情況下讓系統自動擴容，應對流量洪峰。
當然，看到這里可能有人會說我們初創企業沒有那么大的流量，這些都是有些規模的企業才需要考慮的問題。
雖然話是這么說，但即使是小企業在產品上線之后，只要產品不是特別差，每天的用戶量也會有一部分吧？ 哪怕只需要三五臺，甚至十來臺機器部署大模型，而且還有保證業務的穩定運行，這時全靠人力運維，技術人員會有多累？能堅持的住嗎？ 并且還要負責新功能的開發和測試。
本地部署大模型就需要面臨著巨大的運維成本，技術成本和算力成本；使用第三方模型就需要面臨著巨大的接口調用成本；這還是在沒考慮各種意外情況的理想狀態下。
而且，你引入的技術種類越多，也就意味著你的技術成本越高；可能某些技術還需要重新學習。這也意味著上線之后面臨的風險就越大；畢竟無法保證新技術帶來的穩定性。
或者你會說，我們公司不缺錢，這些服務直接買就行了；那對于有鈔能力的企業，作者只能留下羨慕的淚水。
總之，對企業級應用來說，它不是學習用的demo，這個不好換那個；再換之前你需要考慮技術，資金，穩定性，風險等多個角度去考慮問題。
所以，如果說你是技術負責人，你會怎么做？怎么平衡技術，成本，風險，以及各種各樣的問題？
?
本文轉載自公眾號AI探索時代 作者：DFires
