[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-databricks-custom-model-serving-endpoints-zh":3,"article-related-databricks-custom-model-serving-endpoints-zh":30,"series-tools-03ca3c65-1597-4a56-aaf5-09949ec0b995":73},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"03ca3c65-1597-4a56-aaf5-09949ec0b995","databricks-custom-model-serving-endpoints-zh","Databricks 端點讓你少猜","\u003Cp data-speakable=\"summary\">這篇把 Databricks 自訂模型服務端點的權限、Registry、流量與部署模板整理成可直接照抄的版本。\u003C\u002Fp>\u003Cp>我用 Databricks 模型服務一陣子了，越用越覺得它不是不行，是很會把人搞到懷疑自己。端點建起來看起來很順，結果一更新就冒出 \u003Ccode>PERMISSION_DENIED\u003C\u002Fcode>；明明模型有掛上去，卻因為建立者身份、Unity Catalog 權限、還有那個會依模型所在位置變來變去的表單，整個流程卡得像老電腦。我本來以為這只是 UI 難用，後來才發現根本不是。它是在逼你把「誰建立、誰擁有、誰能更新」這三件事先講清楚，不然就等著踩雷。\u003C\u002Fp>\u003Cp>這次我拆的是 Databricks 官方文件 \u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fcreate-manage-serving-endpoints\">Create custom model serving endpoints\u003C\u002Fa>，搭配 \u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Findex.html\">Model Serving 總覽\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fmanage-permissions.html\">權限說明\u003C\u002Fa>，還有 \u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Fen\u002Fdev-tools\u002Fsdk-python.html\">Databricks Python SDK\u003C\u002Fa>。文件本身有寫，但真正會害你出事的，通常不是功能，而是那些看起來像細節、其實是地雷的地方。官方沒給觀看數或星數，我就不亂掰了。\u003C\u002Fp>\u003Ch2>先別急著建端點，先搞清楚誰在背鍋\u003C\u002Fh2>\u003Cblockquote>當你建立端點時，Databricks 會把呼叫者身分記成端點建立者。這個身分通常是 service principal，之後會代表端點去存取 Unity Catalog 資源，而且建立後不能改。\u003C\u002Fblockquote>\u003Cp>白話就是：你以為你是在建一個端點，Databricks 其實是在記錄「這個端點以後算誰的」。這個人不是備註欄位，不是裝飾，是之後更新、查權限、碰 UC 資源時會被拿來驗證的身分。你如果用某個工程師的個人帳號去建，三天後他離開團隊，端點就會開始用最難看的方式提醒你：當初不該偷懶。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782003811403-1hhn.png\" alt=\"Databricks 端點讓你少猜\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我之前就遇過一個很煩的案例。團隊趕著上線，直接用值班同仁的帳號把端點建起來，當下都正常。結果那位同仁調組後，某次更新直接炸掉，錯誤就是 \u003Ccode>PERMISSION_DENIED\u003C\u002Fcode>。那時候大家還以為是模型版本壞掉，查半天才發現是建立者身分已經不在 workspace 裡了。這種問題最討厭的地方不是難修，是它看起來像隨機故障。\u003C\u002Fp>\u003Cp>實操寫法很簡單：建立端點時，優先用 service principal，不要拿人類帳號硬上。然後把這個 service principal 當成長期資產管理，確保它還留在 workspace、還有需要的權限、還能碰得到 Unity Catalog。要是你已經用錯身分建了，別幻想可以局部補救，官方的做法就是刪掉重建，讓正確的身分重新成為建立者。\u003C\u002Fp>\u003Cul>\u003Cli>建立端點的人，最好固定是 service principal。\u003C\u002Fli>\u003Cli>這個身分要保留 workspace membership。\u003C\u002Fli>\u003Cli>更新前先假設建立者權限會被重新檢查。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>表單不是在問好玩，它是在分流你的模型來源\u003C\u002Fh2>\u003Cblockquote>點進 Entity 欄位後，選取要服務的實體表單。依照模型註冊位置，選擇 My models - Unity Catalog 或 My models - Model Registry。表單會依你的選擇動態更新。\u003C\u002Fblockquote>\u003Cp>這段很容易被忽略，因為 UI 看起來像只是多問你一個選項，但它其實是在先問：你的模型到底放哪裡。放在 Unity Catalog，還是放在 Workspace Model Registry，後面整套路徑、權限、版本解析都不一樣。你如果心裡沒先定義清楚，後面就會一直在那邊猜，猜到最後只是在跟錯誤訊息對話。\u003C\u002Fp>\u003Cp>我現在會把這件事當成第一個決策點，不是最後一步。原因很簡單，因為 Databricks 並不是用同一套邏輯處理兩種 Registry。Unity Catalog 要的是完整的 \u003Ccode>catalog.schema.model_name\u003C\u002Fcode>，workspace registry 則走另一條路。你如果把這兩個世界混在一起，端點看似建立成功，實際上只是把未來的自己推去撞牆。\u003C\u002Fp>\u003Cp>實操寫法：先決定模型歸屬，再去填端點。模型在 Unity Catalog，就老老實實用完整名稱；模型在 Workspace Model Registry，就在 UI 選對來源，不要硬把兩邊的命名習慣混用。這不是格式潔癖，這是避免你之後在權限與版本上來回試錯。\u003C\u002Fp>\u003Cul>\u003Cli>Unity Catalog 模型：用完整路徑 \u003Ccode>catalog.schema.model_name\u003C\u002Fcode>。\u003C\u002Fli>\u003Cli>Workspace Model Registry：先選對來源，再填版本。\u003C\u002Fli>\u003Cli>建立前先確認你要的是哪一版模型，不要靠印象。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>權限不是一次檢查完就沒事，它會在兩個時間點咬你\u003C\u002Fh2>\u003Cp>我覺得 Databricks 最值得記住的地方，就是它把權限分成兩種時機在\u003Ca href=\"\u002Fnews\u002Fopenai-partner-network-enterprise-ai-scale-zh\">檢查\u003C\u002Fa>。第一種是建立或更新端點時，第二種是實際有流量打進來時。很多人只看前者，然後在 production 被後者補刀，還一頭霧水。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782003812410-guw0.png\" alt=\"Databricks 端點讓你少猜\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>如果你服務的是 Unity Catalog 模型，建立者至少要有 \u003Ccode>USE CATALOG\u003C\u002Fcode>、\u003Ccode>USE SCHEMA\u003C\u002Fcode>、\u003Ccode>EXECUTE\u003C\u002Fcode> 這幾個權限。模型如果還依賴其他函式，連上游函式的 \u003Ccode>EXECUTE\u003C\u002Fcode> 也要一併有。少一個，建立或更新就可能直接失敗。這裡不是「最好有」，是「沒給就別想過」。\u003C\u002Fp>\u003Cp>我以前最常看到的錯誤，就是大家只去補模型本身的權限，忘了 schema。結果 endpoint 建不過，還以為是 UI 壞掉。其實不是，Databricks 只是照規則檢查而已。只是這規則很不客氣，錯了就直接拒絕，不會幫你猜。\u003C\u002Fp>\u003Cp>實操寫法：先做一份建立者權限清單，包含 catalog、schema、model、上游函式。你可以把它當成部署前檢查表，先確認再動手。然後記得，端點建立成功\u003Ca href=\"\u002Fnews\u002Fchatgpt-10yi-yuehuo-ai-zhushou-bu-shi-yingjia-tongchi-zh\">不代表\u003C\u002Fa>萬事大吉，query-time 的權限還是可能在實際請求時失敗，所以要把「能建立」跟「能穩定服務」分開看。\u003C\u002Fp>\u003Cul>\u003Cli>先檢查建立者是不是 workspace 成員。\u003C\u002Fli>\u003Cli>再檢查 UC 權限鏈。\u003C\u002Fli>\u003Cli>建立成功後，還要另外測實際查詢。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>流量分配跟併發，才是你真正要算的帳\u003C\u002Fh2>\u003Cp>Databricks 提供 traffic split 和 compute sizing，這其實就是在叫你\u003Ca href=\"\u002Fnews\u002Fskill-to-lora-cuts-agent-token-overhead-zh\">別再\u003C\u002Fa>憑感覺配資源。你可以把流量切到不同 served entity，也可以依照模型吞吐量去選擇併發規模。官方甚至直接丟了一個很實在的估算方式：併發數大概抓 \u003Ccode>QPS x model run time\u003C\u002Fcode>。\u003C\u002Fp>\u003Cp>這句我很買單，因為它把很多人愛講的「先開小一點看看」直接打回去。你如果知道 QPS，知道單次推論時間，就可以開始算了，不用靠運氣。像一個請求 200 毫秒、每秒 20 個請求的模型，跟一個每次要 3 秒的模型，資源需求根本不是同一個量級。你不先算，最後就是 latency 跟成本一起爆。\u003C\u002Fp>\u003Cp>實際上我看過不少團隊把 endpoint 開得很小，測試時都沒事，正式流量一進來就開始抖。問題不是模型不行，是你根本沒用真實負載去配。Databricks 有 Small、Medium、Large 這些範圍，\u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> 和 SDK 也能設自訂併發；如果你要用自訂值，記得要是 4 的倍數，這種小規則不先記起來，就很容易卡在奇怪的地方。\u003C\u002Fp>\u003Cp>實操寫法：先用觀察到的 QPS 和平均推論時間算出大概需要的併發，再選最小但不會卡住的配置。如果你要同時跑多個版本，就明確切 traffic split，不要把版本混成一團。要做自動化，就用 REST API 或 SDK，不要每次都靠 UI 手動改，久了只會漂移。\u003C\u002Fp>\u003Cul>\u003Cli>Small：適合 0 到 4 個請求。\u003C\u002Fli>\u003Cli>Medium：適合 8 到 16 個請求。\u003C\u002Fli>\u003Cli>Large：適合 16 到 64 個請求。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Scale to zero 很省錢，但 production 會記恨你\u003C\u002Fh2>\u003Cp>官方對這件事講得很直接：scale to zero 不建議拿來做 production endpoint，因為冷啟動時不保證容量，流量回來時你會先吃到延遲。這不是理論問題，是使用者真的會感受到的問題。\u003C\u002Fp>\u003Cp>我不反對 scale to zero，我自己也會拿來做 demo、測試環境，或那種偶爾才會被打到的端點。但如果這條端點是產品流程的一部分，我就不想賭。因為第一個請求慢，不只是慢而已，它會讓整個體驗看起來很不穩。你省下來的錢，常常是拿使用者耐心去換的。\u003C\u002Fp>\u003Cp>實操寫法：低風險、低頻率的 workload 可以留著 scale to zero；正式上線、重視回應時間的路徑就關掉。你如果很在意首請求延遲，別省那點錢。這不是道德選擇，是成本跟體驗的取捨。\u003C\u002Fp>\u003Ch2>同一件事有四種入口，方便，但也很容易抄錯\u003C\u002Fh2>\u003Cp>Databricks 讓你可以用 Serving UI、REST API、MLflow Deployments SDK，或 Databricks Workspace Client SDK 來建立端點。這種彈性我承認很方便，但也很容易讓人把不同情境的範例混著抄，最後配置語法對不上。\u003C\u002Fp>\u003Cp>我自己的做法是，正式自動化只選一條路走到底。UI 適合第一次摸、快速驗證；REST API 比較像基礎設施操作，配置明確；SDK 則適合 Python 腳本化部署。每條路都能做同一件事，但你最好只挑一條當主線，不然之後排查差異會很痛苦。\u003C\u002Fp>\u003Cp>實操寫法：如果你要做 production，先決定團隊標準是 API 還是 SDK，然後把範例固化。不要今天 UI 建、明天 API 改、後天又手動補設定。那種做法短期看起來快，長期就是 config drift 的溫床。\u003C\u002Fp>\u003Cul>\u003Cli>UI：適合人工檢查與快速試錯。\u003C\u002Fli>\u003Cli>REST API：適合明確可追蹤的部署設定。\u003C\u002Fli>\u003Cli>MLflow Deployments SDK \u002F Workspace Client SDK：適合 Python 自動化。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>GPU 不是勾一下就好，版本不對一樣白搭\u003C\u002Fh2>\u003Cp>如果你要走 \u003Ca href=\"\u002Ftag\u002Fgpu\">GPU\u003C\u002Fa> serving，Databricks 不是只給你一個勾選框而已，它還會看你套件版本合不合。官方列得很清楚：PyTorch 1.13.0 到 2.0.1、TensorFlow 2.5.0 到 2.13.0、MLflow 2.4.0 以上。版本不在範圍內，別幻想只是小問題。\u003C\u002Fp>\u003Cp>這點我很有感，因為很多模型在本機或訓練環境跑得好好的，一搬到服務端就開始出現相依性問題。GPU endpoint 需要對應的 workload type，像 \u003Ccode>GPU_SMALL\u003C\u002Fcode> 這種設定也不是裝飾。你如果只看到 GPU 兩個字就衝，很容易在上線前才發現 runtime 不合。\u003C\u002Fp>\u003Cp>實操寫法：先盤點模型使用的套件版本，再決定要不要上 GPU。版本在支援範圍邊緣的，先升級或固定版本，別邊跑邊賭。接著再把 workload type、workload size 一起設好，最後用真實請求把整條路測過一次，不要只驗 artifact 能不能載入。\u003C\u002Fp>\u003Cp>我也順手把常用參考放這裡：\u003Ca href=\"https:\u002F\u002Fmlflow.org\u002Fdocs\u002Flatest\u002Fpython_api\u002Fmlflow.deployments.html\">MLflow Deployments\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Fen\u002Fdev-tools\u002Fsdk-python.html\">Databricks Workspace Client SDK\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Findex.html\">Model Serving 總覽\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fmanage-permissions.html\">權限說明\u003C\u002Fa>。這些連結我自己也會留著，因為單看一頁常常會漏掉上下文。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Databricks 自訂模型服務端點檢查表\n\n## 建立前先確認\n- 先決定模型是在 Unity Catalog，還是在 Workspace Model Registry。\n- 端點建立者請固定用 service principal。\n- 確認這個身分還在 workspace，且有 workspace-access entitlement。\n- 如果是 Unity Catalog 模型，請先確認：\n  - catalog 上有 USE CATALOG\n  - schema 上有 USE SCHEMA\n  - model 上有 EXECUTE\n  - 若有上游函式，也要有 EXECUTE\n\n## UI 建立流程\n1. 打開 Databricks 側邊欄的 Serving。\n2. 點 Create serving endpoint。\n3. 輸入端點名稱。\n4. 在 Entity 欄位選擇：\n   - My models - Unity Catalog，或\n   - My models - Model Registry\n5. 選模型與版本。\n6. 設定 traffic percentage。\n7. 選 CPU 或 GPU compute。\n8. 設定 compute scale-out：\n   - Small：0-4 requests\n   - Medium：8-16 requests\n   - Large：16-64 requests\n9. 產品環境不要開 scale to zero。\n10. 視需要加上：\n    - served entity 重新命名\n    - instance profile\n    - environment variables\n    - inference table logging\n11. 需要多版本就再加 served entities。\n12. 流量高就開 route optimization。\n13. 需要的話再配 AI Gateway。\n14. 按 Create。\n\n## REST API 範例\nPOST \u002Fapi\u002F2.0\u002Fserving-endpoints\n{\n  \"name\": \"uc-model-endpoint\",\n  \"config\": {\n    \"served_entities\": [\n      {\n        \"name\": \"ads-entity\",\n        \"entity_name\": \"catalog.schema.my-ads-model\",\n        \"entity_version\": \"3\",\n        \"min_provisioned_concurrency\": 4,\n        \"max_provisioned_concurrency\": 12,\n        \"scale_to_zero_enabled\": false\n      }\n    ]\n  }\n}\n\n## MLflow Deployments 範例\nimport mlflow\nfrom mlflow.deployments import get_deploy_client\n\nmlflow.set_registry_uri(\"databricks-uc\")\nclient = get_deploy_client(\"databricks\")\nendpoint = client.create_endpoint(\n    name=\"unity-catalog-model-endpoint\",\n    config={\n        \"served_entities\": [\n            {\n                \"name\": \"ads-entity\",\n                \"entity_name\": \"catalog.schema.my-ads-model\",\n                \"entity_version\": \"3\",\n                \"min_provisioned_concurrency\": 4,\n                \"max_provisioned_concurrency\": 12,\n                \"scale_to_zero_enabled\": False,\n            }\n        ]\n    },\n)\n\n## Workspace Client SDK 範例\nfrom databricks.sdk import WorkspaceClient\nfrom databricks.sdk.service.serving import EndpointCoreConfigInput, ServedEntityInput\n\nw = WorkspaceClient()\nw.serving_endpoints.create(\n    name=\"uc-model-endpoint\",\n    config=EndpointCoreConfigInput(\n        served_entities=[\n            ServedEntityInput(\n                name=\"ads-entity\",\n                entity_name=\"catalog.schema.my-ads-model\",\n                entity_version=\"3\",\n                workload_size=\"Small\",\n                scale_to_zero_enabled=False,\n            )\n        ]\n    ),\n)\n\n## GPU 端點範例\nPOST \u002Fapi\u002F2.0\u002Fserving-endpoints\n{\n  \"name\": \"gpu-model-endpoint\",\n  \"config\": {\n    \"served_entities\": [\n      {\n        \"entity_name\": \"catalog.schema.my-gpu-model\",\n        \"entity_version\": \"1\",\n        \"workload_type\": \"GPU_SMALL\",\n        \"workload_size\": \"Small\",\n        \"scale_to_zero_enabled\": false\n      }\n    ]\n  }\n}\n\n## 營運規則\n- 同一個團隊盡量固定一條部署路徑。\n- 端點建立者身分要穩定。\n- 若建立者失去 workspace membership，更新很可能失敗。\n- scale to zero 當成成本選項，不要當 production 預設。\n- 每次改端點設定，都重查權限。\n- 建立成功不代表查詢一定成功，查詢權限要另外測。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板就是我把官方文件拆完後，留下來真的能用的版本。你可以直接拿去當部署前檢查表，至少不會再把「誰建立的」和「誰能更新」這兩件事搞混。\u003C\u002Fp>\u003Cp>來源主要來自 Databricks 官方文件 \u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fcreate-manage-serving-endpoints\">Create custom model serving endpoints\u003C\u002Fa>。我這篇的重點整理、風險提醒、與可抄模板是我自己重新整理的，原始規則與介面說明則以官方文件為準。\u003C\u002Fp>","我拆 Databricks 自訂模型服務端點的權限、Registry、流量與部署模板，整理成可直接照抄的實作清單。","docs.databricks.com","https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fcreate-manage-serving-endpoints",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782003811403-1hhn.png","tools","zh","bbd8f1b2-71b5-4db9-8c81-b40df39fd62b",[17,18,19,20,21],"Databricks","Unity Catalog","model serving","service principal","REST API",[23,24,25],"建立端點時要固定建立者身分，最好用 service principal。","先分清楚模型在 Unity Catalog 還是 Workspace Model Registry，再填配置。","權限、流量與 scale to zero 都會直接影響 production 穩定性。",0,"2026-06-21T01:03:09.88432+00:00","2026-06-21T01:03:09.879+00:00","2280f033-e3ad-4cc4-8f0e-10a6d08600f5",{"tags":31,"relatedLang":32,"relatedPosts":36},[],{"id":15,"slug":33,"title":34,"language":35},"databricks-custom-model-serving-endpoints-en","Databricks endpoints that stop guessing","en",[37,43,49,55,61,67],{"id":38,"slug":39,"title":40,"cover_image":41,"image_url":41,"created_at":42,"category":13},"4860bd59-d197-4c32-a4aa-e3f53aa08d7a","bigquery-vectorized-python-udfs-arrow-zh","BigQuery Arrow 向量化 Python UDF 實作","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782027159471-91jd.png","2026-06-21T07:32:19.997774+00:00",{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"642eb00a-f3cd-422f-9d29-e113dc82e5d3","apples-gemini-powered-siri-seo-stakes-zh","Apple Siri 接上 Gemini，SEO 壓力升高","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782011869139-s32t.png","2026-06-21T03:17:28.557729+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"1210fbca-7d00-4a0d-9be2-39163079dbb0","go-turns-team-chaos-into-boring-builds-zh","Go 把團隊混亂變成穩定建置","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781971401098-zdl4.png","2026-06-20T16:02:53.571588+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"44069991-6152-4495-879f-c4e727541300","fde-sales-engineering-playbook-zh","FDE把售前和工程拧成一股绳","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781965996042-v9rb.png","2026-06-20T14:32:50.484812+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"7beaabe3-5421-4e2b-a42a-d1a7b669be12","deploy-minimax-m3-with-vllm-openai-api-zh","用 vLLM 部署 MiniMax M3 並開啟 OpenAI API","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781954276176-k5fw.png","2026-06-20T11:17:30.019598+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"fe9fecba-d6ae-4293-af38-e68e6c2c111b","namastack-turns-outbox-pain-into-reliable-events-zh","Namastack 把 outbox 變穩定事件流","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781949794069-sfg2.png","2026-06-20T10:02:49.479466+00:00",[74,79,84,89,94,99,104,109,114,119],{"id":75,"slug":76,"title":77,"created_at":78},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":80,"slug":81,"title":82,"created_at":83},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":85,"slug":86,"title":87,"created_at":88},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]