使用小型模型的代理式程式設計工作流程

現在我們來做個小測驗

大家好，

我是 Jose，今天與 Ian 和 Zoe 一起

我們都知道 LLM。

我們用它們來做各種事情：尋找食譜、總結 YouTube 影片和編寫程式碼。

Gemini 模型等超大型 LLM 具備驚人的能力，但本次講座將著重介紹小型語言模型。

它們也是 LLM，因為擁有 40 億個參數的模型不可能小，但從現在起，我們會區分前沿模型和小型語言模型，就像火箭和腳踏車。

我們將討論小型模型，但不會將其視為前沿模型的替代方案，而是主要用於補充前沿模型。

我們將探討小型語言模型的所有優點，尤其是開放式、開放權重和可下載的模型，但先來看看成本。

為了準備這場演講，我執行了許多基準測試，其中一項是使用近 1.31 億個詞元，處理 200 項中等和困難任務的資料集，花費不到 $9 美元。

我使用 Gemma 4 執行這項作業，因此可以免費下載並在自己的硬體上執行，但為了公平比較，我選擇在商用閘道上執行。

那麼，前沿模型需要多少費用？

視權杖快取和其他因素而定，大約是 20 到 200 倍。

因此，單車可能不是最快的交通工具，但絕對是最有效率的。

沒錯。

現在，顯而易見的問題是，品質和準確度有何差異？

在這個資料集中，Gemma 4 可解決 53% 的工作。

這代表兩件事。

如果使用前沿模型執行左側的工作，可能有點大材小用。

如果使用小型模型執行右側的工作，則必須引導模型找出解決方案，或使用較大的模型。

這場講座將協助您充分運用每個詞元。

Zoe 會逐步說明如何選擇小型模型，Ian 則會介紹 Gemma 模型，讓您瞭解如何思考這些模型能實現哪些功能。

接著，我會快速示範如何在 Android Studio 中試用 Gemma 4。最後，我們會說明如何將小型模型融入日常工作流程，並提供實際的 Android 開發基準，協助您瞭解這些模型的功能。

接下來，請 Zoe 說明。

非常感謝，Jose。

因此，如果所有工作都使用同一個模型，就像用大錘敲堅果一樣，有點大材小用，對吧？

雖然效率很高，但有點不對稱。

因此，小型模型就像是擴充工具組，

如要瞭解應將哪些工具納入工作流程，請開啟工具組，查看可用的工具、規格和用途。

因此，如要選擇小型模型，您必須瞭解小型模型。

而大多數人想到語言模型時，通常會想到自動迴歸語言模型。

之所以稱為自動迴歸，是因為模型會根據輸入內容 (切分為詞元)，從候選清單中選擇最有可能的下一個詞元。

接著，系統會將最有可能的下一個詞元放回輸入內容，然後繼續執行，這樣就能產生連貫且聽起來很聰明的回覆，但也有一些注意事項，包括但不限於線性運作。

因此，我們可以非線性方式工作。

擴散模型也採用相同方法，但一次處理一個詞元區塊。

就像是草稿逐漸清晰。

在這個例子中，DiffusionGemma 一次處理 256 個詞元的區塊。

基本上，您會獲得適用於整個區塊的通行證，能以較低的延遲時間生成結果。

我們的工具組有可以寫作的模型，對吧？

不是，

基本上，嵌入模型會將圖片、文字或任何其他概念轉換成向量。

因此，這項技術可將座標對應至高維度空間，讓我們能從概念上比較兩項事物。

舉例來說，如果熱狗是三明治，兩者可能會很接近，或最終會落在相近的空間。

因此，檢查兩個概念是否相關，就變成了一點數學運算，而不是模型傳遞，這也可以說是一點數學運算，但這個範式更進一步，對吧？

也有小型和專門的模型，可以做好一項工作，而且做得非常好。

舉例來說，我們有可將自然語言轉換為 API 呼叫的函式模型、視覺模型 (從名稱就能知道功能)，以及可根據特定參數為輸入內容評分的分類器。

好，所以有很多選項，對吧？

