Re: [心得] token maximum

作者: leicheong (睡魔)   2026-03-01 18:05:54
※ 引述《erspicu (.)》之銘言:
: 所以到底max應該設定多少比較適合?
借這個來抱怨一下.
正如我在之前稍微提過的, 我的公司已經全面轉用 AI, 而且為了
不讓外部的一些壞 coding 習慣污染 AI, 是用自己 code base train
的 AI model. (本公司不留能力不足的人, 而且一直都需要 code review
才可以 check-in 因此 code 的本身質素是沒問題的)
隨著超過2000位 dev同時使用 AI 來做 coding, 公司本身配置的資源
很快就開始不夠用了. 寫好了 prompt 提交時發現在排隊 350位以外
是常事. 公司很快 (也花了一個月左右) 便批准了買更多的 VM, 但同時
也要求我們用 prompt improvement coach wizard 「改進」我們的 prompt.
結果他都要求我直接告訴 AI 需要修改那個檔案. 這產生了兩個問題:
首先, 如果我看錯是那個檔案出問題的話, 不管怎麼改還是沒有效果.
然後, 如果我寫 prompt 還是先 trace code 去找那個檔案出問題的話, 比起
花時間寫 prompt, 自己改比較快 (還不用排隊)
最近我們也發現了 AI 寫的 code 在需要和第三方對接的部份常出現
忽略明明已經寫進了 rules.md 的限制, 因此需要回爐人手重做的事件.
說實在的, 用了 AI 後也沒發現省了多少時間.
作者: HaHadog   2026-03-01 19:34:00
恭喜你 發現爲什麼在這裡真的有開發經驗的工程師噴那些AI吹噴那麼兇了 這就是現在AI開發現實 至於那些說未來會進步的 可能連現在語言模型的基礎原理是什麼都不知道先吹再說
作者: gtr22101361 (Kai)   2026-03-01 19:36:00
??
作者: tsairay (火の紅寶石)   2026-03-01 19:43:00
從AI開發得利最大的是那些自有資料中心的大公司他們token多半是無限使用的,才能獲益如此巨大
作者: ZielC (Ziel)   2026-03-01 21:47:00
但會不會就是因為本地模型,上下文容量與產token能力不足,才只能讓他閱讀部份的代碼無法觀察全局導致你文中的情境?當然本地化的保密需求是外部AI model永遠無法滿足的
作者: ZMTL (夜風/瀟湘 VR板已經開板!)   2026-03-01 22:18:00
我看下來這好像不是LLM的問題...這個場景本身就已經只有頂尖Model的選擇了,本地自訓練的就要先考慮推理能力落差,再來會2000個dev排隊這是治理問題
作者: aspirev3 (aspire)   2026-03-01 22:39:00
0>1 AI很神 1>100真的就還好 專案越大人越多就越還好
作者: abc21086999 (呵呵)   2026-03-01 22:47:00
人家脈絡都說了,不就是不能用外面的嗎而且LLM做事情無視規則真的蠻常遇到的
作者: ZMTL (夜風/瀟湘 VR板已經開板!)   2026-03-01 23:08:00
我知道情境不能用外面啊,但不是那幾個頂級的推理model就不太適合拿來類比啊,能力真的有差
作者: gofigure (平行世界)   2026-03-02 07:47:00
蛤?自己train的model...這才是問題吧
作者: DrTech (竹科管理處網軍研發人員)   2026-03-02 08:49:00
正常人用AI:AI比較快,比較好時才用AI。沒比較好,比較快時,何必堅持用AI。這就跟早期沒LLM時很多企業AI專案失敗的原因一樣,硬要什麼流程都用AI,結果沒比較好。壞的coding習慣,要擋,何必訓練模型才能擋。硬體資源不足,暫時解法,何必硬要從prompt解。比prompt調整更有效率的方法還很多。
作者: freeunixer (御劍客)   2026-03-02 09:10:00
你跑到英國去工作了??
作者: askacis (ASKA)   2026-03-02 10:29:00
地端的 LLM 沒那麼厲害,巨頭的模型厲害有他的道理
作者: chita0258 (大報社)   2026-03-02 10:58:00
公司資源問題 Trial & Error是建立工作留的必經之路
作者: nfsong (圖書館我來了)   2026-03-02 18:05:00
有沒有可能你們公司的code品質不高
作者: rugia813 (rugia)   2026-03-02 20:24:00
用本地model來為雲端頂級model下結論嗎
作者: cowbadma5566 (陳拷白)   2026-03-03 00:51:00
地端model能力跟那幾家的能力差非常多 無論理解和token量
作者: sarsman (DeNT15T♠)   2026-03-03 04:18:00
自己train的AI的問題通常是資料量不夠,而不是資料品質
作者: louner (louner)   2026-03-03 07:06:00
Model不夠強 以及機器不夠多 灑錢能有效解決之前也有試過local model能力跟Claude落差挺大的 雖然也跟我的agent orchestration寫的不夠好有關 但Claude就是夠聰明到即使如此還是持續使用正確的工具
作者: GiPaPa (揪濘)   2026-03-03 13:58:00
地端也沒關係 但是用自己CODE BASE TRAIN出來的肯定沒用連湧現門檻都到不了 是能訓練出什麼
作者: Romulus (Säubern Mode)   2026-03-03 15:36:00
你們公司的全面AI好怪 真的好怪
作者: dream1124 (全新開始)   2026-03-03 18:53:00
來,我跟你說現在爭論AI的無限制迴圈:1.有人抱怨難用=>你沒全信AI,只把它當顧問,你用網頁版沒套CLI,沒搞agent=>2.你做了,但還是有些問題,效率不如預期 =>你沒有完全信任他,你的組織沒有全面AI Coding =>於是你們也做了,公司也全面推動,但有效能或表現問題=>你機器買不夠多=>4. 你們也買了,但AI還是不能當人用=>都是你們沒用大廠私有LLM的錯=>6.有些公司於是也切了=>6.遇到token限制問題=>誰叫你們不買最大或無限制方案講來講去都是在這幾個點無限跳針,千錯萬錯,錯的絕對不是AI,也不是連原理都不很清楚就無條件「相信」AI可以真的當基層工程師來用的資深同事或中高層主管這就是這一兩年最瞎的事情。本來它就只是工具,因此照理講就是給大家用,但提供一定彈性不要強制大家怎麼做事,也不要毫無理由相信全交給AI必定沒問題,有問題就一定是倒回去燒token算到對為止。有錯必是人錯,有延宕必是人類在扯AI後腿……別搞這些就沒事了。
作者: gtr22101361 (Kai)   2026-03-03 19:23:00
人家公司都是coding能力很高的 當然是ai扯後腿
作者: ZMTL (夜風/瀟湘 VR板已經開板!)   2026-03-03 21:33:00
AI又不會自己動自己佈署自己,那能不能用在對的場合達成對的目的不就是人的問題?美國都在用AI開打WW3了你在那邊盲信AI
作者: flydeer (拖鞋)   2026-03-04 07:57:00
要不要先試試雲端大模型比較看看
作者: teddy (這是個好問題)   2026-03-04 09:08:00
地端模型有300B嗎?
作者: shadow0326 (非議)   2026-03-04 14:11:00
"不讓外部的一些壞 coding 習慣污染 AI"這句話滿怪的
作者: OBTea (明珠)   2026-03-05 17:42:00
減少基層純碼農是大公司共識...
作者: AxelGod (Axel)   2026-03-06 10:31:00
共識=找理由裁員罷了
作者: pttassassin (0)   2026-03-08 14:20:00
看起來是你們train的模型太爛捏還有機器太少
作者: aria0520 (紫)   2026-03-09 00:24:00
問題應該是出在你們自train的模型上以現在來說比起自train 不如寫個有你們coding style的skill 接入claude聽起來你們公司有點跟不上現在AI workflow的進展自train local llm大概是兩年前的meta
作者: leicheong (睡魔)   2026-03-09 06:24:00
對. 我現在是在英國最大的軟體公司工作.我公司在用的是Azure企業版的AI hosting方案. 用的token數量已經是專門去談的海量了.但面對真實的應用場景還是會很快燒完.AI model本身沒問題, 但在還要想辦法控制token用量下我感覺幫助有限.

Links booklink

Contact Us: admin [ a t ] ucptt.com