标签：#mac

This is the project my last two posts were building towards (this is the last of this silliness). I ported the Doom rendering algorithm to run inside a transformer. Instead of training a model, I used a compiler I wrote which converts computation graphs into transformer weights, and then ported Doom's algorithm into a compatible graph. The generated checkpoints can be loaded in Hugging Face without trust_remote_code -- it's just a standard transformers checkpoint. You feed the model a prompt representing the scene data, and generate until the model stops. The result is a token sequence which includes simple pixel drawing commands (to move the cursor, draw a pixel, etc). When you mechanically apply those drawing commands you get the rendered frame. The article includes the entire host program necessary to load the checkpoint, generate the render, and parse the output into the famous E1M1 frame. This host code is 43 lines of python. The python to define the computation graph is much longer, but that gets compiled into the transformer itself. One frame is a 3,614-token prompt plus 53,747 generated tokens -- just over 40 minutes on a B200. The original Doom could achieve 35 FPS on a 486. This achieves 35 FPD (frames per day) on a B200. Write-up: https://ood.dev/posts/doom/ Weights: https://huggingface.co/physicsrob/torchwright-doom-e1m1 Github for the source code which gets compiled: https://github.com/physicsrob/torchwright_doom/ submitted by /u/notforrob [link] [留言]

Implied vs Realized Volatility: Reading the Gap By Shakti Tiwari · Educational only · Not investment advice This article explains implied vs realized volatility: reading the gap from first principles. No live market numbers are quoted; the structure is what lasts. Why this matters Implied vs Realized Volatility: Reading the Gap is one of those subjects that sounds simple until you implement it, at which point the hidden complexity appears. The first version works on a laptop with a tiny file; the second version breaks at 3am when the WebSocket drops, the replay file is half-written, and you cannot tell which ticks you already stored. This article is a structural walkthrough: the concepts, the math where it helps, the code shape where it helps, and the failure modes that quietly cost money or correctness. No live market numbers are quoted because a number without a dated source is decoration, not education. The structure here does not expire, and unlike a specific price level, you can reuse it on the next dataset without re-deriving anything. If you only remember one sentence from this page, make it this: the boring parts are the product, and the interesting parts are a small fraction of what separates a demo from a system. Core concept At its heart, implied vs realized volatility: reading the gap is about being honest with your own assumptions. The trap is not that the idea is wrong; it is that a half-implemented version looks right in a demo and breaks in production. We separate the idea from the implementation so you can tell which one you actually have. A clean concept on paper can still produce a broken system if the boundary between 'what I meant' and 'what the code does' is never made explicit. Write the concept as a contract: given X observable at time t, the system produces Y, and any deviation is a bug, not a feature. A contract you can state in one sentence is also one you can test in one assertion, and that testability is the entire difference between an

Been working on this for the last few months. I've been working on PyTorch for the past few years and I always felt, many a times my work went into dump, because of some mistakes I made in the code. torch-preflight reads your PyTorch code and catches the bugs costing you GPU hours. Things like losses.append(loss), which holds the autograd graph from every step until CUDA dies on you or no zero_grad() in the loop or gradient accumulation without dividing the loss or DDP with no DistributedSampler, so every rank trains on the same batches. I've been able to get 13 rules so far. Your code never gets imported or executed, so you need no GPU and no torch install. There's another part to this that estimates VRAM. Point the tool at a training script and a GPU, and you learn whether the run fits before you pay for the instance. You also get the list of changes to make the run fit, with the GiB each one saves. pip install torch-preflight https://github.com/highwaterlabs/torch-preflight https://pypi.org/project/torch-preflight/ Please try this out, and I would like to get your feedback! It's still a work in progeress. Would like to know what breaks on your code. False positives kill a linter, and my only large test target so far has been the PyTorch source tree. Same for the memory numbers. Mine land within 4% of measured peaks, but from four models on one T4. PS: open to contributions, and issues are already open on the repo. Soon I'm going to add a few "Good first issues" as well. Feel free to ping me if you have any questions! submitted by /u/LeJanbandhu [link] [留言]