模型種類繁多，維度、大小、脈絡窗口、功能和記憶體用量各不相同。打開工具箱後，如果考量到所有可能性，選項會呈指數級成長，讓任何 DIY 愛好者欣喜若狂，或因難以抉擇而不知所措。

那麼，該如何選擇小型模型呢？

首先，我們來看看 Gemma 模型，這是一組可在本機執行的開放式小型模型。

交給你了，Ian。

謝謝你，Zoe。

正如 Jose 在開頭所說，小型語言模型開箱即用，可完成約 50% 的工作。

但為什麼要選擇本機模型呢？

因此，這可以歸納為四個重點。

首先是隱私權。

舉例來說，您可能有 API 金鑰、專屬程式碼，或絕對不能離開筆電的資料。

第二個是延遲時間。

因此，當模型實際載入記憶體 (圖形記憶體或統一記憶體) 時，只要運算完成，就會立即收到回覆。

因此，不需要往返伺服器，也不會增加延遲時間。

接下來是零邊際成本。

因此，只要能控制模型的執行位置，就能提高成本效益。

舉例來說，在本機電腦上執行作業時，可能會在錯誤迴圈中執行額外的重試。

這項功能完全免費，不會產生任何非預期的 API 費用。

最後，第四個是離線存取。

想像一下，你可以在飛機、火車、公車或地鐵上使用這項功能，基本上只要硬體能執行模型，就能使用。

這聽起來很棒，但我們在做這些決定時，需要考慮兩個主要因素。

一個是記憶體，另一個是速度。

請看這張圖表，底部的兩個模型 26B 和 31B，都需要超過 50 GB 的視訊 RAM，才能在 BF16 (16 位元量化) 中執行。

因此，這裡的挑戰是，這不適用於許多硬體。

因此，我們會進行量化程序，將精確度縮減為 4 位元浮點數。

現在看起來合理多了。

我們說的是 14 GB 和 17 GB，對吧？

現在，這類模型可以裝進統一記憶體 Mac 等裝置。

不過，一般訓練後量化會面臨一項挑戰：壓縮權重時，模型的準確度會比基礎模型略低。我們有一項技術可以解決這個問題。

這種做法稱為「量化感知訓練」。

這樣一來，模型在訓練時就會知道自己要縮小，因此損失會比直接縮小來得少。

因此，RAM 需求降低了 75%，現在可以安裝在這些裝置上。

我們更進一步

因此，我們在許多手機上採用的行動量化方法，可以透過瞭解所有不同層的運作方式和運作大小，進一步縮小這些模型。

因此，我們有混合量化包。

因此，我們從 11.4 Gemma E2B 縮減到 1.1 GB。

因此，現在中高階手機的價格其實更合理。

接著是速度。

因此，如 Zoe 所說，使用自動迴歸模型時，您是在預測下一組權杖。

因此，在程式設計工作中，您可能會發現許多這類權杖其實相當容易預測，例如方法簽章的結尾，或是開頭或結尾大括號。

這時可以採用推測解碼技術。

這項技術會使用較小的草稿模型預測多個詞元，然後由較大的模型驗證。

之所以能在 Gemma 4 架構中運作，是因為它們共用同一個 KV 快取。

因此，您可以將這視為模型的短期記憶。

因此，小型草稿模型會預測三或四個詞元，大型模型則會查看相同的 KV 快取，並驗證輸出內容。

這項技術可將效能提升約 3 倍，且不會實際降低模型輸出內容的品質，因為模型只會預測內容，然後決定是否通過，以及是否正確。

因此，這同樣取決於您要執行的工作。

因此，這種方法不適合用於創意寫作等變異性較高的工作，但非常適合用於可預測的工作，例如 JSON 結構和程式設計。

那麼，您實際上會如何評估其中一個模型呢？

因此，最明顯的做法可能是查看 LiveCodeBench 或 MMLU 等基準測試，然後查看分數。

但這只能大致反映模型的能力。

你真正需要做的是評估整個堆疊，也就是它執行的環境。

