Supermicro HGX B200, 8 GPUs
10U air-cooled · 8 × NVIDIA B200 180 GB · 2 × AMD EPYC 9575F · 2,304 GB DDR5 · 8 × 400G ConnectX-7 · 3-year warranty
We take on engineering work that has stalled, or that no single vendor is accountable for.
One team of senior engineers is accountable for the result in the scope you engage, and examines the layer above it and the layer below it. Every engagement starts with a fixed-fee assessment, and you can stop after it.
Our work is to take a proof of concept into production, and to show you in writing what is inside it
Many businesses are testing new technology, and most of that testing is in AI. A proof of concept, or a pilot, shows that the technology can do the job on a chosen sample. It has not yet been asked what production will ask.
Production asks whether the system is right on your real data, whether it holds at peak load and at what cost, who and what can reach it, what you can show an auditor, how it fails, and who owns it and runs it. In our view it is uncommon for one implementation partner to be set up to take a proof of concept through all of those and to put each answer in writing. Our engineers assemble and test the system themselves, component by component, so this last part of the work is the part we take on.
The drawing shows the six questions that stand between a proof of concept and a system in production.
A test against agreed targets
The proof of concept is measured for accuracy on cases drawn from your own work, and for response time and cost at the concurrency you expect at peak, against targets agreed before the test starts.
Each component described in writing
Before a component in the agreed scope carries production traffic, you are told in writing what it does, what it depends on, the ways we have found that it can fail, and which of those we tested.
The engineers who test it build it
If you ask us to do the build, the engineers who ran the test do it and hand the system to your team. If the lead has to change, you are told first. A support period follows the handover.
We do not audit or certify the systems we build, and we do not issue security or compliance certificates. The documents are written for your own security team and your auditors to examine.
How an engagement runs
There are four steps, and each is set out in full under Working with us.
Describe
You describe what you are trying to do and what has stopped it. An engineer replies with questions, a proposed call, or a statement that the work is outside what we do.
Assess
The assessment has a fixed fee and a fixed length. It runs under an NDA, reads your systems with read-only access that you grant, and ends with written findings that are yours. You can stop there.
Build
The build is set out in milestones, and each milestone has acceptance tests agreed in writing before work on it starts. It is done in your accounts and repositories by engineers engaged directly by Udhyam.
Hand over
Your engineers run the system, a release and a rollback, which is a return to the previous version, themselves while ours observe. A support period follows, and continued engineering is available on a retainer if you want it.
The five practices
You can engage one practice on its own. A layer is one level of the system, from the hardware up to the application. Whichever practice you engage, we also examine the layer above it and the layer below it, and we report what we find there.
Moving production from one cloud provider to another
Virtual machines and containers usually move with little change. Sign-in and permissions, network design, the provider's own database services, and the operating procedures written around one provider's behaviour have to be rebuilt. We move the estate, meaning everything you run on the provider, in waves. Each wave is a group of services small enough to be moved back within one maintenance window, and the wave plan states the point after which a service can no longer be moved back.
What the work is planned to deliver
- The estate running on the target provider, with every wave verified
- Infrastructure code for each environment covered, in your repository
- The source estate decommissioned, with a reconciled final bill
The drawing shows a move part way through: ten services verified on the new provider, two running on both, and eight still to move.
Rebuilding a system that has outgrown its original design
A system that was built correctly for one set of assumptions can stop coping when those assumptions change. We replace the parts that have to change, with the system designed to stay in service throughout. Traffic moves to a new path only after that path has matched the old one on the same live requests, within a tolerance agreed with you.
What the work is planned to deliver
- New components carrying production traffic
- Data migrated and verified as part of the project
- The old path retired, once the new path has met the retirement test agreed in advance
The drawing shows requests divided between the old system and its replacements, with both answers compared before more traffic moves.
Making a release safe enough to do on any working day
A release pipeline, the automated path from a code change to production, can have every stage and still leave the team unwilling to release without a manual check, because no stage measures whether the release is safe. We build test environments from the same code and configuration as production, release gates that a new version must pass before more users receive it, and a rollback, which is a return to the previous version, that is rehearsed and timed.
What the work is planned to deliver
- Infrastructure defined as code in each environment covered
- Gradual release gated on error rate, response time and a business signal you choose
- A rollback rehearsed in production, with its restore time recorded
The drawing follows one change from commit to release. It is held at five percent of traffic until its signals have been judged.
Taking an AI pilot into daily use
A model that answers well in a demonstration has not yet been asked to serve every user at once. Doing that at a response time, and at a cost for each request, that the business can accept is a separate engineering problem, and it is the one we work on.
What the work is planned to deliver
- The service in production, available to the people it was built for
- Evaluation cases drawn from your own work, which show whether its answers are right
- A measured cost, in your currency, for each type of request
The drawing follows one request through the system and shows where the waiting time and the cost arise.
Sizing a GPU purchase, or checking a quotation before you sign it
We size from the work you intend to run, and not from a catalogue of parts. A GPU server, the kind of machine that runs AI models, has several limits: how fast it calculates, how fast it moves data through its memory, and how much memory it holds. We test which limit your work reaches first and specify the servers for that limit. No supplier pays us, so the recommendation can be to buy what was quoted, to buy less or more, to buy a different part, or to rent first.
What the work is planned to deliver
- A written recommendation, with the arithmetic shown in your currency
- The cost of owning the servers, in your own facility or colocated in another firm's data centre, and of renting, compared on one basis in your currency
- A specification for the servers and their network, where you ask for one, with the power and cooling the data centre must supply
The chart shows what renting, colocating and buying cost at different levels of use. The three bars show which limit of the hardware the work reaches first.
Swipe sideways for the other four practices.
Where each practice works in the stack
No practice is confined to one layer. Each layer is either worked on or examined by at least two practices, so the five are run by one team that can see all of them.
One team accountable for every layer in scope
When each layer is contracted to a different vendor, a fault that spans two layers can be left without an owner. A slow response after a migration, for example, can sit across the network path, the way the application holds its database connections, and a difference between two database engines, and each vendor can show that its own layer is within specification.
We are accountable for the result in the scope you engage. We also examine the layer above and the layer below, report what we find there, and work alongside your own team and your existing suppliers.
How we engineerWe measure before we design
Where a system is running, we measure where its time and memory go before proposing a design. Where nothing is running yet, we measure a representative workload on capacity rented in an account you control. Where there is nothing to run, we work from stated inputs and say how uncertain the result is.
Two engineers on every engagement
The engineer who scopes the work leads it. A second engineer follows the engagement from the first day and can take it over. If the lead has to change, you are told first.
Each design decision is recorded with its measurements
The volume of work handled, the response time and the cost are recorded for each design decision that affects them, and are handed over with the system.
Working assets that belong to you
The assessment ends with written findings and a short paper for your management. A build is planned to end with the working system and the measurements behind it, and advisory work with the sizing model. From the first day of the build everything is saved in your own code repositories, and it is yours.
- A management paper from the assessment: what we found, what we recommend, an estimate of what it would cost and what could go wrong
- Infrastructure code for each environment covered
- Evaluation cases built from your own data
- Release gates tied to measured signals
- A cost model with every assumption visible
The three files shown here are examples, for your engineers, of what is stored in your repository.
# One wave of a cutover, for stateless services. Each name has a source
# record and a target record, and DNS answers divide in proportion to their
# weights. A target weight of zero stops new resolutions reaching the target.
# Cached answers and open connections drain over the TTL and the connection
# lifetime. Stateful services follow a separate replication plan.
variable "wave" {
type = object({
name = string
services = set(string)
target_weight = number # 0 to 100
})
validation {
condition = var.wave.target_weight >= 0 && var.wave.target_weight <= 100
error_message = "The target weight must be between 0 and 100."
}
}
resource "aws_route53_record" "target" {
for_each = var.wave.services
zone_id = var.zone_id
name = "${each.key}.${var.domain}"
type = "CNAME"
ttl = 60
set_identifier = "target"
records = [local.target_endpoint[each.key]]
weighted_routing_policy {
weight = var.wave.target_weight
}
}
resource "aws_route53_record" "source" {
for_each = var.wave.services
zone_id = var.zone_id
name = "${each.key}.${var.domain}"
type = "CNAME"
ttl = 60
set_identifier = "source"
records = [local.source_endpoint[each.key]]
weighted_routing_policy {
weight = 100 - var.wave.target_weight
}
}# The same cases for every candidate model, replayed at your peak arrival rate.
def evaluate(model: Endpoint, cases: list[Case], requests_per_s: float) -> Result:
runs = replay(model, cases, rate=requests_per_s) # open loop, so queueing shows
ok = [r for r in runs if r.ok]
# A failed run scores zero and counts as a full timeout, so failing is never free.
ttft = [r.ttft_ms if r.ok else TIMEOUT_MS for r in runs]
# decode_s runs from the first token to the last, so it covers n - 1 tokens.
rates = [(r.output_tokens - 1) / r.decode_s for r in ok if r.output_tokens > 1]
return Result(
model=model.name,
accuracy=mean(r.case.grade(r.text) if r.ok else 0.0 for r in runs),
failed_share=1 - len(ok) / len(runs),
first_token_ms_p95=percentile(ttft, 95),
tokens_per_s_p50=percentile(rates, 50),
tokens_per_s_p05=percentile(rates, 5), # the slowest requests
# capacity cost at the utilisation you expect over a day, or the supplier's
# input and output prices at the measured mix where the model is an API
cost_per_m_tokens=model.cost_per_m_tokens(ok, utilisation=EXPECTED),
)# The canary advances when its signals have been judged against the stable
# version. Signals that arrive late are checked during a hold at 25 percent.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
rollbackWindow:
revisions: 1 # re-applying the previous revision skips the steps
strategy:
canary:
canaryService: app-canary
stableService: app-stable
trafficRouting:
plugins:
argoproj-labs/gatewayAPI:
httpRoute: app # the Gateway API route that carries the split
steps:
- setWeight: 5
- analysis: &gate # compares canary pods with stable pods
templates:
- templateName: error-rate-p99-and-approval-rate
args:
- name: canary-hash
valueFrom: { podTemplateHashValue: Latest }
- name: stable-hash
valueFrom: { podTemplateHashValue: Stable }
- setWeight: 25
- analysis: *gate
- pause: { duration: 30m } # the hold for signals that arrive late
- analysis: { templates: [{ templateName: reconciliation-breaks }] }
- setWeight: 100
scaleDownDelaySeconds: 600 # previous version stays up for ten minutesNotes from the engineering work
Each article sets out one problem, the mechanism behind it and what we would check first.
Where the work is done from
The firm is based in Delhi and the engineering is led from India. Our engineers work from India and from other countries, and each engineer's profile states the country that engineer works from.
For organisations in India
If your data must stay in India, or the system must run on an Indian sovereign cloud or a private cloud, we design for that from the first conversation. We work inside your own accounts under named identities that you issue and can revoke. Tell us if your rules require the engineers to be in India, and the proposal will name engineers who are.
For organisations elsewhere
The terms are the same as for an organisation in India. We work inside your own accounts under named identities that you issue and can revoke. Tell us what your vendor onboarding requires, and we will answer it in writing.
Across time zones
We work in writing by default, so progress can be followed without a call. Each decision is recorded in your repository when it is made, and each switch from the old system to the new one is staffed live inside your maintenance window.
Describe the problem, and an engineer will reply within one working day
Tell us in general terms what you are trying to do and what has stopped it. If it is not ours to take on, we will say so.