Hello, I was curious about the differences you can get from the human reviewers and the llms. Any insight is welcome, thank you! submitted by /u/obliviousphoenix2003 [link] [留言]

i wanna build a text diffusion model which interpret text and convert it into ascii images so like Text : build a cat Output : /\\\_/\\ ( o.o ) \> \^ < So , i have a decent background of ml algo ( completed cs229 , cs230 , Ml architecture and basic CNN and diffusion model ) ik making a project like this is tricky and making diffusion model like that from scratch is hard but i wanna try it because that's wot make me excited lol ... I am currently reading GANs research paper , can u guys help me in finding more papers which helps me in making this project or guide me through this good title for this Thx in adv submitted by /u/Udbhav96 [link] [留言]

A hands-on test of BGE-M3 + Qwen3 (RAG vs. direct-context answering) on a real research paper and a full-length book including a retrieval bug hiding in a footnote, and one surprisingly good model behavior. I wanted to answer a simple question: when you feed a document to an AI model, is it actually reading it or just pattern-matching to whatever text happens to look similar to your question? So I built a small open-source pipeline to test this directly. For any document and question, it generates two separate answers: RAG answer: BGE-M3 finds the most relevant chunks of the document, and Qwen3 answers using only those chunks. Direct answer: Qwen3 reads the raw document text directly, no retrieval involved. Both run on a free Google Colab GPU. I kept the retrieval side deliberately "vanilla" fixed-size chunking, plain cosine similarity, no reranking, no fancy tricks so I could see exactly where the basic version breaks before adding any fixes. Before running my first real test, I already knew one thing to guard against: reference lists. Early experimentation (not covered here) showed that a paper's bibliography, once chunked like any other text, can get retrieved as if it were real content a citation for a paper about "text embeddings" can look deceptively similar to a generic question about a document's topic. So going in, my pipeline already strips everything after a References/Bibliography heading before chunking. With that fix in place, I ran two real tests. Test 1: A research paper on Nepali legal machine translation First document: a SIGUL 2024 workshop paper on a bidirectional English-Nepali machine translation system for the legal domain. Question: "What is this paper about?" RAG answer: This paper presents the first transformer-based bidirectional machine translation system for the English-Nepali legal domain, using a custom-built parallel corpus of 125,000 sentences. It achieves encouraging BLEU scores and addresses the scarcity of domain-specific legal tr

Originally published on tamiz.pro . The AI agent is no longer a chatbot that reads and writes. It connects to APIs, executes code, accesses databases, and makes decisions on behalf of users. That capability is also its vulnerability surface—and attackers are already weaponizing it. Prompt injection, tool-use exploitation, and supply-chain poisoning are no longer theoretical risks. They are happening in production today. This article doesn't rehash the high-level warnings. It draws concrete architectural lessons from GitHub's most popular open-source security and gateway repositories—tools like NVIDIA NeMo Guardrails , LangChain's security contributions , Guardrails AI , Ollama's gateway patterns , and Microsoft's guidance on LLM security —and translates them into a practical blueprint for building AI agents that survive deliberate adversarial attacks. The central thesis: prompt injection is not a prompt-engineering problem. It is an input-validation and system-architecture problem. The fixes are structural, not rhetorical. Table of Contents 1. The Threat Model: Why AI Agents Are Fundamentally Different 2. The Layered Defense Architecture 3. Guardrails: Input Validation That Actually Works 4. Tool-Use Hardening: The Hidden Attack Surface 5. Gateway Patterns: Routing, Rate-Limiting, and Sandboxing 6. Supply-Chain and Model-Level Threats 7. Observability and Incident Response 8. A Minimal Production-Ready Agent Skeleton 9. When Your Defenses Fail Frequently Asked Questions 1. The Threat Model: Why AI Agents Are Fundamentally Different Traditional software attacks target inputs at the network boundary. AI agents change the boundary. The user's prompt is no longer just data—it is often executable context . When an agent interprets a prompt as instructions, the prompt becomes a vector for command injection, data exfiltration, and privilege escalation. Consider the attack surface: Direct prompt injection : The user provides a malicious prompt like "Ignore previous instruct