也就是您使用的模型、權重和量化方法，以及執行階段的推論，因此您可能會使用 llama.cpp、Ollama 或 LiteRT 等工具、您使用的代理駕馭系統 (例如 Pi、OpenCode 或 Antigravity)，以及脈絡窗口，也就是您希望模型能夠處理的所有資料的空間。

這些因素綜合起來，就會決定是否可行。

舉例來說，我們在 Android Bench 上測試 Gemma 4，並執行預設 32k 脈絡的 Ollama 版本。

我們發現，在其中一項測試中，代理程式在尋找錯誤時，代理程式工具的壓縮功能會將該檔案移出記憶體，導致模型無法完成工作，進而失敗。

因此，只要將脈絡長度從 32k 增加到 256k，模型就能記住這項資訊，並通過該項測試。

我們發現該工作的成功率提高了一倍。

這表示即使是其中一個小因素，也可能對模型是否適用產生重大影響。

那麼，實際上該如何自行評估呢？

以下提供三個快速建議。

第一種是使用 Git 記錄，也就是您已成功取得的一堆 PR，並將這些 PR 做為模型的提示輸入，看看模型在這些 PR 上的表現如何。

接下來，您需要確定性評分器等工具，協助評估模型輸出內容是否正確。

我們有兩個很好的例子。

我們有編譯器和單元測試。

無論生成什麼內容，都可以透過這個工具執行，它會告訴你是否成功完成該特定任務。

第三個是記錄軌跡。

因此，執行代理時，您需要追蹤代理的不同行為，瞭解哪些部分成功、哪些部分失敗，並據此評估模型與工具互動及使用工具的能力。

我希望大家試著改變提問方式，不要問「這個模型是否和這個大型前沿模型一樣聰明？」

「這項硬體搭配這項特定設定，是否能執行這項工作？」

為了找出答案，我們設計了「我們達到了嗎？」架構。

或 AWTY。

這個架構的整體原則，是根據準備程度，在該軸上為所有這些不同的工作評分。

也就是模型本身、使用的推論引擎、測試架構和硬體設定。

這項指標會告訴你是否已準備好。

舉例來說，您可能會想瞭解特定工作的可靠性。

如果連續執行 10 次，每次都會執行相同的動作嗎？

您可能正在查看延遲時間。

您可能需要即時回應。

所以，您知道，您執行任務的速度門檻是多少？

接著，您可能會查看 RAM 需求。

因此，這不只是裝置擁有的 RAM，而是裝置的 RAM，也就是您可以使用的部分，以及您還需要在該硬體上執行的其他應用程式和其他工具。

所以，您可以使用 50% 的 RAM，還是只能使用 10%？

最後，你會看到準備度指數。

如果顯示綠色，表示設定已完成。

如果顯示橘色、黃色或紅色，表示可能需要變更設定。

您可能需要更快的加速器來降低延遲，或需要更強大的大型模型。

所以，我建議您看看這個。

我們目前提供預先發布版，歡迎你提供意見回饋，協助我們瞭解這項工具的實用性。

Zoe 稍後會進一步說明如何設定部分評估作業，現在我先交給 Jose，他會快速示範如何開始使用 Gemma 4。

謝謝 Ian。

所以，目前體驗 Gemma 4 最快的方式，應該是透過 Android Studio。

接著，我會說明如何

請切換到筆電。

就像這樣

如果前往設定中的模型供應商頁面，並選取 Gemma，就能清楚瞭解各模型的大小。

只要將模型下載到硬碟即可。

因此，這會開啟或啟動 llama.cpp 伺服器，並從一開始就正確設定。

不過，您也可以視需要使用自己的 llama.cpp 伺服器、Ollama 或 LM Studio。

只要在這裡新增本機供應商即可。

此外，透過遠端供應商使用小型模型也相當合理。

因此，您可以在這裡新增一個，只要與 OpenAI 或 Anthropic 相容，就能連線。

好，我們來看看。

順帶一提，在 Android Studio 中，您顯然可以透過這個下拉式選單選取模型。

