Giters

ravenscroftj / turbopilot

Turbopilot is an open source large-language-model based code completion engine that runs locally on CPU

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Only huggingface client works, and crashes server

aperullo opened this issue · comments

commented

Awesome project!

I wanted to know which client is supported and which you personally use because of the 3 I could find references to, only the hugging face one seems to work.

My server version is master, built locally via the Dockerfile.cuda11 file.

Fauxpilot

settings.json

    "fauxpilot.server": "http://localhost:18080/v1/engines",
    "fauxpilot.enabled": true,

This results in the error described here of Error: Illegal argument: line must be non-negative.

official copilot plugin

Results in the behavior here of completions not showing up.

Huggingface plugin

Does work, however if you type too quickly, the server gets multiple requests and crashes with a Segmentation fault. If the server receives a request from the same user, it should stop processing the old one via some kind of cancellable task, if it doesn't already.

Is HF the only working client?

commented

Thanks for raising this. I'm not having any issues with the fauxpilot plugin so that's really interesting sorry to hear that it's not working for you. I might have a dig around and see if I can recreate that issue. Are you on Mac OS?

I haven't had a look at the co-pilot official plugin for a while - it seems particularly annoying/tricky to reverse engineer and I've not had time to figure it out

The HF issue is interesting. You're right that the problem is caused by multiple requests being serviced by the same device. I'm not entirely sure that cancelling previous requests would be the desired behaviour (what does the hf plugin do with those requests? Are they actually invalid or is it trying to gather multiple results? What about a use case where multiple users want to make requests from the same server?). However, queueing requests or using some sort of locking/mutex structure might provide a short term fix.

commented

Thanks for the reply! No I am actually running all of this on fedora.

The HF plugin doesn't seem to care, it shows only the results from the latest request. I can't verify for sure but if the server isn't available (ie still starting) it'll just happily wait forever. The first request that is sent and responded to satisfies it and it stops listening to other requests is how it appears.

In retrospect that makes sense, I'm almost certain official one is built to discard all requests except the latest, because the inference isn't fast enough to keep up with someone typing without pause.

That's why I figure some kind of ID per user would be better, though if the plugin doesn't send something like that already I can see how it would be tough.

A queue doesn't sound right, you'd want to serve the latest request from each user no?

If a request is sent for

def divideby

the completion should be

def divideby(x,y):
    return x/y

But if I kept typing while turbopilot was crunching away and now my code says

def divideby2(x):

Then the completion turbopilot is already working on isn't useful to me anymore.

However having a lock is absolutely better than having the server crash.

commented

The locking change has gone in. I agree that it would probably be nice to have a way to cancel ongoing requests - I need to better study the crowcpp docs and see how I could go about doing that.

My thinking is to have the model evaluation loop try to acquire a semaphor and break after evaluation of each token. Then, have Crow throw up the semaphor if a connection is closed prematurely. I need to see where this logic could hook into.