I recently had a paper accepted to TMLR and was wondering how prestigious it is, in comparison to A* conferences (ie. NeurIPS, ICLR, ICML), but also vs journals like JMLR. submitted by /u/Awesome_Nerd10 [link] [留言]

A field report on serving Google's Gemma 4 E2B on AWS EC2 **G5g * — a Graviton2 (aarch64) host with an NVIDIA T4G (Turing, SM 7.5) GPU. Three obstacles: an arch list nobody publishes for this combination, a version floor that only the newest vLLM clears, and 64 KiB of shared memory that stops the model dead. Plus the seven things I documented wrong before I had a box.* Model google/gemma-4-E2B-it (reference bf16 release) Hardware AWS EC2 g5g.4xlarge — Graviton2 + 1x NVIDIA T4G, compute capability 7.5 , 15,360 MiB Base image Deep Learning ARM64 AMI OSS Nvidia Driver GPU PyTorch 2.12 (Ubuntu 24.04) Software torch 2.12.0+cu132 · CUDA 13.2 · vLLM v0.27.2rc0 built from source for sm_75 Result 43.1 tok/s single-stream greedy, 329,579-token KV cache — after one patch to vLLM G5g is the only instance AWS has ever shipped that puts an NVIDIA GPU behind a Graviton host. It launched in 2020, it never got a successor, and Graviton is now on its fifth generation without one. That matters more than it sounds. The Arm-plus-CUDA world moved on to NVIDIA's own Arm CPU — Grace, paired with SM 9.0 and 10.0 parts. Turing stayed well supported, on x86. G5g is the only hardware that is aarch64 and compute capability 7.5, and almost nobody publishes a build for that combination. I put a rig on one anyway. The packaging problem was the quick part. Everything after it — a compiler that was not there, a version floor I did not expect, and 32 KiB of shared memory — took far longer, because none of it fails where you are looking. No published build covers aarch64 and SM 7.5 together Start with the obvious candidate. vllm/vllm-openai:v0.27.1 publishes both platforms under one tag, and you can read the arch lists straight out of the image config without pulling a layer: docker buildx imagetools inspect vllm/vllm-openai:v0.27.1 --format '{{json .Image}}' linux/amd64 7.5 8.0 8.6 8.9 9.0 10.0 12.0 linux/arm64 8.0 8.7 8.9 9.0 10.0 11.0 12.0 The one architecture this hardware needs is the only entry

A field report on serving Google's Gemma 4 E2B on AWS EC2 **G5g * — a Graviton2 (aarch64) host with an NVIDIA T4G (Turing, SM 7.5) GPU. Three obstacles: an arch list nobody publishes for this combination, a version floor that only the newest vLLM clears, and 64 KiB of shared memory that stops the model dead. Plus the seven things I documented wrong before I had a box.* Model google/gemma-4-E2B-it (reference bf16 release) Hardware AWS EC2 g5g.4xlarge — Graviton2 + 1x NVIDIA T4G, compute capability 7.5 , 15,360 MiB Base image Deep Learning ARM64 AMI OSS Nvidia Driver GPU PyTorch 2.12 (Ubuntu 24.04) Software torch 2.12.0+cu132 · CUDA 13.2 · vLLM v0.27.2rc0 built from source for sm_75 Result 43.1 tok/s single-stream greedy, 329,579-token KV cache — after one patch to vLLM G5g is the only instance AWS has ever shipped that puts an NVIDIA GPU behind a Graviton host. It launched in 2020, it never got a successor, and Graviton is now on its fifth generation without one. That matters more than it sounds. The Arm-plus-CUDA world moved on to NVIDIA's own Arm CPU — Grace, paired with SM 9.0 and 10.0 parts. Turing stayed well supported, on x86. G5g is the only hardware that is aarch64 and compute capability 7.5, and almost nobody publishes a build for that combination. I put a rig on one anyway. The packaging problem was the quick part. Everything after it — a compiler that was not there, a version floor I did not expect, and 32 KiB of shared memory — took far longer, because none of it fails where you are looking. No published build covers aarch64 and SM 7.5 together Start with the obvious candidate. vllm/vllm-openai:v0.27.1 publishes both platforms under one tag, and you can read the arch lists straight out of the image config without pulling a layer: docker buildx imagetools inspect vllm/vllm-openai:v0.27.1 --format '{{json .Image}}' linux/amd64 7.5 8.0 8.6 8.9 9.0 10.0 12.0 linux/arm64 8.0 8.7 8.9 9.0 10.0 11.0 12.0 The one architecture this hardware needs is the only entry