我選取了 Gemma 4 26B，並詢問「什麼是 ViewModel？」

好的。

因此，請務必記住，每當您變更模型時，整個對話都會從頭重新傳送至新模型。

因此，如果您與模型進行了很長的對話，並想切換到新的對話，建議您開始新的對話，或壓縮對話等。

現在回到投影片，由 Zoe 介紹小型模型可執行的各種工作流程。

非常感謝 Jose 和 Ian 介紹 Gemma 模型，並說明我們是否已達到目標。

我們已經瞭解有哪些模型類型和規格，現在要瞭解可以讓模型執行哪些工作。

第一種工作是您可能已經在做的，例如偵錯或疑難排解等程式設計工作流程，或是我相信大家 (或至少我) 會非常諷刺地懷念手動執行的工作，也就是提高測試涵蓋率。

對吧？

所以，這些是，你知道的，我相當確定每個人都已經在做的一些事情，甚至，可能，在沒有意識到的情況下。

但我希望大家能跳脫這個框架，

小型模型可以開放權重，並在本機執行，因此能為您節省時間。

對吧？

我們討論的是不使用火箭，為什麼要用大腦代表？

如果能突破這項限制，小型模型可以做到哪些事？

有哪些工作流程可以讓他們參與，讓你的生活更輕鬆，並有更多時間做想做的事？

舉例來說，確保文件一律會根據您所做的變更更新，或確保您有自動迴歸測試，做為預先修訂掛鉤的一部分，甚至確保代理在工作流程中收到的情境資訊已最佳化，運作速度更快。

以上是幾個例子。

最後，在某種程度上，只有天空或架構是極限，你可以思考如何實作許多事情。

不過，即使有了規格、工具和工作流程，你還是不確定該從何著手嗎？

這就是基準的用途。

正如 Ian 所說，一般排行榜 (尤其是 Python 排行榜) 提供的資訊有限，無法判斷小型模型是否能有效提升 Android 工作流程。

就像石膏板鑽頭可能無法告訴你太多關於混凝土鑽頭的資訊。

但您應該投資自己的評估作業。

您應該投入資源測試自己的架構，但在測試之前，您可能不想投入所有資源。

這需要時間、金錢和精力，因此在決定投資自己的評估之前，先查看公開的基準，可以讓你有一些想法和一份簡短的清單。

評估基準時，有三個重點需要注意，對吧？

這有點抽象，但基本上，首先要瞭解的是，這個模型執行的工作類型是什麼，對吧？

具體程度。

是否與您要指派給它的工作類型相似？

第二個是工作範圍。

例如撰寫說明文件、解決 PR，或與您工作類似的任務？

最後，系統的複雜程度是否與您要提供的複雜程度類似？

這就是為什麼 Python 基準測試無法代表 Android 的原因。

因此，我們打造了 Android Bench，這項基準測試可反映 Android 生態系統和 Android 工作。

第一個版本包含 100 項 PR 大小的 Android 工作，您現在可以透過 Harbor 自行執行，檢查任何代理、模型和技能組合。

我們推出 2.0 版，加入更複雜的長時間執行任務，瞭解前沿模型在處理您目前交辦的工作時，能發揮什麼樣的能力。

接下來，我將交棒給 Jose，由他展示我們透過這項技術取得的成果，並介紹一些最佳化小型模型的方法。

好的，謝謝你，Zoe。

好，我們來看看小型模型可以解決哪些工作，以及哪些工作會開始出現困難。

我們隨意將工作分為四類：小型、中型、大型和長程。

長程任務是指人類可能需要數天或數週才能完成的工作。

例如遷移、大型重構，而且劇透一下，小型模型無法做到這些。

至少不會一次就完成。

我們稍後會再討論。

好，小任務。

這類工作需要讀取和寫入一或兩個檔案，不需要太多知識。

舉例來說，小型模型相當擅長 Compose，至少能處理 Compose 的基本功能。

例如元素之間必須有 8 dp 的間距、使用主題而非硬式編碼顏色，或擷取字串。

小型模型可以輕鬆處理。

