[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-databricks-custom-model-serving-endpoints-en":3,"article-related-databricks-custom-model-serving-endpoints-en":30,"series-tools-bbd8f1b2-71b5-4db9-8c81-b40df39fd62b":75},{"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},"bbd8f1b2-71b5-4db9-8c81-b40df39fd62b","databricks-custom-model-serving-endpoints-en","Databricks endpoints that stop guessing","\u003Cp data-speakable=\"summary\">A practical Databricks model-serving setup you can copy.\u003C\u002Fp>\u003Cp>I've been using Databricks model serving long enough to know when the docs are helping and when they're just moving the furniture around. This one was the latter for me. I could get an endpoint created, sure, but the behavior around creator identity, Unity Catalog grants, traffic split, and that weird little UI form that changes depending on where the model lives kept biting me. One minute I'm thinking, “fine, I'll just point the endpoint at the model,” and the next minute I'm staring at \u003Ccode>PERMISSION_DENIED\u003C\u002Fcode> because the recorded creator lost access three days ago. That is not a fun way to learn how serving works.\u003C\u002Fp>\u003Cp>What finally made it click was treating Databricks serving endpoints less like a checkbox in the UI and more like a permissioned deployment object with a lifecycle. Once I stopped assuming the caller and the creator were the same thing forever, the rest started making sense. The docs I’m breaking down here are from \u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fcreate-manage-serving-endpoints\">Databricks’ AWS model serving guide\u003C\u002Fa>, and the details that matter are not the glossy ones. They’re the ones that decide whether your endpoint comes up cleanly or dies on update.\u003C\u002Fp>\u003Ch2>Databricks is not just serving a model, it is recording who owns the blast radius\u003C\u002Fh2>\u003Cblockquote>When you create an endpoint, Databricks records the calling identity as the endpoint's creator. This identity — typically a service principal — is used to access Unity Catalog resources on behalf of the endpoint and cannot be changed after creation.\u003C\u002Fblockquote>\u003Cp>What this actually means is: the identity that creates the endpoint is not just metadata. It becomes the identity Databricks uses later when the endpoint needs to touch Unity Catalog objects. If that identity loses access, or gets removed from the workspace, the endpoint doesn't politely degrade. It starts failing updates, and sometimes creation itself becomes a permission mess.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782003812998-rhzh.png\" alt=\"Databricks endpoints that stop guessing\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>I ran into this exact kind of nonsense when a team created endpoints from a human account during a rush deploy. Everything worked until that person left the workspace and an update failed with \u003Ccode>PERMISSION_DENIED\u003C\u002Fcode>. That’s the kind of failure that feels random if you haven’t read this part carefully. It isn’t random. It’s Databricks doing exactly what it said it would do, just in the least forgiving way possible.\u003C\u002Fp>\u003Cp>How to apply it: create serving endpoints with a service principal, not a random engineer’s login, and make sure that identity is the one you actually want attached to the endpoint for the long haul. If you already created it with the wrong identity, the docs are blunt about the fix: delete the endpoint and recreate it under an identity that has the right permissions and still belongs to the workspace.\u003C\u002Fp>\u003Cul>\u003Cli>Use a service principal as the recorded creator whenever possible.\u003C\u002Fli>\u003Cli>Keep that identity in the workspace and grant it the UC permissions it needs.\u003C\u002Fli>\u003Cli>Assume endpoint updates will re-check creator membership and grants.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>The UI form is not magic, it is a fork in your model registry path\u003C\u002Fh2>\u003Cblockquote>Click into the Entity field to open the Select served entity form. Select either My models- Unity Catalog or My models- Model Registry based on where your model is registered. The form dynamically updates based on your selection.\u003C\u002Fblockquote>\u003Cp>This is the part that looks simple until you realize Databricks is asking you to choose the model’s registry source before it can even show the right fields. If your model is in Unity Catalog, the endpoint config needs the full catalog.schema.model path. If it lives in the Workspace Model Registry, the UI routes you differently. Same endpoint concept, different source of truth.\u003C\u002Fp>\u003Cp>I actually like this once I stop pretending the UI is being cute. It’s forcing you to declare where the model is managed, which matters because permissions, naming, and version resolution all depend on that choice. If you skip over that detail, you end up with an endpoint config that looks valid but points at the wrong registry path or the wrong permission model.\u003C\u002Fp>\u003Cp>How to apply it: before you click Create, decide which registry owns the model. Then fill the endpoint from that registry outward. For Unity Catalog, always use the fully qualified model name. For workspace registry models, stick to the workspace path the UI expects. Don’t mix the two in your head; Databricks absolutely does not.\u003C\u002Fp>\u003Cul>\u003Cli>Unity Catalog model: use \u003Ccode>catalog.schema.model_name\u003C\u002Fcode>.\u003C\u002Fli>\u003Cli>Workspace Model Registry model: select the workspace registry option in the UI.\u003C\u002Fli>\u003Cli>Always confirm the model version before creating the endpoint.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Permissions are checked twice, and that is where people get burned\u003C\u002Fh2>\u003Cp>The docs split permissions into two buckets, and I think that distinction is the most useful thing in the whole page. Some grants are validated \u003Ca href=\"\u002Fnews\u002Fai-coding-assistant-roi-measured-en\">when you\u003C\u002Fa> create or update the endpoint. Others are only checked when traffic actually hits the model. That difference matters a lot, because it explains why an endpoint can be created successfully and still fail later in production.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782003809965-zz2p.png\" alt=\"Databricks endpoints that stop guessing\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>For a Unity Catalog model, the recorded creator needs \u003Ccode>USE CATALOG\u003C\u002Fcode> on the catalog, \u003Ccode>USE SCHEMA\u003C\u002Fcode> on the schema, and \u003Ccode>EXECUTE\u003C\u002Fcode> on the model. If the model has transitive function dependencies, the creator also needs \u003Ccode>EXECUTE\u003C\u002Fcode> on those upstream functions. This is not optional fluff. Databricks checks it at endpoint creation or update, and missing grants fail the request with \u003Ccode>PERMISSION_DENIED\u003C\u002Fcode>.\u003C\u002Fp>\u003Cp>What I’d tell a teammate is this: if your endpoint creation is failing, don’t just stare at the model permission. Walk the chain. Catalog, schema, model, and any dependent functions. I’ve seen people waste time because they granted access to the model but forgot the schema. That is the kind of mistake that feels insulting once you see it.\u003C\u002Fp>\u003Cp>How to apply it: build a deployment checklist for the endpoint creator identity. If you are using Unity Catalog, verify access before you touch the serving UI or \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa>. And if the endpoint is already live, remember that query-time permissions can still fail later even if creation succeeded. That’s why “it created fine” is not the same thing as “it’s safe.”\u003C\u002Fp>\u003Cul>\u003Cli>Check creator membership in the workspace.\u003C\u002Fli>\u003Cli>Check UC grants before endpoint creation.\u003C\u002Fli>\u003Cli>Remember query-time access can fail later even if creation passed.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Traffic split and concurrency are where the actual serving math lives\u003C\u002Fh2>\u003Cp>Databricks gives you a traffic split and a compute sizing model, and this is where the endpoint stops being a static deployment and starts acting like a capacity planning problem. You can route a percentage of traffic to each served entity, and you can choose compute scale-out based on how many requests the model can process at once. The docs even give a rough rule: this number should be about \u003Ccode>QPS x model run time\u003C\u002Fcode>.\u003C\u002Fp>\u003Cp>That’s the kind of line I wish more platform docs would say plainly. It means you should stop guessing at compute size from vibes. If your model gets 20 QPS and each request takes 200 ms, your concurrency needs are different than a model that takes 3 seconds per request. Databricks gives you Small, Medium, and Large ranges, plus custom concurrency in the API and SDK paths. Concurrency values must be multiples of 4 when you use the custom settings.\u003C\u002Fp>\u003Cp>I’ve had teams under-size these endpoints because the model looked “lightweight” during testing. Then production traffic showed up and latency went sideways. The fix was not more optimism. It was sizing for actual request volume and runtime. If your endpoint is expected to serve real traffic, the compute choice is part of the product, not an afterthought.\u003C\u002Fp>\u003Cp>How to apply it: estimate real request concurrency from observed QPS and model latency, then choose the smallest size that does not pin the endpoint under load. If you need to split traffic across versions or models, use multiple served entities and control the split explicitly. If you need custom concurrency, use the REST API or SDK and keep the values aligned to multiples of 4.\u003C\u002Fp>\u003Cul>\u003Cli>Small covers 0-4 requests.\u003C\u002Fli>\u003Cli>Medium covers 8-16 requests.\u003C\u002Fli>\u003Cli>Large covers 16-64 requests.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Scale to zero is fine for demos and annoying for production\u003C\u002Fh2>\u003Cp>The docs are pretty direct here: scale to zero is not recommended for production endpoints because capacity is not guaranteed when the endpoint is cold. When traffic comes back, you pay the cold-start penalty. That means extra latency right when someone is trying to use the model, which is exactly when you do not want a surprise.\u003C\u002Fp>\u003Cp>I’m not anti-scale-to-zero. I use it for demos, test environments, and endpoints that are hit sporadically. But for production, I treat it like a cost-saving option with a real user-experience tax. If the endpoint matters to an application path, I would rather keep some capacity warm than explain why the first request after lunch took forever.\u003C\u002Fp>\u003Cp>How to apply it: leave scale to zero on for low-stakes or bursty workloads, but disable it for production paths where latency matters. If you need predictable response times, pay for the always-ready capacity. That’s the tradeoff. There’s no free lunch here, despite what people like to assume when they see the checkbox.\u003C\u002Fp>\u003Ch2>Databricks gives you three ways to do the same thing, which is both useful and mildly annoying\u003C\u002Fh2>\u003Cp>You can create serving endpoints through the Serving UI, the REST API, the MLflow Deployments SDK, or the Databricks Workspace Client SDK. I like that Databricks exposes all four because it lets you pick the right level of control for the job. I also dislike it because it means the same idea is spread across multiple syntaxes, and people inevitably copy the wrong example into the wrong context.\u003C\u002Fp>\u003Cp>The REST API and MLflow Deployments SDK both accept the same endpoint configuration parameters. The Workspace Client SDK wraps that same config in Python objects like \u003Ccode>EndpointCoreConfigInput\u003C\u002Fcode> and \u003Ccode>ServedEntityInput\u003C\u002Fcode>. If you’re scripting deployments, the SDK is nicer. If you need direct infrastructure-style control, the REST API is clearer. If you’re still figuring the model out, the UI is the fastest place to make mistakes and see them immediately.\u003C\u002Fp>\u003Cp>How to apply it: pick one path for production automation and stick to it. I would not mix UI-created endpoints with ad hoc API updates unless there’s a good reason. The more you standardize on one creation path, the less likely you are to get config drift across teams.\u003C\u002Fp>\u003Cul>\u003Cli>UI: best for manual setup and quick validation.\u003C\u002Fli>\u003Cli>REST API: best for explicit endpoint config.\u003C\u002Fli>\u003Cli>MLflow Deployments SDK and Workspace Client SDK: best for Python automation.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>GPU support is not just a checkbox, it is a compatibility filter\u003C\u002Fh2>\u003Cp>Databricks calls out \u003Ca href=\"\u002Ftag\u002Fgpu\">GPU\u003C\u002Fa> deployment compatibility with specific package versions: PyTorch 1.13.0 through 2.0.1, TensorFlow 2.5.0 through 2.13.0, and MLflow 2.4.0 and above. That matters because GPU serving is not just “turn on GPU and go.” Your model stack has to fit the supported versions or you’re going to have a bad time.\u003C\u002Fp>\u003Cp>If you’ve ever tried to ship a model that worked on your laptop and then fell apart under a different runtime, you already know why this section exists. GPU endpoints need the right workload type, and the docs show the same creation flow with \u003Ccode>workload_type\u003C\u002Fcode> set to something like \u003Ccode>GPU_SMALL\u003C\u002Fcode>. The UI also exposes GPU types from the Compute Type dropdown.\u003C\u002Fp>\u003Cp>How to apply it: verify your model library versions before you commit to GPU serving. If you’re on the edge of the supported range, upgrade or pin carefully. Then choose the GPU workload type in the endpoint config and test the whole path, not just the model artifact.\u003C\u002Fp>\u003Cp>For the actual platform docs, I’d also keep these nearby: \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\">Databricks Model Serving overview\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fdocs.databricks.com\u002Faws\u002Fen\u002Fmachine-learning\u002Fmodel-serving\u002Fmanage-permissions.html\">model serving permissions\u003C\u002Fa>. They fill in the gaps this page assumes you already know.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Databricks model serving endpoint checklist\n\n## Before you create\n- Decide whether the model is in Unity Catalog or the Workspace Model Registry.\n- Use a service principal as the endpoint creator.\n- Verify the creator has workspace membership and workspace-access entitlement.\n- For Unity Catalog models, verify:\n  - USE CATALOG on the catalog\n  - USE SCHEMA on the schema\n  - EXECUTE on the model\n  - EXECUTE on upstream functions, if any\n\n## Serving UI setup\n1. Open Serving in the Databricks sidebar.\n2. Click Create serving endpoint.\n3. Enter an endpoint name.\n4. In Entity, choose:\n   - My models - Unity Catalog, or\n   - My models - Model Registry\n5. Select the model and version.\n6. Set traffic percentage.\n7. Choose CPU or GPU compute.\n8. Pick compute scale-out:\n   - Small: 0-4 requests\n   - Medium: 8-16 requests\n   - Large: 16-64 requests\n9. Disable scale to zero for production endpoints.\n10. Add optional settings:\n    - Rename served entity\n    - Instance profile\n    - Environment variables\n    - Inference table logging\n11. Add more served entities if needed.\n12. Enable route optimization if throughput is high.\n13. Configure AI Gateway features if needed.\n14. Click Create.\n\n## REST API example\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 example\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 example\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 endpoint example\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## Operational rules\n- Use one deployment path consistently.\n- Keep the recorded creator identity stable.\n- Expect update failures if the creator loses workspace membership.\n- Treat scale to zero as a cost choice, not a default for production.\n- Recheck permissions whenever endpoint config changes.\n- Test query-time access separately from creation-time validation.\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>That template is basically the distilled version of the docs, minus the part where you have to keep rereading the page to remember which identity Databricks is actually using. I’ve found that writing the creator identity and permission checklist down next to the endpoint config saves a stupid amount of time later.\u003C\u002Fp>\u003Cp>The original source is 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> page. My breakdown is derivative of that documentation, but the framing, warnings, and deployment checklist are mine.\u003C\u002Fp>","A practical breakdown of Databricks model serving setup, permissions, and endpoint config with a copy-ready template.","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-1782003812998-rhzh.png","tools","en","03ca3c65-1597-4a56-aaf5-09949ec0b995",[17,18,19,20,21],"Databricks","model serving","Unity Catalog","MLflow","GPU endpoints",[23,24,25],"Creator identity is permanent and controls endpoint access to Unity Catalog.","UI, REST API, and SDK paths all create the same endpoint concept with different ergonomics.","Scale-to-zero and concurrency choices are operational tradeoffs, not just config toggles.",0,"2026-06-21T01:03:10.338776+00:00","2026-06-21T01:03:10.332+00:00","0c42cb32-a243-4a33-92ed-0549a19cbd89",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":20,"slug":33},"mlflow",{"id":15,"slug":35,"title":36,"language":37},"databricks-custom-model-serving-endpoints-zh","Databricks 端點讓你少猜","zh",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"decd40da-6ddd-45f0-835f-7981d0f45111","cudf-turns-pandas-code-into-gpu-runs-en","cuDF turns pandas code into GPU runs","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782058729869-s0tn.png","2026-06-21T16:18:27.628499+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"a0d9f17c-ff77-49c2-bf56-d78cebffc801","bigquery-vectorized-python-udfs-arrow-en","BigQuery vectorized Python UDFs with Arrow","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782027164452-1u37.png","2026-06-21T07:32:20.57785+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"e3deb33e-ba49-4722-aeaf-eb85c71d6338","apples-gemini-powered-siri-seo-stakes-en","Apple’s Gemini-Powered Siri Raises SEO Stakes","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782011872881-96h8.png","2026-06-21T03:17:28.996623+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"16db1c34-d629-49ac-987b-297bb1b90a41","go-turns-team-chaos-into-boring-builds-en","Go turns team chaos into boring builds","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781971403049-v0dz.png","2026-06-20T16:02:54.021206+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"3ef4d3d4-b628-498c-acb7-34131b1a60cd","fde-role-sales-engineering-playbook-en","FDE岗位把售前和工程拧成一股绳","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781966000604-7muv.png","2026-06-20T14:32:51.011973+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"77c071b4-4373-449e-b812-2577d9644514","deploy-minimax-m3-with-vllm-openai-api-en","Deploy MiniMax M3 with vLLM OpenAI API","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781954275829-y5gk.png","2026-06-20T11:17:30.525369+00:00",[76,81,86,91,96,101,106,111,116,121],{"id":77,"slug":78,"title":79,"created_at":80},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":82,"slug":83,"title":84,"created_at":85},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":87,"slug":88,"title":89,"created_at":90},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":92,"slug":93,"title":94,"created_at":95},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":97,"slug":98,"title":99,"created_at":100},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":102,"slug":103,"title":104,"created_at":105},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":107,"slug":108,"title":109,"created_at":110},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":112,"slug":113,"title":114,"created_at":115},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":117,"slug":118,"title":119,"created_at":120},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":122,"slug":123,"title":124,"created_at":125},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]