City2Graph is a Python library I built that turns geospatial data into analysis-ready graphs (for spatial analysis, network analysis, and Graph Neural Networks as GeoAI), and the paper describing it has just been published, so I wanted to share it here. Repository: https://github.com/c2g-dev/city2graph import city2graph as c2g # buildings + street segments -> heterogeneous morphological graph nodes, edges = c2g.morphological_graph(buildings, segments) # straight into PyTorch Geometric data = c2g.gdf_to_pyg(nodes, edges) What it covers: Morphology : graphs of buildings, streets, and tessellated urban fabric from OpenStreetMap and Overture Maps Transportation : GTFS and GBFS feeds loaded through DuckDB, with GTFS aggregated into stop-to-stop transit graphs Mobility : OD matrices and flow data (migration, bike-sharing, pedestrian counts) as weighted spatial graphs Proximity and contiguity : KNN, Delaunay, Gilbert, Waxman, plus queen/rook contiguity, under Euclidean, Manhattan, or network distances Heterogeneous graphs and metapaths : several node and edge types in one graph, with metapath-derived edges composing relations across them Conversion : round trips between GeoDataFrames, NetworkX, rustworkx, and PyTorch Geometric Data / HeteroData , with geometries and attributes kept intact It sets out why urban data is better treated as heterogeneous graphs than as flat feature tables, how the morphological, transport, mobility, and proximity constructions relate to each other, and how the library keeps geometry and graph structure consistent across conversions. If you use the library in research, that is the citation. Paper Sato, Y., Pietrostefani, E., Mahabir, R., & Arribas-Bel, D. (2026). City2Graph: A Python library for Heterogeneous Graph Neural Networks and spatial analysis in urban systems . Computers, Environment and Urban Systems , 130, 102492. Happy to answer questions about the design, and issues or PRs are very welcome. I am especially keen to hear which data so

About QQ studio QQ studio is a Czech production and postproduction company engaged in filmmaking and European television projects. For their visual effects (VFX) artists, editors, and sound designers, high data throughput and system reliability are critical. Data bottlenecks and hardware crashes risk missed client deadlines, broken delivery promises, and interrupted creative flow. The Breaking Point In mid-2024, QQ studio’s production pipeline hit a wall. Over 40 TB of active project data lived on an aging QNAP NAS. External access via FTP failed, forcing reliance on expensive third-party file transfer services like Frame.io. Meanwhile, project management relied on Kitsu, the studio’s central tool for tracking VFX shot status, coordinating task assignments, and reviewing preview renders across creators. For most modern companies, the automatic answer to a failing local server is simply: Move everything to the cloud. However, given QQ studio’s hybrid setup where editors, VFX artists, and render nodes work directly on local workstations, relying on remote storage isn’t practical. The studio works with massive, uncompressed video files where even a 2.5Gbps local network can sometimes feel slow. Pulling terabytes of raw footage down from the internet daily would cripple their creative workflow, and paying for 40+ TB of active, high-speed cloud storage would burn through project budgets entirely. They needed the massive speed of a local network, but with enterprise-grade reliability. Meanwhile, daily backups were manual and fragile, relying entirely on hope that systems wouldn't crash. With growing project scopes, a team scaling over 40 creators, and strict commitments to major partners, studio leadership knew their old infrastructure had reached its limits. They brought me in to work alongside their team and replace the fragile setup with a stable, secure foundation. Deploying the Industry Standard Rather than forcing a proprietary, unproven setup from scratch, I worked