不過，這項工作涵蓋更進階的主題，但難度仍然不高。

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

在這種情況下，難度在於範圍，而非知識。

因此，提示實際上會告訴我們應最佳化哪個可組合函式，以及問題所在：每個影格都會重新組成。

因此，即使是 Gemma 4 等小型模型，也能輕鬆完成這項工作。

在這個案例中，只要 3 分鐘就能完成，而且只要變更一行程式碼。

現在我們來做個小測驗

我想大家對小型模型已有充分瞭解。

我們來看看微…抱歉，是小型工作。

接著來看看中等工作。

小型模型應能執行大部分工作。

在這項工作中，Pocket Casts 應用程式的要求缺少使用者代理程式，且重試邏輯有誤。

這個問題稍微難一點，因為我們同時要求兩件事，而且沒有提示這些內容在程式碼集中的位置。

但 Nest Audio 順利通過考驗。

10 分鐘。

修改了三個檔案。

順帶一提，透過 OpenRouter 執行這項操作的費用是 6 美分。

現在來看看同一個資料集失敗的工作。

這是 Now in Android 的範例，其中包含相當完整的報告或提示，但未提及類別名稱或檔案，因此代理需要花費更多心力瞭解應用程式的架構、資料層、同步機制等。因此，在這個特定執行中，它失敗了。

所有內容都已正確實作，但系統假設初始同步處理的值為 -1，但實際上是 0。

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

就是這麼簡單！

如果代理程式執行現有的單元測試，就能發現這個錯誤。

這表示一般來說，較小的模型往往會比先進模型更早停止。

我們只要求代理修正問題，而非驗證問題。

因此，我們或許應該修改工作，加入驗證步驟。

我們稍後也會討論這個問題。

好的，接下來談談大型工作。

根據這項定義，大約有一半的大型工作每次都能通過。

有些失敗的提示實際上太長且複雜，不適合小型模型，因此無法處理。

但有些情況下，當你查看實際發生的情況時，會發現模型已經完成了 90% 或 90% 以上。

我們來選一個。

我選擇這個是因為它不穩定。

執行時約有一半的時間會通過。

因此，我認為這是小型模型能做到的極限。

或至少是 4 月的模型。

這項漏洞與剖析 Coil 程式庫中格式錯誤的網址有關。

如你所見，PR 說明相當完整，但漏掉了一項需求。

我們來快速瞭解一下。

所有執行作業都會檢查一般網址編碼和錯誤，但只有部分 (一半) 執行作業會新增編碼錯誤字元的測試，因此該測試案例會出現在這裡。

未通過評估。

因此，所有執行結果都近乎完美，但這再次證明，小型模型不一定會採取額外步驟。

它們會遵循指令，但不會像前沿模型那樣試圖取悅你。

你知道現在可以設定代理的努力程度嗎？

只是使用小型模型時，這個值會設得太低。

因此，我們將大型任務定義為小型模型約有 50% 的機率能完成的任務，這也是 Gemma 4 31B 在 Android Bench v1 資料集上能達到的水準，也就是 Zoe 之前提到的。

因此，在討論長程任務之前，我們是否能採取任何措施，協助小型模型處理這些任務？

當然，而且這些事情完全不費吹灰之力。

首先，如果像 Ian 一樣在本機使用 Gemma 4 等模型，請確認設定正確。

舉例來說，如果使用 Ollama 提供 Gemma 4，預設脈絡窗口為 32,000 個詞元，但實際支援的數量是八倍。

當然，如果您透過 Android Studio 使用 Gemma 4，就不需要設定。

根據預設，這項設定已正確設定。

在我們的評估中，啟用完整脈絡後，結果從 26% 提升至 53%。

接下來，請使用 Android CLI，這是專門用來搜尋說明文件的 Android CLI 工具。

這不一定適用，因為模型在基本方面表現相當出色，但每當您使用新的或利基 API 時，說明文件就是關鍵。

根據我們的經驗，這比使用網頁搜尋工具好得多。

接著，新增驗證提示。

我們討論過這件事。

告訴模型如何執行測試、有哪些測試類型、如何管理模擬器等。您可以在 AGENTS.md 檔案中執行這項操作，這樣所有代理都能取得操作說明，這其實是件好事。

你應該有。

不過，也要注意 AGENTS.md 檔案是否過長。如果嘗試不同的代理，您會發現有些代理有大量的系統提示和工具說明，這似乎會降低小型模型的效能。

我們實際嘗試使用 OpenCode 執行這些基準測試，結果效能遠低於 pi，可能是因為 OpenCode 使用較大的工具說明和系統提示。

接著，新增技能，但也移除技能。

使用新的利基 API 時，小型模型可能需要提示，但最好不要在情境中填入一般 Compose 技能等。

那麼，長程任務呢？

這類工作涉及數十個檔案，需要做出重大架構決策，通常由思考模型處理，該模型會制定計畫並啟動多個子代理，執行不同工作。

長程任務的例子包括：將整個應用程式從 XML 遷移至 Compose、從頭建立複雜的應用程式，或將跨平台應用程式轉換為原生 Android 應用程式。

Android Bench V2 專門評估長程任務，結果顯示前沿模型的得分落在 3% 到 40% 之間。

因此，小型模型應該無法勝任這項工作。

不過，如果先透過前沿模型進行初步分析，再將較簡單的工作交給較小的模型，就能大幅提高詞元和點數的使用效率。

一起來看看如何執行：

回到 Zoe。

非常感謝，Jose。

我們稍後會介紹串接，但在深入探討或介紹一些方法之前，我想先退一步，說明如何透過其他方式，利用不同模型的自動化調度管理功能。

舉例來說，自動化調度管理功能可以協助您避免遭到封鎖，對吧？

因此，無論是供應商服務中斷、達到 API 頻率限制，還是像 Ian 說的，在飛機或火車上，您都可以設定備用模型，無論是在線上還是本機，都能在發生任何狀況時繼續運作。

另一種做法是透過自動化調度管理取得更準確的答案。

舉例來說，您可以讓小型模型獨立運作，並在需要協助時呼叫顧問。

您也可以設定一個委員會，讓不同類型或不同的模型同時執行相同的工作，然後評估不同的回覆，以及每個模型的權重和偏誤如何影響結果。

您也可以使用另一個模型，假設是測試模型。

就像同儕互評。

你可以透過這個看到。

最後，自動化調度管理功能可透過這類串聯方式，協助您提高成本效益。

基本上，您可以手動設定，例如設定一個模型用於規劃，另一個模型用於執行，再一個模型用於測試。

您可以透過多種方式執行，例如在雲端執行，或設定 LiteLLM Proxy 在本機執行。

或者，您也可以使用分類器，根據要求自動將要求轉送至正確的模型類型，這就是 Ian 提到的 Proxy 概念，但會自動執行。

最後，我們來回答 Jose 在講座一開始提出的問題：小型模型和前沿模型在品質和準確度上有何差異？

答案和電腦科學中的許多問題一樣，視情況而定。

不過，我想提醒大家，這是可以設計的。

你可以根據設定方式和玩法，讓這項功能發揮不同效果。

首先，要選擇合適的工具，對吧？

工具分為多種類型。

瞭解並探索這些功能，對吧？

然後找出他們適合或甚至可以做哪些工作。

第二，請務必調整模型取得的範圍，以便執行工作。

例如，任務指令、提供正確且僅限正確的任務背景資訊，以及檢查自身工作的方法。

接著，您當然需要設定並測試整個設定，而不只是單獨測試模型，因為這會造成差異，而且如果您設定了不同的元素設定，您得到的結果可能會有所調整。

最後，您需要設定或建立自己的評估。

最後，您可以同時運用腳踏車和火箭，不必在兩者之間做出選擇，並有效運用預算。

但最重要的是，你可以繼續探索、繼續建構、繼續享受樂趣，對吧？

您可以立即開始，透過 Android Bench 和相關發現設定模型候選清單，或立即在 Android Studio 中使用 Gemma 4。

謝謝各位