Almost every graph starts life as relational tables. The conversion is mechanical once three decisions are made, and one of the three — id remapping — is a silent correctness bug rather than a matter of taste. Deciding what is a node Start with three tables: customers (customer_id, region, signup_date, tenure_days), products (product_id, category, price), and orders (order_id, customer_id, product_id, amount, ordered_at). The rule that resolves nearly every case: A table with a primary key that other tables point at is a node type. A table whose whole job is to link two keys is an edge type. So customers and products are nodes, and orders are edges — even though orders has its own primary key. The order id is not an entity you want to reason about; it is an identifier for a relationship. The harder case is a repeated categorical column such as region . It can stay a customer feature, or it can become a node type with a customer–region edge. The test is behavioural, not aesthetic: do you want information to flow between rows that share this value? As a feature, region is a tag on each customer and nothing more. As a node, it creates a two-hop path between every pair of customers in the same region, so their representations start blending. If a region contains 400,000 customers, that node is a hub through which everything mixes, which is usually a way of turning four hundred thousand distinct customers into one regional average. Keep high-cardinality-of-membership categoricals as features; promote a category to a node when its membership is small and meaningful. If you end up with more than one node type, the model has to change too — see heterogeneous graph neural networks . The id remapping nobody warns you about Graph libraries do not store your ids. They store a node feature matrix and an edge index of integer positions into it, because a message-passing layer is a gather over rows of a dense array. So node ids must be contiguous integers from 0 to n−1 , per node

You put “use British English spelling” in the system prompt. The first three paragraphs are fine. By paragraph nine there is a color , and by the end there is an organization . The instruction was not ignored; it was outvoted. The symptom The characteristic pattern is not uniform failure. It is a document that starts correct and degrades — and the degradation is usually inconsistent within the document, so you get colour in one paragraph and color two paragraphs later, sometimes in the same sentence as behaviour . Long outputs are worse than short ones, and a long conversation is worse than a single call. A second symptom is domain-specific: the spelling holds in ordinary prose and fails in technical contexts. Code comments, API field names, CSS properties and library names are American by convention ( color is a CSS property; serialize is what the method is called), and text near them pulls the surrounding prose across. Both patterns point at the same cause, and it is not that the model did not read the instruction. Why it drifts back Each token is sampled from a distribution conditioned on everything in the context. The system prompt is part of that context, but so are the two thousand tokens the model has generated since, and so is the enormous prior from training data in which American spelling outnumbers British by a wide margin in almost every technical domain. At the start of a response the instruction is close by and there is little else in the context, so it dominates. As the response grows, the local statistics of the text being generated carry more weight relative to a single instruction several thousand tokens back. And the drift is self-reinforcing in exactly the way described in mid-answer code-switching : once one American spelling is in the context, the conditional probability of the next one rises. The key insight for fixing it is that spelling is not a mode the model is in. There is no British-English state that gets set and then holds. Each word i

Brazil’s AI bill is described in a great deal of writing as though it were in force. It is not, and the distinction is not pedantic: the risk tiers, the prohibitions and the regulator that summaries attribute to Brazilian law exist only in a text that one chamber of Congress has approved. Where the bill stands PL 2338/2023 was introduced in the Federal Senate in May 2023 by the then-President of the Senate, building on the report of a commission of jurists that had been convened to draft a substitute for earlier and much thinner AI bills. After committee work through 2024, the Senate plenary approved the bill on 10 December 2024 and sent it to the Chamber of Deputies, where it has been examined by a special committee rather than passed straight to a floor vote. As at the date on this page, the bill has not been enacted. It has been approved by one chamber and remains before the other. This is a status page about a live legislative process and it is written to be checked, not relied on. It is not legal advice. Before making any decision that depends on whether Brazil has an AI statute, verify the current stage on the official tracking pages linked below—a page written at any date can be overtaken the following week. How a Brazilian bill becomes law The reason “approved by the Senate” is so frequently misreported as “passed” is that the remaining route is substantial and can change the text materially. A bill originating in the Senate goes to the Chamber of Deputies as the revising chamber. If the Chamber amends it, the amended text returns to the Senate, which decides between its own text and the Chamber’s. Only when both chambers have settled on one text does it go to the President, who may sanction it in whole, or veto provisions in part, with vetoes subject to being overridden by Congress. Each of those stages has changed the substance of comparable Brazilian technology legislation. The LGPD itself, Brazil’s data protection statute, was enacted in 2018 and then am

The instinct is to hand the whole reference list to a model and ask for an array of citation objects. On a list of eighty entries that produces seventy-three, with two merged and five hallucinated into tidiness. The fix is to make segmentation a separate, deterministic step. Two stages, and why the first one is harder Parsing one reference string into author, year, title and venue is a task current models do well. Deciding where one reference ends and the next begins is a task they do badly, because the boundary is typographic rather than semantic: a hanging indent, a numeric label, a line break that is either a wrap or a separator depending on the column width. Splitting the work also gives you a count to assert against. If the list is numbered 1 to 84 and you segmented 81 entries, you know the parse is wrong before you have looked at a single field. A single-call extraction gives you no such handle — a merged pair looks identical to a list that was three shorter. Step 1: segment the list Three reference-list styles cover almost everything, and each has a different boundary signal: Numbered (Vancouver, IEEE). Each entry begins with 1. or [1] . Boundary detection is a regex, the sequence is monotonic, and you get the assertion for free. Author-date (APA, Harvard, Chicago author-date). No labels. Entries are separated by a hanging indent — the first line starts at the margin and continuations are indented — which is invisible in a flat text stream and obvious in the layout. Note-bibliography (Chicago notes). Also unlabelled, also hanging-indented, and additionally uses a three-em dash for a repeated first author, which is the case discussed below. For the unlabelled styles, segment on the indent rather than on the text. If you have coordinates from the PDF, an entry starts at every line whose left edge is at the block minimum and continues through every line indented further. If you do not have coordinates, a reasonable proxy is a line that begins with a capital lett

If your Azure Pipelines eval gate runs on pushes to main but never on a pull request, the YAML is not the problem. Microsoft’s documentation is explicit: for an Azure Repos Git repository you cannot configure a PR trigger in the YAML file, and the functionality is implemented by a branch policy instead. Why your pr trigger does nothing The pr: key exists in the Azure Pipelines YAML schema, and it works — for GitHub and Bitbucket Cloud repositories. For Azure Repos Git it is inert. The Azure Repos Git documentation states that pull request triggers are implemented using branch policies, and that to enable PR validation you configure the Build validation policy on the target branch. A pr: block in the file is not an error and produces no warning; it simply never causes a run. Two related things surprise people once the policy exists. Draft pull requests do not trigger a pipeline even with a branch policy configured, so a gate that seems not to run may be running against a draft. And you must be a project administrator of the project to configure validation builds at all, which is why this is often the step that a developer cannot complete themselves. This is a product behaviour rather than a version detail, but it is the kind of thing that changes. Check the Azure Repos Git page in Microsoft’s Azure Pipelines documentation before assuming it still holds. The pipeline A single-stage pipeline is enough. The CI trigger below covers pushes; the pull request path comes from the policy in the next section, and no pr: key appears at all because on Azure Repos it would only be misleading to a reader. trigger : branches : include : - main paths : exclude : - docs/* pool : vmImage : ubuntu-latest variables : - group : llm-eval-keys - name : EVAL_MODEL value : gpt-4.1-mini-2025-04-14 steps : - task : UsePythonVersion@0 inputs : versionSpec : ' 3.12' - script : pip install -r evals/requirements.txt displayName : Install eval dependencies - script : | python -m evals.run \ --cases

HTTP 429 from Azure OpenAI is four different problems sharing one status code. Three of them are fixed by backing off and one is not, and the response headers distinguish them in about a line of code. Most teams skip that line and file a quota increase for a condition that would have cleared on its own. The error The SDK surfaces it as a rate-limit error — openai.RateLimitError in Python, a RequestFailedException with Status == 429 in .NET. The message text is the first discriminator, and Microsoft documents the indicator phrases rather than a single fixed string: "Requests to … have been limited" or "Rate limit is exceeded" "The service is temporarily unable to process your request" or "System is experiencing high demand" Those two groups mean opposite things. The first is your allocation; the second is Azure’s capacity. Log the message body on every 429 — without it you are guessing. Microsoft, Manage Azure OpenAI quota . Four causes wearing one status code Rate limit exceeded. Your traffic genuinely passed the deployment’s TPM or RPM allocation. Remedy: raise the deployment’s TPM, rebalance quota from an underused deployment, or request an increase. System capacity throttling. Backend capacity is constrained. Documented as often transient. Remedy: retry after the delay the service gives you. A quota increase does nothing here. Temporary rate limit adjustment. The one worth knowing about. Standard and Global Standard deployments share a resource pool across customers, and Microsoft documents that when demand approaches capacity limits the system may temporarily reduce your deployment’s effective rate limit to keep the pool reliable. Your configured quota has not changed. The adjustment typically resolves within a few hours. Token budget consumed by parameters. The rate-limit calculation includes max_tokens and the prompt estimate, not the tokens actually generated. A request with a large max_tokens spends that budget whether or not it uses it. Two more mechanics e

The substitution is three lines of client code. The part that costs an afternoon is that the most powerful-looking Azure OpenAI role is explicitly unable to make an inference call. What a key cannot do An Azure OpenAI resource key is a bearer secret with no identity, no expiry and no scope narrower than the whole resource. Every deployment on the resource is reachable with it, every caller looks identical in the audit trail, and rotating it means coordinating every consumer at once. A managed identity replaces it with a short-lived Microsoft Entra ID token issued to a specific workload identity. The credential is never stored, the token expires on its own, and the grant is a role assignment you can scope to a resource group, a resource, or nothing at all. Combined with a private endpoint, it removes the two things an attacker needs — the network path and the static secret. The role that permits inference Microsoft documents four roles for Azure OpenAI, and the summary table on its RBAC article makes one distinction that is worth reading twice: Cognitive Services OpenAI User — can make inference API calls with Microsoft Entra ID. Cannot read or regenerate keys, cannot create deployments, cannot create guardrails. Cognitive Services OpenAI Contributor — everything the User role has, plus creating and editing deployments, fine-tuning and stored completions. Cognitive Services Contributor — can create resources, read and regenerate keys, and create customised guardrails, but is listed as unable to make inference API calls with Microsoft Entra ID . Cognitive Services Usages Reader — quota visibility only, and only at subscription scope. That third entry is the trap. Granting an application the Contributor role because it sounds broader produces an application that can rotate the keys it is no longer using and cannot call the model at all. The role you want for a workload is Cognitive Services OpenAI User , and nothing else. Microsoft also notes that subscription-level Ow

Global Standard is the default for a reason and the reason is not performance. It is a routing behaviour with quota consequences, and both halves surprise people who chose it because it was preselected. What the type does The SKU name in code is GlobalStandard . Microsoft describes it as using Azure’s global infrastructure to dynamically route traffic to available datacenters, and lists three concrete consequences: it provides the highest default quota , it eliminates the need to load balance across multiple resources for throughput purposes, and it is the type new models arrive on first. The launch order is documented and it is a planning input. New deployment types become available Global first, then Data Zone, then single region — and single-region types arrive last, have no guaranteed availability date , and depend on capacity that frees up as older models retire. A design that requires a model pinned to one region is a design that may wait indefinitely for that model. Microsoft, Understanding deployment types in Foundry Models . Global Standard also supports priority processing on a pay-as-you-go basis, which is a separate rate for faster responses on the same deployment. Routing and data residency The distinction Microsoft draws is between data at rest and data in flight, and only the second one varies by deployment type. Data stored at rest remains in the designated Azure geography for every type. Inferencing data is processed differently: Global types: may be processed in any Azure region . Data Zone types: processed only within the Microsoft-specified data zone — US, EU or Asia Pacific. The EU zone follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland in addition to member states. Standard (single region): processed in the deployment region. “Any Azure region” is the phrase to take to a compliance conversation before you deploy rather than after. Microsoft also notes it can add regions to a data zone without pri